[PATCH] rtc: add support for Maxim rtc max6916 v3.0

[venkat . prashanth2498]

From: venkat-prashanth 

 #Change Log: from v2.0 to v3.0

 - fixed the out-of-tree Makefile and suitably added
   the modifications in the Makefile

 - fixed the bad indented Kconfig file

 -used a define instead of 0x1B as follows
#define MAX6916_REG_MAP_ADDRESS 0x1B

 -moved and placed the test at the begining of the function
  after the range is properly enforced
   if (dt->tm_year < 100 || dt->tm_year > 199) {
  dev_err(>dev,"Year must be between 2000 and 2099.
  It's %d.\n", dt->tm_year + 1900);
  return -EINVAL;
  }

 - A magic number is a direct usage of a number
   in the code,instead has been refactored in  the
   current version v3.0 which use defines as follows:-
 -max6916_read_reg(>dev,
  int MAX6916_CONTROL_REG = 0x08, );
 -max6916_write_reg(>dev,
  int MAX6916_CONTROL_REG= 0x08, data);
 -max6916_write_reg(>dev,
  int MAX6916_STATUS_REG = 0x0C, data);
 -max6916_read_reg(>dev,
  int MAX6916_CONTROL_REG = 0x08, );
   -max6916_read_reg(>dev,
  int MAX6916_STATUS_REG  = 0X0C,  );
 -Unnecessary test function if(dt->tm_year >= 100)
  dt->tm_year -= 100;
  is deleted after the range is properly enforced.
 -seperated logical code sections with an empty line
  and used indentation after if-statements.
---
---
 Kconfig   |   9 
 Makefile  |   1 +
 rtc-max6916.c | 162 ++
 3 files changed, 172 insertions(+)

diff --git a/driver/rtc/Kconfig b/driver/rtc/Kconfig
index fcf87da..5321e8f 100644
--- a/driver/rtc/Kconfig
+++ b/driver/rtc/Kconfig
@@ -699,6 +699,15 @@
  
   This driver can also be built as a module. If so, the module
   will be called rtc-max6902.
+config RTC_DRV_MAX6916
+tristate "Maxim MAX6916"
+help
+  If you say yes here you will get support for the
+  Maxim MAX6916 SPI RTC chip.
+
+  This driver can also be built as a module. If so, the module
+  will be called rtc-max6916.
+
  
 config RTC_DRV_R9701
 tristate "Epson RTC-9701JE"
diff --git a/driver/rtc/Makefile b/driver/rtc/Makefile
index 9421959..0b3fded 100644
--- a/driver/rtc/Makefile
+++ b/driver/rtc/Makefile
@@ -85,6 +85,7 @@
 obj-$(CONFIG_RTC_DRV_M48T86)+= rtc-m48t86.o
 obj-$(CONFIG_RTC_DRV_MAX6900)   += rtc-max6900.o
 obj-$(CONFIG_RTC_DRV_MAX6902)   += rtc-max6902.o
+obj-$(CONFIG_RTC_DRV_MAX6916)   += rtc-max6916.o
 obj-$(CONFIG_RTC_DRV_MAX77686)  += rtc-max77686.o
 obj-$(CONFIG_RTC_DRV_MAX77802)  += rtc-max77802.o
 obj-$(CONFIG_RTC_DRV_MAX8907)   += rtc-max8907.o
diff --git a/driver/rtc/rtc-max6916.c b/driver/rtc/rtc-max6916.c
index e69de29..ced341a 100644
--- a/driver/rtc/rtc-max6916.c
+++ b/driver/rtc/rtc-max6916.c
@@ -0,0 +1,162 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Registers in max6916 rtc */
+
+#define MAX6916_SECONDS_REG  0x01
+#define MAX6916_MINUTES_REG  0x02
+#define MAX6916_HOURS_REG0x03
+#define MAX6916_DATE_REG 0x04
+#define MAX6916_MONTH_REG0x05
+#define MAX6916_DAY_REG  0x06
+#define MAX6916_YEAR_REG 0x07
+#define MAX6916_CONTROL_REG  0x08
+#define MAX6916_STATUS_REG   0x0C
+#define MAX6916_CLOCK_BURST  0x3F
+#define MAX6916_REG_MAP_ADDRESS  0x1B
+
+static int max6916_read_reg(struct device *dev, unsigned char address, 
unsigned char *data)
+
+{
+   struct spi_device *spi = to_spi_device(dev);
+
+   *data = address | 0x80;
+
+   return spi_write_then_read(spi, data, 1, data, 1);
+}
+
+static int max6916_write_reg(struct device *dev, unsigned char address, 
unsigned char data)
+
+{
+   struct spi_device *spi = to_spi_device(dev);
+   unsigned char buf[2];
+
+   buf[0] = address&0x7F;
+   buf[1] = data;
+
+   return spi_write_then_read(spi, buf, 2, NULL, 0);
+}
+
+static int max6916_read_time(struct device *dev, struct rtc_time *dt)
+{
+   struct spi_device *spi = to_spi_device(dev);
+   int err;
+   unsigned char buf[8];
+
+   

[PATCH] rtc: add support for Maxim rtc max6916 v3.0

[venkat . prashanth2498]

From: venkat-prashanth 

 #Change Log: from v2.0 to v3.0

 - fixed the out-of-tree Makefile and suitably added
   the modifications in the Makefile

 - fixed the bad indented Kconfig file

 -used a define instead of 0x1B as follows
#define MAX6916_REG_MAP_ADDRESS 0x1B

 -moved and placed the test at the begining of the function
  after the range is properly enforced
   if (dt->tm_year < 100 || dt->tm_year > 199) {
  dev_err(>dev,"Year must be between 2000 and 2099.
  It's %d.\n", dt->tm_year + 1900);
  return -EINVAL;
  }

 - A magic number is a direct usage of a number
   in the code,instead has been refactored in  the
   current version v3.0 which use defines as follows:-
 -max6916_read_reg(>dev,
  int MAX6916_CONTROL_REG = 0x08, );
 -max6916_write_reg(>dev,
  int MAX6916_CONTROL_REG= 0x08, data);
 -max6916_write_reg(>dev,
  int MAX6916_STATUS_REG = 0x0C, data);
 -max6916_read_reg(>dev,
  int MAX6916_CONTROL_REG = 0x08, );
   -max6916_read_reg(>dev,
  int MAX6916_STATUS_REG  = 0X0C,  );
 -Unnecessary test function if(dt->tm_year >= 100)
  dt->tm_year -= 100;
  is deleted after the range is properly enforced.
 -seperated logical code sections with an empty line
  and used indentation after if-statements.
---
---
 Kconfig   |   9 
 Makefile  |   1 +
 rtc-max6916.c | 162 ++
 3 files changed, 172 insertions(+)

diff --git a/driver/rtc/Kconfig b/driver/rtc/Kconfig
index fcf87da..5321e8f 100644
--- a/driver/rtc/Kconfig
+++ b/driver/rtc/Kconfig
@@ -699,6 +699,15 @@
  
   This driver can also be built as a module. If so, the module
   will be called rtc-max6902.
+config RTC_DRV_MAX6916
+tristate "Maxim MAX6916"
+help
+  If you say yes here you will get support for the
+  Maxim MAX6916 SPI RTC chip.
+
+  This driver can also be built as a module. If so, the module
+  will be called rtc-max6916.
+
  
 config RTC_DRV_R9701
 tristate "Epson RTC-9701JE"
diff --git a/driver/rtc/Makefile b/driver/rtc/Makefile
index 9421959..0b3fded 100644
--- a/driver/rtc/Makefile
+++ b/driver/rtc/Makefile
@@ -85,6 +85,7 @@
 obj-$(CONFIG_RTC_DRV_M48T86)+= rtc-m48t86.o
 obj-$(CONFIG_RTC_DRV_MAX6900)   += rtc-max6900.o
 obj-$(CONFIG_RTC_DRV_MAX6902)   += rtc-max6902.o
+obj-$(CONFIG_RTC_DRV_MAX6916)   += rtc-max6916.o
 obj-$(CONFIG_RTC_DRV_MAX77686)  += rtc-max77686.o
 obj-$(CONFIG_RTC_DRV_MAX77802)  += rtc-max77802.o
 obj-$(CONFIG_RTC_DRV_MAX8907)   += rtc-max8907.o
diff --git a/driver/rtc/rtc-max6916.c b/driver/rtc/rtc-max6916.c
index e69de29..ced341a 100644
--- a/driver/rtc/rtc-max6916.c
+++ b/driver/rtc/rtc-max6916.c
@@ -0,0 +1,162 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Registers in max6916 rtc */
+
+#define MAX6916_SECONDS_REG  0x01
+#define MAX6916_MINUTES_REG  0x02
+#define MAX6916_HOURS_REG0x03
+#define MAX6916_DATE_REG 0x04
+#define MAX6916_MONTH_REG0x05
+#define MAX6916_DAY_REG  0x06
+#define MAX6916_YEAR_REG 0x07
+#define MAX6916_CONTROL_REG  0x08
+#define MAX6916_STATUS_REG   0x0C
+#define MAX6916_CLOCK_BURST  0x3F
+#define MAX6916_REG_MAP_ADDRESS  0x1B
+
+static int max6916_read_reg(struct device *dev, unsigned char address, 
unsigned char *data)
+
+{
+   struct spi_device *spi = to_spi_device(dev);
+
+   *data = address | 0x80;
+
+   return spi_write_then_read(spi, data, 1, data, 1);
+}
+
+static int max6916_write_reg(struct device *dev, unsigned char address, 
unsigned char data)
+
+{
+   struct spi_device *spi = to_spi_device(dev);
+   unsigned char buf[2];
+
+   buf[0] = address&0x7F;
+   buf[1] = data;
+
+   return spi_write_then_read(spi, buf, 2, NULL, 0);
+}
+
+static int max6916_read_time(struct device *dev, struct rtc_time *dt)
+{
+   struct spi_device *spi = to_spi_device(dev);
+   int err;
+   unsigned char buf[8];
+
+   buf[0] = MAX6916_CLOCK_BURST | 

RE: [PATCH] usb: gadget: f_fs: report error if excess data received

[Du, Changbin]

> Hi,
> 
> "Du, Changbin"  writes:
> >> right, and that was my point: if we copy more to userspace, then we have
> >> a real big problem.
> >>
> > Yes, we drop the data because we userspace buffer is not enough this time.
> > The problem here is that really can we just drop it silently? Maybe not.
> 
> Yeah, it probably deserves a pr_err() or pr_debug(), but host sending
> more data than it should, is another problem altogether which needs to
> be addressed at the host.
> 
> Adding a print to aid debugging is a good idea, but bailing out on the
> peripheral side is not :-s
> 
Ok, if we think this is a problem at host side that the transfer is not device
expected, then device side should not accept the data or deliver the
transferred data to userspace. But now we take part of the data to userspace
and says it is ok.
Do you agree with this point?

IMO, we expose usb transfer as a file on device side. But file read() doesn't
have a requirement that "sorry, you cannot read so little! you need read all
once, else we may drop data for you. :) ".
And some library that may retry read() until get enough data (which is normal
For a general read). Then sometimes the buffer size for sys_read may not as
expected. This is why I think ioctl approach is more appropriate for usb 
transfer.

> --
> Balbi

Best Regards,
Du, Changbin

RE: [PATCH] usb: gadget: f_fs: report error if excess data received

[Du, Changbin]

> Hi,
> 
> "Du, Changbin"  writes:
> >> right, and that was my point: if we copy more to userspace, then we have
> >> a real big problem.
> >>
> > Yes, we drop the data because we userspace buffer is not enough this time.
> > The problem here is that really can we just drop it silently? Maybe not.
> 
> Yeah, it probably deserves a pr_err() or pr_debug(), but host sending
> more data than it should, is another problem altogether which needs to
> be addressed at the host.
> 
> Adding a print to aid debugging is a good idea, but bailing out on the
> peripheral side is not :-s
> 
Ok, if we think this is a problem at host side that the transfer is not device
expected, then device side should not accept the data or deliver the
transferred data to userspace. But now we take part of the data to userspace
and says it is ok.
Do you agree with this point?

IMO, we expose usb transfer as a file on device side. But file read() doesn't
have a requirement that "sorry, you cannot read so little! you need read all
once, else we may drop data for you. :) ".
And some library that may retry read() until get enough data (which is normal
For a general read). Then sometimes the buffer size for sys_read may not as
expected. This is why I think ioctl approach is more appropriate for usb 
transfer.

> --
> Balbi

Best Regards,
Du, Changbin

Re: SHA1-MB algorithm broken on latest kernel

[Ingo Molnar]

* Herbert Xu  wrote:

> On Thu, May 12, 2016 at 04:31:06PM -0700, Megha Dey wrote:
> > Hi,
> >  
> > When booting latest kernel with the CONFIG_CRYPTO_SHA1_MB enabled, I
> > observe a panic.
> >  
> > After having a quick look, on reverting the following patches, I am able
> > to complete the booting process.
> > aec4d0e301f17bb143341c82cc44685b8af0b945
> > 8691ccd764f9ecc69a6812dfe76214c86ac9ba06
> > 68874ac3304ade7ed5ebb12af00d6b9bbbca0a16
> >  
> > Of the 3 patches, aec4d0e301f17bb143341c82cc44685b8af0b945 seems wrong.
> > The r10 to r15 registers are used in sha1_x8_avx2.S, which is called
> > from sha1_mb_mgr_flush_avx2.S.
> >
> > I do not think the functionality of the SHA1-MB crypto algorithm has
> > been tested after applying these changes. (I am not sure if any of the
> > other crypto algorithms have been affected by these changes).
> 
> Josh, Ingo:
> 
> Any ideas on this? Should we revert?

Yeah, I think so - although another option would be to standardize 
sha1_x8_avx2() 
- the problem is that it is a function that clobbers registers without 
saving/restoring them, breaking the C function ABI. I realize it's written in 
assembly, but unless there are strong performance reasons to deviate from the 
regular calling convention it might make sense to fix that.

Do any warnings get generated after the revert, if you enable 
CONFIG_STACK_VALIDATION=y?

Thanks,

Ingo

Re: SHA1-MB algorithm broken on latest kernel

[Ingo Molnar]

* Herbert Xu  wrote:

> On Thu, May 12, 2016 at 04:31:06PM -0700, Megha Dey wrote:
> > Hi,
> >  
> > When booting latest kernel with the CONFIG_CRYPTO_SHA1_MB enabled, I
> > observe a panic.
> >  
> > After having a quick look, on reverting the following patches, I am able
> > to complete the booting process.
> > aec4d0e301f17bb143341c82cc44685b8af0b945
> > 8691ccd764f9ecc69a6812dfe76214c86ac9ba06
> > 68874ac3304ade7ed5ebb12af00d6b9bbbca0a16
> >  
> > Of the 3 patches, aec4d0e301f17bb143341c82cc44685b8af0b945 seems wrong.
> > The r10 to r15 registers are used in sha1_x8_avx2.S, which is called
> > from sha1_mb_mgr_flush_avx2.S.
> >
> > I do not think the functionality of the SHA1-MB crypto algorithm has
> > been tested after applying these changes. (I am not sure if any of the
> > other crypto algorithms have been affected by these changes).
> 
> Josh, Ingo:
> 
> Any ideas on this? Should we revert?

Yeah, I think so - although another option would be to standardize 
sha1_x8_avx2() 
- the problem is that it is a function that clobbers registers without 
saving/restoring them, breaking the C function ABI. I realize it's written in 
assembly, but unless there are strong performance reasons to deviate from the 
regular calling convention it might make sense to fix that.

Do any warnings get generated after the revert, if you enable 
CONFIG_STACK_VALIDATION=y?

Thanks,

Ingo

Re: next: fuloong2e qemu boot failure due to 'MIPS: Loongson: AddLoongson-3A R2 basic support'

[Huacai Chen]

I'll send a patch, but it seems be ignored by maintainer.
https://patchwork.linux-mips.org/patch/13136/

Huacai

On Fri, May 13, 2016 at 11:46 AM, Guenter Roeck <li...@roeck-us.net> wrote:
> On 04/19/2016 10:41 PM, Huacai Chen wrote:
>>
>> This is a kernel bug, I'll send a patch.
>>
>
> Did you ever send a patch to fix this problem ? It is still broken in
> next-20160512.
>
> Guenter
>
>
>> Huacai
>>
>> On Wed, Apr 20, 2016 at 12:43 PM, Guenter Roeck <li...@roeck-us.net>
>> wrote:
>>>
>>> On 04/19/2016 08:37 PM, 陈华才 wrote:
>>>>
>>>>
>>>> Hi,
>>>>
>>>> Could you please remove the line "#define cpu_hwrena_impl_bits
>>>> 0xc000" in
>>>> arch/mips/include/asm/mach-loongson64/cpu-feature-overrides.h
>>>> and try again?Thanks.
>>>>
>>>
>>> That fixes the problem.
>>>
>>> Does this need to be addressed in qemu or in the Linux kernel ?
>>>
>>> Thanks,
>>> Guenter
>>>
>>>
>>>> Huacai
>>>>
>>>> -- Original --
>>>> From:  "Guenter Roeck"<li...@roeck-us.net>;
>>>> Date:  Wed, Apr 20, 2016 10:54 AM
>>>> To:  "Huacai Chen"<che...@lemote.com>;
>>>> Cc:  "Ralf Baechle"<r...@linux-mips.org>;
>>>> "linux-mips"<linux-m...@linux-mips.org>;
>>>> "linux-next"<linux-n...@vger.kernel.org>;
>>>> "linux-kernel"<linux-kernel@vger.kernel.org>;
>>>> Subject:  next: fuloong2e qemu boot failure due to 'MIPS: Loongson:
>>>> AddLoongson-3A R2 basic support'
>>>>
>>>> Hi,
>>>>
>>>> qemu fails to boot in -next for machine fulong2e with configuration
>>>> fuloong2e_defconfig. Bisect points to commit 'MIPS: Loongson: Add
>>>> Loongson-3A R2 basic support'. qemu hangs in boot, after displaying
>>>> "Inode-cache hash table entries: 16384 (order: 3, 131072 bytes)".
>>>>
>>>> Bisect log is attached.
>>>>
>>>> Guenter
>>>>
>>>> ---
>>>> # bad: [1bd7a2081d2c7b096f75aa934658e404ccaba5fd] Add linux-next
>>>> specific
>>>> files for 20160418
>>>> # good: [bf16200689118d19de1b8d2a3c314fc21f5dc7bb] Linux 4.6-rc3
>>>> git bisect start 'HEAD' 'v4.6-rc3'
>>>> # bad: [493ac92ff65ec4c4cd4c43870e778760a012951d] Merge remote-tracking
>>>> branch 'ipvs-next/master'
>>>> git bisect bad 493ac92ff65ec4c4cd4c43870e778760a012951d
>>>> # bad: [20ca3ae9c517eee9b2f1bd0fb2a06e2d14153792] Merge remote-tracking
>>>> branch 'btrfs-kdave/for-next'
>>>> git bisect bad 20ca3ae9c517eee9b2f1bd0fb2a06e2d14153792
>>>> # good: [c454e65fb9ade11d0f84718d06a6888e2c92804d] Merge remote-tracking
>>>> branch 'omap/for-next'
>>>> git bisect good c454e65fb9ade11d0f84718d06a6888e2c92804d
>>>> # good: [6f5c70fb9b4fc0534157bfa40cea9b402e6f2506] Merge remote-tracking
>>>> branch 'microblaze/next'
>>>> git bisect good 6f5c70fb9b4fc0534157bfa40cea9b402e6f2506
>>>> # bad: [7f053cd68fd14243c8f202b4086d7dd75c409e6f] MIPS: Loongson-3:
>>>> Introduce CONFIG_LOONGSON3_ENHANCEMENT
>>>> git bisect bad 7f053cd68fd14243c8f202b4086d7dd75c409e6f
>>>> # good: [e9aacdd7f0b66c4ace17e5950c48e7cc61a253c8] MIPS: Allow RIXI to
>>>> be
>>>> used on non-R2 or R6 cores
>>>> git bisect good e9aacdd7f0b66c4ace17e5950c48e7cc61a253c8
>>>> # good: [d1e8b9a8dc6c7fa9add5dfa7083e035ce037e56d] MAINTAINERS: add
>>>> Loongson1 architecture entry
>>>> git bisect good d1e8b9a8dc6c7fa9add5dfa7083e035ce037e56d
>>>> # good: [13ff6275bb389c3669082d3ef8483592a31eb0ea] MIPS: Fix siginfo.h
>>>> to
>>>> use strict posix types
>>>> git bisect good 13ff6275bb389c3669082d3ef8483592a31eb0ea
>>>> # good: [66e74bdd51e617023fa2e79a807b704fb3eed8aa] MIPS: Enable ptrace
>>>> hw
>>>> watchpoints on MIPS R6
>>>> git bisect good 66e74bdd51e617023fa2e79a807b704fb3eed8aa
>>>> # good: [f7cabc2dac8adf5986dbc700584bc3b8fe493d4d] MIPS: Loongson-3:
>>>> Adjust irq dispatch to speedup processing
>>>> git bisect good f7cabc2dac8adf5986dbc700584bc3b8fe493d4d
>>>> # bad: [4978c8477e96fb9e9d870d8f42328dcabf1a65e9] MIPS: Loongson-3: Set
>>>> cache flush handlers to cache_noop
>>>> git bisect bad 4978c8477e96fb9e9d870d8f42328dcabf1a65e9
>>>> # bad: [04a35922c1dac1b4864b8b366a37474e9e51d8c0] MIPS: Loongson: Add
>>>> Loongson-3A R2 basic support
>>>> git bisect bad 04a35922c1dac1b4864b8b366a37474e9e51d8c0
>>>> # first bad commit: [04a35922c1dac1b4864b8b366a37474e9e51d8c0] MIPS:
>>>> Loongson: Add Loongson-3A R2 basic support
>>>>
>>>
>>>
>>
>
>

[PATCH] ixgbe: take online CPU number as MQ max limit when alloc_etherdev_mq()

[Ethan Zhao]

Allocating 64 Tx/Rx as default doesn't benefit perfomrnace when less
CPUs were assigned. especially when DCB is enabled, so we should take
num_online_cpus() as top limit, and aslo to make sure every TC has
at least one queue, take the MAX_TRAFFIC_CLASS as bottom limit of queues
number.

Signed-off-by: Ethan Zhao 
---
 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c 
b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 7df3fe2..1f9769c 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -9105,6 +9105,10 @@ static int ixgbe_probe(struct pci_dev *pdev, const 
struct pci_device_id *ent)
indices = IXGBE_MAX_RSS_INDICES;
 #endif
}
+   /* Don't allocate too more queues than online cpus number */
+   indices = min_t(int, indices, num_online_cpus());
+   /* To make sure TC works, allocate at least 1 queue per TC */
+   indices = max_t(int, indices, MAX_TRAFFIC_CLASS);
 
netdev = alloc_etherdev_mq(sizeof(struct ixgbe_adapter), indices);
if (!netdev) {
-- 
1.8.3.1

Re: next: fuloong2e qemu boot failure due to 'MIPS: Loongson: AddLoongson-3A R2 basic support'

[Huacai Chen]

I'll send a patch, but it seems be ignored by maintainer.
https://patchwork.linux-mips.org/patch/13136/

Huacai

On Fri, May 13, 2016 at 11:46 AM, Guenter Roeck  wrote:
> On 04/19/2016 10:41 PM, Huacai Chen wrote:
>>
>> This is a kernel bug, I'll send a patch.
>>
>
> Did you ever send a patch to fix this problem ? It is still broken in
> next-20160512.
>
> Guenter
>
>
>> Huacai
>>
>> On Wed, Apr 20, 2016 at 12:43 PM, Guenter Roeck 
>> wrote:
>>>
>>> On 04/19/2016 08:37 PM, 陈华才 wrote:
>>>>
>>>>
>>>> Hi,
>>>>
>>>> Could you please remove the line "#define cpu_hwrena_impl_bits
>>>> 0xc000" in
>>>> arch/mips/include/asm/mach-loongson64/cpu-feature-overrides.h
>>>> and try again?Thanks.
>>>>
>>>
>>> That fixes the problem.
>>>
>>> Does this need to be addressed in qemu or in the Linux kernel ?
>>>
>>> Thanks,
>>> Guenter
>>>
>>>
>>>> Huacai
>>>>
>>>> -- Original --
>>>> From:  "Guenter Roeck";
>>>> Date:  Wed, Apr 20, 2016 10:54 AM
>>>> To:  "Huacai Chen";
>>>> Cc:  "Ralf Baechle";
>>>> "linux-mips";
>>>> "linux-next";
>>>> "linux-kernel";
>>>> Subject:  next: fuloong2e qemu boot failure due to 'MIPS: Loongson:
>>>> AddLoongson-3A R2 basic support'
>>>>
>>>> Hi,
>>>>
>>>> qemu fails to boot in -next for machine fulong2e with configuration
>>>> fuloong2e_defconfig. Bisect points to commit 'MIPS: Loongson: Add
>>>> Loongson-3A R2 basic support'. qemu hangs in boot, after displaying
>>>> "Inode-cache hash table entries: 16384 (order: 3, 131072 bytes)".
>>>>
>>>> Bisect log is attached.
>>>>
>>>> Guenter
>>>>
>>>> ---
>>>> # bad: [1bd7a2081d2c7b096f75aa934658e404ccaba5fd] Add linux-next
>>>> specific
>>>> files for 20160418
>>>> # good: [bf16200689118d19de1b8d2a3c314fc21f5dc7bb] Linux 4.6-rc3
>>>> git bisect start 'HEAD' 'v4.6-rc3'
>>>> # bad: [493ac92ff65ec4c4cd4c43870e778760a012951d] Merge remote-tracking
>>>> branch 'ipvs-next/master'
>>>> git bisect bad 493ac92ff65ec4c4cd4c43870e778760a012951d
>>>> # bad: [20ca3ae9c517eee9b2f1bd0fb2a06e2d14153792] Merge remote-tracking
>>>> branch 'btrfs-kdave/for-next'
>>>> git bisect bad 20ca3ae9c517eee9b2f1bd0fb2a06e2d14153792
>>>> # good: [c454e65fb9ade11d0f84718d06a6888e2c92804d] Merge remote-tracking
>>>> branch 'omap/for-next'
>>>> git bisect good c454e65fb9ade11d0f84718d06a6888e2c92804d
>>>> # good: [6f5c70fb9b4fc0534157bfa40cea9b402e6f2506] Merge remote-tracking
>>>> branch 'microblaze/next'
>>>> git bisect good 6f5c70fb9b4fc0534157bfa40cea9b402e6f2506
>>>> # bad: [7f053cd68fd14243c8f202b4086d7dd75c409e6f] MIPS: Loongson-3:
>>>> Introduce CONFIG_LOONGSON3_ENHANCEMENT
>>>> git bisect bad 7f053cd68fd14243c8f202b4086d7dd75c409e6f
>>>> # good: [e9aacdd7f0b66c4ace17e5950c48e7cc61a253c8] MIPS: Allow RIXI to
>>>> be
>>>> used on non-R2 or R6 cores
>>>> git bisect good e9aacdd7f0b66c4ace17e5950c48e7cc61a253c8
>>>> # good: [d1e8b9a8dc6c7fa9add5dfa7083e035ce037e56d] MAINTAINERS: add
>>>> Loongson1 architecture entry
>>>> git bisect good d1e8b9a8dc6c7fa9add5dfa7083e035ce037e56d
>>>> # good: [13ff6275bb389c3669082d3ef8483592a31eb0ea] MIPS: Fix siginfo.h
>>>> to
>>>> use strict posix types
>>>> git bisect good 13ff6275bb389c3669082d3ef8483592a31eb0ea
>>>> # good: [66e74bdd51e617023fa2e79a807b704fb3eed8aa] MIPS: Enable ptrace
>>>> hw
>>>> watchpoints on MIPS R6
>>>> git bisect good 66e74bdd51e617023fa2e79a807b704fb3eed8aa
>>>> # good: [f7cabc2dac8adf5986dbc700584bc3b8fe493d4d] MIPS: Loongson-3:
>>>> Adjust irq dispatch to speedup processing
>>>> git bisect good f7cabc2dac8adf5986dbc700584bc3b8fe493d4d
>>>> # bad: [4978c8477e96fb9e9d870d8f42328dcabf1a65e9] MIPS: Loongson-3: Set
>>>> cache flush handlers to cache_noop
>>>> git bisect bad 4978c8477e96fb9e9d870d8f42328dcabf1a65e9
>>>> # bad: [04a35922c1dac1b4864b8b366a37474e9e51d8c0] MIPS: Loongson: Add
>>>> Loongson-3A R2 basic support
>>>> git bisect bad 04a35922c1dac1b4864b8b366a37474e9e51d8c0
>>>> # first bad commit: [04a35922c1dac1b4864b8b366a37474e9e51d8c0] MIPS:
>>>> Loongson: Add Loongson-3A R2 basic support
>>>>
>>>
>>>
>>
>
>

[PATCH] ixgbe: take online CPU number as MQ max limit when alloc_etherdev_mq()

[Ethan Zhao]

Allocating 64 Tx/Rx as default doesn't benefit perfomrnace when less
CPUs were assigned. especially when DCB is enabled, so we should take
num_online_cpus() as top limit, and aslo to make sure every TC has
at least one queue, take the MAX_TRAFFIC_CLASS as bottom limit of queues
number.

Signed-off-by: Ethan Zhao 
---
 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c 
b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 7df3fe2..1f9769c 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -9105,6 +9105,10 @@ static int ixgbe_probe(struct pci_dev *pdev, const 
struct pci_device_id *ent)
indices = IXGBE_MAX_RSS_INDICES;
 #endif
}
+   /* Don't allocate too more queues than online cpus number */
+   indices = min_t(int, indices, num_online_cpus());
+   /* To make sure TC works, allocate at least 1 queue per TC */
+   indices = max_t(int, indices, MAX_TRAFFIC_CLASS);
 
netdev = alloc_etherdev_mq(sizeof(struct ixgbe_adapter), indices);
if (!netdev) {
-- 
1.8.3.1

Re: [PATCH] sched/core: don't include asm/mmu_context from drivers

[Andy Lutomirski]

On Fri, Apr 29, 2016 at 6:42 AM, Steven Rostedt  wrote:
> On Fri, 29 Apr 2016 10:52:32 +0200
> Arnd Bergmann  wrote:
>
>> This reverts the earlier fix attempt and works around the problem
>> by including both linux/mmu_context.h and asm/mmu_context.h from
>> kernel/sched/core.c. This is not a good solution but seems less
>> hacky than the alternatives.
>
> What about simply not compiling finish_arch_post_lock_switch() when
> building modules?
>
> (untested, not compiled or anything)
>
> Signed-off-by: Steven Rostedt 
> ---
> diff --git a/arch/arm/include/asm/mmu_context.h 
> b/arch/arm/include/asm/mmu_context.h
> index fa5b42d44985..3f22d1b6bac8 100644
> --- a/arch/arm/include/asm/mmu_context.h
> +++ b/arch/arm/include/asm/mmu_context.h
> @@ -66,6 +66,7 @@ static inline void check_and_switch_context(struct 
> mm_struct *mm,
> cpu_switch_mm(mm->pgd, mm);
>  }
>
> +#ifndef MODULE
>  #define finish_arch_post_lock_switch \
> finish_arch_post_lock_switch
>  static inline void finish_arch_post_lock_switch(void)
> @@ -87,6 +88,7 @@ static inline void finish_arch_post_lock_switch(void)
> preempt_enable_no_resched();
> }
>  }
> +#endif /* !MODULE */
>
>  #endif /* CONFIG_MMU */
>


Can someone in arm land ack this so Ingo can apply it?

--Andy

-- 
Andy Lutomirski
AMA Capital Management, LLC

Re: [PATCH] sched/core: don't include asm/mmu_context from drivers

[Andy Lutomirski]

On Fri, Apr 29, 2016 at 6:42 AM, Steven Rostedt  wrote:
> On Fri, 29 Apr 2016 10:52:32 +0200
> Arnd Bergmann  wrote:
>
>> This reverts the earlier fix attempt and works around the problem
>> by including both linux/mmu_context.h and asm/mmu_context.h from
>> kernel/sched/core.c. This is not a good solution but seems less
>> hacky than the alternatives.
>
> What about simply not compiling finish_arch_post_lock_switch() when
> building modules?
>
> (untested, not compiled or anything)
>
> Signed-off-by: Steven Rostedt 
> ---
> diff --git a/arch/arm/include/asm/mmu_context.h 
> b/arch/arm/include/asm/mmu_context.h
> index fa5b42d44985..3f22d1b6bac8 100644
> --- a/arch/arm/include/asm/mmu_context.h
> +++ b/arch/arm/include/asm/mmu_context.h
> @@ -66,6 +66,7 @@ static inline void check_and_switch_context(struct 
> mm_struct *mm,
> cpu_switch_mm(mm->pgd, mm);
>  }
>
> +#ifndef MODULE
>  #define finish_arch_post_lock_switch \
> finish_arch_post_lock_switch
>  static inline void finish_arch_post_lock_switch(void)
> @@ -87,6 +88,7 @@ static inline void finish_arch_post_lock_switch(void)
> preempt_enable_no_resched();
> }
>  }
> +#endif /* !MODULE */
>
>  #endif /* CONFIG_MMU */
>


Can someone in arm land ack this so Ingo can apply it?

--Andy

-- 
Andy Lutomirski
AMA Capital Management, LLC

linux-next: Tree for May 13

[Stephen Rothwell]

Hi all,

Changes since 20160512:

Dropped tree: rdma-leon (bad build and conflicts)

The rdma-leon tree gained a build failure so I dropped it for today.

The staging tree gained a build failure for which I applied a merge
fix patch.

The pinctrl tree lost its build failure.

Non-merge commits (relative to Linus' tree): 9975
 8496 files changed, 436478 insertions(+), 184404 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
(this fails its final link) and pseries_le_defconfig and i386, sparc
and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 235 trees (counting Linus' and 35 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (02c9c0e9b9d9 Merge tag 'keys-fixes-20160512' of 
git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs)
Merging fixes/master (b507146bb6b9 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on 
module install)
Merging arc-current/for-curr (44549e8f5eea Linux 4.6-rc7)
Merging arm-current/fixes (ec953b70f368 ARM: 8573/1: domain: move 
{set,get}_domain under config guard)
Merging m68k-current/for-linus (7b8ba82ad4ad m68k/defconfig: Update defconfigs 
for v4.6-rc2)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging powerpc-fixes/fixes (b4c112114aab powerpc: Fix bad inline asm 
constraint in create_zero_mask())
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (33656a1f2ee5 Merge branch 'for_linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs)
Merging net/master (2073dbad172f net: mvneta: bm: fix dependencies again)
Merging ipsec/master (d6af1a31cc72 vti: Add pmtu handling to vti_xmit.)
Merging ipvs/master (f28f20da704d Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging wireless-drivers/master (cbbba30f1ac9 Merge tag 
'iwlwifi-for-kalle-2016-05-04' of 
https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes)
Merging mac80211/master (e6436be21e77 mac80211: fix statistics leak if 
dev_alloc_name() fails)
Merging sound-current/for-linus (84add303ef95 ALSA: usb-audio: Yet another 
Phoneix Audio device quirk)
Merging pci-current/for-linus (9a2a5a638f8e PCI: Do not treat EPROBE_DEFER as 
device attach failure)
Merging driver-core.current/driver-core-linus (c3b46c73264b Linux 4.6-rc4)
Merging tty.current/tty-linus (44549e8f5eea Linux 4.6-rc7)
Merging usb.current/usb-linus (44549e8f5eea Linux 4.6-rc7)
Merging usb-gadget-fixes/fixes (38740a5b87d5 usb: gadget: f_fs: Fix 
use-after-free)
Merging usb-serial-fixes/usb-linus (74d2a91aec97 USB: serial: option: add even 
more ZTE device ids)
Merging usb-chipidea-fixes/ci-for-usb-stable (d144dfea8af7 usb: chipidea: otg: 
change workqueue ci_otg as freezable)
Merging staging.current/staging-linus (44549e8f5eea Linux 4.6-rc7)
Merging char-misc.current/char-misc-linus (44549e8f5eea Linux 4.6-rc7)
Merging input-current/for-linus (c52c545ead97 Input: twl6040-vibra - fix DT 
node memory management)
Merging crypto-current/master (df27b26f04ed crypto: testmgr - Use kmalloc 
memory for RSA input)
Merging ide/master (1993b176a822 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide)
Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test 
for PPC_PSERIES)
Merging rr-fixes/fixes (8244062ef1e5 modules: fix longstanding /proc/kallsyms 
vs module insertion race.

linux-next: Tree for May 13

[Stephen Rothwell]

Hi all,

Changes since 20160512:

Dropped tree: rdma-leon (bad build and conflicts)

The rdma-leon tree gained a build failure so I dropped it for today.

The staging tree gained a build failure for which I applied a merge
fix patch.

The pinctrl tree lost its build failure.

Non-merge commits (relative to Linus' tree): 9975
 8496 files changed, 436478 insertions(+), 184404 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
(this fails its final link) and pseries_le_defconfig and i386, sparc
and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 235 trees (counting Linus' and 35 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (02c9c0e9b9d9 Merge tag 'keys-fixes-20160512' of 
git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs)
Merging fixes/master (b507146bb6b9 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on 
module install)
Merging arc-current/for-curr (44549e8f5eea Linux 4.6-rc7)
Merging arm-current/fixes (ec953b70f368 ARM: 8573/1: domain: move 
{set,get}_domain under config guard)
Merging m68k-current/for-linus (7b8ba82ad4ad m68k/defconfig: Update defconfigs 
for v4.6-rc2)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging powerpc-fixes/fixes (b4c112114aab powerpc: Fix bad inline asm 
constraint in create_zero_mask())
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (33656a1f2ee5 Merge branch 'for_linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs)
Merging net/master (2073dbad172f net: mvneta: bm: fix dependencies again)
Merging ipsec/master (d6af1a31cc72 vti: Add pmtu handling to vti_xmit.)
Merging ipvs/master (f28f20da704d Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging wireless-drivers/master (cbbba30f1ac9 Merge tag 
'iwlwifi-for-kalle-2016-05-04' of 
https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes)
Merging mac80211/master (e6436be21e77 mac80211: fix statistics leak if 
dev_alloc_name() fails)
Merging sound-current/for-linus (84add303ef95 ALSA: usb-audio: Yet another 
Phoneix Audio device quirk)
Merging pci-current/for-linus (9a2a5a638f8e PCI: Do not treat EPROBE_DEFER as 
device attach failure)
Merging driver-core.current/driver-core-linus (c3b46c73264b Linux 4.6-rc4)
Merging tty.current/tty-linus (44549e8f5eea Linux 4.6-rc7)
Merging usb.current/usb-linus (44549e8f5eea Linux 4.6-rc7)
Merging usb-gadget-fixes/fixes (38740a5b87d5 usb: gadget: f_fs: Fix 
use-after-free)
Merging usb-serial-fixes/usb-linus (74d2a91aec97 USB: serial: option: add even 
more ZTE device ids)
Merging usb-chipidea-fixes/ci-for-usb-stable (d144dfea8af7 usb: chipidea: otg: 
change workqueue ci_otg as freezable)
Merging staging.current/staging-linus (44549e8f5eea Linux 4.6-rc7)
Merging char-misc.current/char-misc-linus (44549e8f5eea Linux 4.6-rc7)
Merging input-current/for-linus (c52c545ead97 Input: twl6040-vibra - fix DT 
node memory management)
Merging crypto-current/master (df27b26f04ed crypto: testmgr - Use kmalloc 
memory for RSA input)
Merging ide/master (1993b176a822 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide)
Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test 
for PPC_PSERIES)
Merging rr-fixes/fixes (8244062ef1e5 modules: fix longstanding /proc/kallsyms 
vs module insertion race.

[PATCH v2 4/4] ACPI 2.0 / AML: Fix module level execution by correctly parsing table as TermList

[Lv Zheng]

This experiment follows de-facto standard behavior, parsing entire
table as a single TermList, so that all module level executions are
possible during the table loading.

If regressions are found against the enabling of this experimental fix,
this patch is the only one that should get bisected out. Please report
the regressions to the kernel bugzilla for further root causing.

Signed-off-by: Lv Zheng 
---
 include/acpi/acpixf.h |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/acpi/acpixf.h b/include/acpi/acpixf.h
index 22b0397..e21bdd1 100644
--- a/include/acpi/acpixf.h
+++ b/include/acpi/acpixf.h
@@ -196,9 +196,9 @@ ACPI_INIT_GLOBAL(u8, acpi_gbl_group_module_level_code, 
FALSE);
 
 /*
  * Optionally support module level code by parsing the entire table as
- * a term_list. Default is FALSE, do not execute entire table.
+ * a term_list. Default is TRUE, do execute entire table.
  */
-ACPI_INIT_GLOBAL(u8, acpi_gbl_parse_table_as_term_list, FALSE);
+ACPI_INIT_GLOBAL(u8, acpi_gbl_parse_table_as_term_list, TRUE);
 
 /*
  * Optionally use 32-bit FADT addresses if and when there is a conflict
-- 
1.7.10

[PATCH v2 4/4] ACPI 2.0 / AML: Fix module level execution by correctly parsing table as TermList

[Lv Zheng]

This experiment follows de-facto standard behavior, parsing entire
table as a single TermList, so that all module level executions are
possible during the table loading.

If regressions are found against the enabling of this experimental fix,
this patch is the only one that should get bisected out. Please report
the regressions to the kernel bugzilla for further root causing.

Signed-off-by: Lv Zheng 
---
 include/acpi/acpixf.h |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/acpi/acpixf.h b/include/acpi/acpixf.h
index 22b0397..e21bdd1 100644
--- a/include/acpi/acpixf.h
+++ b/include/acpi/acpixf.h
@@ -196,9 +196,9 @@ ACPI_INIT_GLOBAL(u8, acpi_gbl_group_module_level_code, 
FALSE);
 
 /*
  * Optionally support module level code by parsing the entire table as
- * a term_list. Default is FALSE, do not execute entire table.
+ * a term_list. Default is TRUE, do execute entire table.
  */
-ACPI_INIT_GLOBAL(u8, acpi_gbl_parse_table_as_term_list, FALSE);
+ACPI_INIT_GLOBAL(u8, acpi_gbl_parse_table_as_term_list, TRUE);
 
 /*
  * Optionally use 32-bit FADT addresses if and when there is a conflict
-- 
1.7.10

[PATCH v2 3/4] ACPI 2.0 / AML: Enable correct ACPI subsystem initialization order for new table loading mode

[Lv Zheng]

This patch enables the following initialization order for the new table
loading mode (which is enabled by setting
acpi_gbl_parse_table_as_term_list to TRUE):
  1. Install default region handlers (SystemMemory, SystemIo, PciConfig,
 EmbeddedControl via ECDT) without evaluating _REG;
  2. Load the table and execute the module level AML opcodes instantly.

Signed-off-by: Lv Zheng 
---
 drivers/acpi/bus.c |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index 31e8da6..d177649 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -925,7 +925,8 @@ void __init acpi_early_init(void)
goto error0;
}
 
-   if (acpi_gbl_group_module_level_code) {
+   if (!acpi_gbl_parse_table_as_term_list &&
+   acpi_gbl_group_module_level_code) {
status = acpi_load_tables();
if (ACPI_FAILURE(status)) {
printk(KERN_ERR PREFIX
@@ -1008,7 +1009,8 @@ static int __init acpi_bus_init(void)
status = acpi_ec_ecdt_probe();
/* Ignore result. Not having an ECDT is not fatal. */
 
-   if (!acpi_gbl_group_module_level_code) {
+   if (acpi_gbl_parse_table_as_term_list ||
+   !acpi_gbl_group_module_level_code) {
status = acpi_load_tables();
if (ACPI_FAILURE(status)) {
printk(KERN_ERR PREFIX
-- 
1.7.10

Re: [GIT PULL 00/10] perf/urgent fixes

[Ingo Molnar]

* Arnaldo Carvalho de Melo <a...@kernel.org> wrote:

> Hi Ingo,
> 
>   Please consider pulling, test built on:
> 
> alldeps-fedora-rawhide: Ok
> alldeps-ubuntu-14.04: Ok
> alldeps-ubuntu-16.04: Ok
> alldeps-fedora-20: Ok
> alldeps-ubuntu-12.04: Ok
> minimal-debian-experimental-x-mips64: Ok
> minimal-debian-experimental-x-mips64el: Ok
> minimal-debian-experimental-x-mipsel: Ok
> minimal-ubuntu-x-arm: Ok
> minimal-ubuntu-x-arm64: Ok
> minimal-ubuntu-x-ppc64: Ok
> minimal-ubuntu-x-ppc64el: Ok
> alldeps-debian: Ok
> alldeps-mageia: Ok
> alldeps-rhel7: Ok
> alldeps-centos: Ok
> alldeps-opensuse: Ok
> 
> - Arnaldo
> 
> The following changes since commit 9f448cd3cbcec8995935e60b27802ae56aac8cc0:
> 
>   perf/core: Disable the event on a truncated AUX record (2016-05-12 14:46:11 
> +0200)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git 
> tags/perf-urgent-for-mingo-20160512
> 
> for you to fetch changes up to 42ef8a78c1f49f53f29f0f3a6f9a5bcbc653233e:
> 
>   perf stat: Fallback to user only counters when perf_event_paranoid > 1 
> (2016-05-12 16:25:18 -0300)
> 
> 
> perf/urgent fixes:
> 
> User visible:
> 
> - Fallback to usermode only counters when perf_event_paranoid > 1, which
>   is the case now (Arnaldo Carvalho de Melo)
> 
> - Do not reassign parg after collapse_tree() in libtraceevent, which
>   may cause tool crashes (Steven Rostedt)
> 
> Build fixes:
> 
> - Fix the build on Fedora Rawhide, where readdir_r() is deprecated and
>   also wrt -Werror=unused-const-variable= + x86_32_regoffset_table on
>   !x86_64 (Arnaldo Carvalho de Melo)
> 
> - Fix the build on Ubuntu 12.04.5, where dwarf_getlocations() isn't
>   available, i.e. libdw-dev < 0.157 (Arnaldo Carvalho de Melo)
> 
> Signed-off-by: Arnaldo Carvalho de Melo <a...@redhat.com>
> 
> 
> Arnaldo Carvalho de Melo (9):
>   perf tools: Use readdir() instead of deprecated readdir_r()
>   perf script: Use readdir() instead of deprecated readdir_r()
>   perf thread_map: Use readdir() instead of deprecated readdir_r()
>   perf tools: Use readdir() instead of deprecated readdir_r()
>   perf dwarf: Guard !x86_64 definitions under #ifdef else clause
>   perf probe: Check if dwarf_getlocations() is available
>   perf evsel: Improve EPERM error handling in open_strerror()
>   perf evsel: Handle EACCESS + perf_event_paranoid=2 in fallback()
>   perf stat: Fallback to user only counters when perf_event_paranoid > 1
> 
> Steven Rostedt (1):
>   tools lib traceevent: Do not reassign parg after collapse_tree()
> 
>  tools/build/Makefile.feature  |  2 +
>  tools/build/feature/Makefile  |  4 ++
>  tools/build/feature/test-all.c|  5 ++
>  tools/build/feature/test-dwarf_getlocations.c | 12 +
>  tools/lib/traceevent/parse-filter.c   |  4 +-
>  tools/perf/arch/x86/util/dwarf-regs.c |  8 +--
>  tools/perf/builtin-script.c   | 70 
> +--
>  tools/perf/builtin-stat.c |  7 ++-
>  tools/perf/config/Makefile|  6 +++
>  tools/perf/util/dwarf-aux.c   |  9 
>  tools/perf/util/event.c   | 12 ++---
>  tools/perf/util/evsel.c   | 23 -
>  tools/perf/util/parse-events.c| 60 +++
>  tools/perf/util/thread_map.c  |  8 +--
>  14 files changed, 145 insertions(+), 85 deletions(-)
>  create mode 100644 tools/build/feature/test-dwarf_getlocations.c

Pulled, thanks a lot Arnaldo!

Ingo

[PATCH v2 3/4] ACPI 2.0 / AML: Enable correct ACPI subsystem initialization order for new table loading mode

[Lv Zheng]

This patch enables the following initialization order for the new table
loading mode (which is enabled by setting
acpi_gbl_parse_table_as_term_list to TRUE):
  1. Install default region handlers (SystemMemory, SystemIo, PciConfig,
 EmbeddedControl via ECDT) without evaluating _REG;
  2. Load the table and execute the module level AML opcodes instantly.

Signed-off-by: Lv Zheng 
---
 drivers/acpi/bus.c |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index 31e8da6..d177649 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -925,7 +925,8 @@ void __init acpi_early_init(void)
goto error0;
}
 
-   if (acpi_gbl_group_module_level_code) {
+   if (!acpi_gbl_parse_table_as_term_list &&
+   acpi_gbl_group_module_level_code) {
status = acpi_load_tables();
if (ACPI_FAILURE(status)) {
printk(KERN_ERR PREFIX
@@ -1008,7 +1009,8 @@ static int __init acpi_bus_init(void)
status = acpi_ec_ecdt_probe();
/* Ignore result. Not having an ECDT is not fatal. */
 
-   if (!acpi_gbl_group_module_level_code) {
+   if (acpi_gbl_parse_table_as_term_list ||
+   !acpi_gbl_group_module_level_code) {
status = acpi_load_tables();
if (ACPI_FAILURE(status)) {
printk(KERN_ERR PREFIX
-- 
1.7.10

Re: [GIT PULL 00/10] perf/urgent fixes

[Ingo Molnar]

* Arnaldo Carvalho de Melo  wrote:

> Hi Ingo,
> 
>   Please consider pulling, test built on:
> 
> alldeps-fedora-rawhide: Ok
> alldeps-ubuntu-14.04: Ok
> alldeps-ubuntu-16.04: Ok
> alldeps-fedora-20: Ok
> alldeps-ubuntu-12.04: Ok
> minimal-debian-experimental-x-mips64: Ok
> minimal-debian-experimental-x-mips64el: Ok
> minimal-debian-experimental-x-mipsel: Ok
> minimal-ubuntu-x-arm: Ok
> minimal-ubuntu-x-arm64: Ok
> minimal-ubuntu-x-ppc64: Ok
> minimal-ubuntu-x-ppc64el: Ok
> alldeps-debian: Ok
> alldeps-mageia: Ok
> alldeps-rhel7: Ok
> alldeps-centos: Ok
> alldeps-opensuse: Ok
> 
> - Arnaldo
> 
> The following changes since commit 9f448cd3cbcec8995935e60b27802ae56aac8cc0:
> 
>   perf/core: Disable the event on a truncated AUX record (2016-05-12 14:46:11 
> +0200)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git 
> tags/perf-urgent-for-mingo-20160512
> 
> for you to fetch changes up to 42ef8a78c1f49f53f29f0f3a6f9a5bcbc653233e:
> 
>   perf stat: Fallback to user only counters when perf_event_paranoid > 1 
> (2016-05-12 16:25:18 -0300)
> 
> 
> perf/urgent fixes:
> 
> User visible:
> 
> - Fallback to usermode only counters when perf_event_paranoid > 1, which
>   is the case now (Arnaldo Carvalho de Melo)
> 
> - Do not reassign parg after collapse_tree() in libtraceevent, which
>   may cause tool crashes (Steven Rostedt)
> 
> Build fixes:
> 
> - Fix the build on Fedora Rawhide, where readdir_r() is deprecated and
>   also wrt -Werror=unused-const-variable= + x86_32_regoffset_table on
>   !x86_64 (Arnaldo Carvalho de Melo)
> 
> - Fix the build on Ubuntu 12.04.5, where dwarf_getlocations() isn't
>   available, i.e. libdw-dev < 0.157 (Arnaldo Carvalho de Melo)
> 
> Signed-off-by: Arnaldo Carvalho de Melo 
> 
> 
> Arnaldo Carvalho de Melo (9):
>   perf tools: Use readdir() instead of deprecated readdir_r()
>   perf script: Use readdir() instead of deprecated readdir_r()
>   perf thread_map: Use readdir() instead of deprecated readdir_r()
>   perf tools: Use readdir() instead of deprecated readdir_r()
>   perf dwarf: Guard !x86_64 definitions under #ifdef else clause
>   perf probe: Check if dwarf_getlocations() is available
>   perf evsel: Improve EPERM error handling in open_strerror()
>   perf evsel: Handle EACCESS + perf_event_paranoid=2 in fallback()
>   perf stat: Fallback to user only counters when perf_event_paranoid > 1
> 
> Steven Rostedt (1):
>   tools lib traceevent: Do not reassign parg after collapse_tree()
> 
>  tools/build/Makefile.feature  |  2 +
>  tools/build/feature/Makefile  |  4 ++
>  tools/build/feature/test-all.c|  5 ++
>  tools/build/feature/test-dwarf_getlocations.c | 12 +
>  tools/lib/traceevent/parse-filter.c   |  4 +-
>  tools/perf/arch/x86/util/dwarf-regs.c |  8 +--
>  tools/perf/builtin-script.c   | 70 
> +--
>  tools/perf/builtin-stat.c |  7 ++-
>  tools/perf/config/Makefile|  6 +++
>  tools/perf/util/dwarf-aux.c   |  9 
>  tools/perf/util/event.c   | 12 ++---
>  tools/perf/util/evsel.c   | 23 -
>  tools/perf/util/parse-events.c| 60 +++
>  tools/perf/util/thread_map.c  |  8 +--
>  14 files changed, 145 insertions(+), 85 deletions(-)
>  create mode 100644 tools/build/feature/test-dwarf_getlocations.c

Pulled, thanks a lot Arnaldo!

Ingo

[PATCH v2 2/4] ACPICA: ACPI 2.0, Interpreter: Fix MLC issues by switching to new TermList grammar for table loading

[Lv Zheng]

The MLC (Module Level Code) is an ACPICA terminology describing the AML
code out of any control method, its support is the main contention of the
interpreter behavior during the table loading.

The original implementation of MLC in ACPICA had several issues:
1. Out of any control method, besides of the object creating opcodes, only
   the code blocks wrapped by "If/Else/While" opcodes were supported.
2. The supported MLC code blocks were executed after loading the table
   rather than being executed right in place.
   
   The demo of this order issue is as follows:
 Name (OBJ1, 1)
 If (CND1 == 1)
 {
   Name (OBJ2, 2)
 }
 Name (OBJ3, 3)
   The original MLC support created OBJ2 after OBJ3's creation.
   
Other than these limitations, MLC support in ACPICA looks correct. And
supporting this should be easy/natural for ACPICA, but enabling of this was
blocked by some ACPICA internal and OSPM specific initialization order
issues we've fixed recently. The wrong support started from the following
false bug fixing commit:
  Commit: 80d7951177315f70b5ffd8663985fbf725d07799
  Subject: Add support for module-level executable AML code.

We can confirm Windows interpreter behavior via reverse engineering means.
It can be proven that not only If/Else/While wrapped code blocks, all
opcodes can be executed at the module level, including operation region
accesses. And it can be proven that the MLC should be executed right in
place, not in such a deferred way executed after loading the table.

And the above facts indeed reflect the spec words around ACPI definition
block tables (DSDT/SSDT/...), the entire table and the Scope object is
defined by the AML specification in BNF style as:
  AMLCode := DefBlockHeader TermList
  DefScope := ScopeOp PkgLength NameString TermList
The bodies of the scope opening terms (AMLCode/Scope) are all TermList,
thus the table loading should be no difference than the control method
evaluations as the body of the Method is also defined by the AML
specification as TermList:
  DefMethod := MethodOp PkgLength NameString MethodFlags TermList
The only difference is: after evaluating control method, created named
objects may be freed due to no reference, while named objects created by
the table loading should only be freed after unloading the table.

So this patch follows the spec and the de-facto standard behavior, enables
the new grammar (TermList) for the table loading.

By doing so, beyond the fixes to the above issues, we can see additional
differences comparing to the old grammar based table loading:
1. Originally, beyond the scope opening terms (AMLCode/Scope),
   If/Else/While wrapped code blocks under the scope creating terms
   (Device/PowerResource/Processor/ThermalZone) are also supported as
   deferred MLC, which violates the spec defined grammar where ObjectList
   is enforced. With MLC support improved as non-deferred, the interpreter
   parses such scope creating terms as TermList rather ObjectList like the
   scope opening terms.
   After probing the Windows behavior and proving that it also parses these
   terms as TermList, we submitted an ECR (Engineering Change Request) to
   the ASWG (ACPI Specification Working Group) to clarify this. The ECR is
   titled as "ASL Grammar Clarification for Executable AML Opcodes" and has
   been accepted by the ASWG. The new grammar will appear in ACPI
   specification 6.2.
2. Originally, Buffer/Package/OperationRegion/CreateXXXField/BankField
   arguments are evaluated in a deferred way after loading the table. With
   MLC support improved, they are also parsed right in place during the
   table loading.
   This is also Windows compliant and the only difference is the removal
   of the debugging messages implemented before acpi_ds_execute_arguments(),
   see Link 1 for the details. A previous commit should have ensured that
   acpi_check_address_range() won't regress.

Note that enabling this feature may cause regressions due to long term
Linux ACPI support on top of the wrong grammar. So this patch also prepares
a global option to be used to roll back to the old grammar during the
period between a regression is reported and the regression is
root-cause-fixed. ACPICA BZ 963, fixed by Lv Zheng.

Link 1: https://bugzilla.kernel.org/show_bug.cgi?id=112911
Link 2: https://bugs.acpica.org/show_bug.cgi?id=963
Tested-by: Chris Bainbridge 
Signed-off-by: Lv Zheng 
---
 drivers/acpi/acpica/acnamesp.h |3 +
 drivers/acpi/acpica/acparser.h |2 +
 drivers/acpi/acpica/evrgnini.c |3 +-
 drivers/acpi/acpica/exconfig.c |6 +-
 drivers/acpi/acpica/nsload.c   |3 +-
 drivers/acpi/acpica/nsparse.c  |  163 
 drivers/acpi/acpica/psparse.c  |4 +-
 drivers/acpi/acpica/psxface.c  |   73 ++
 

[PATCH v2 2/4] ACPICA: ACPI 2.0, Interpreter: Fix MLC issues by switching to new TermList grammar for table loading

[Lv Zheng]

The MLC (Module Level Code) is an ACPICA terminology describing the AML
code out of any control method, its support is the main contention of the
interpreter behavior during the table loading.

The original implementation of MLC in ACPICA had several issues:
1. Out of any control method, besides of the object creating opcodes, only
   the code blocks wrapped by "If/Else/While" opcodes were supported.
2. The supported MLC code blocks were executed after loading the table
   rather than being executed right in place.
   
   The demo of this order issue is as follows:
 Name (OBJ1, 1)
 If (CND1 == 1)
 {
   Name (OBJ2, 2)
 }
 Name (OBJ3, 3)
   The original MLC support created OBJ2 after OBJ3's creation.
   
Other than these limitations, MLC support in ACPICA looks correct. And
supporting this should be easy/natural for ACPICA, but enabling of this was
blocked by some ACPICA internal and OSPM specific initialization order
issues we've fixed recently. The wrong support started from the following
false bug fixing commit:
  Commit: 80d7951177315f70b5ffd8663985fbf725d07799
  Subject: Add support for module-level executable AML code.

We can confirm Windows interpreter behavior via reverse engineering means.
It can be proven that not only If/Else/While wrapped code blocks, all
opcodes can be executed at the module level, including operation region
accesses. And it can be proven that the MLC should be executed right in
place, not in such a deferred way executed after loading the table.

And the above facts indeed reflect the spec words around ACPI definition
block tables (DSDT/SSDT/...), the entire table and the Scope object is
defined by the AML specification in BNF style as:
  AMLCode := DefBlockHeader TermList
  DefScope := ScopeOp PkgLength NameString TermList
The bodies of the scope opening terms (AMLCode/Scope) are all TermList,
thus the table loading should be no difference than the control method
evaluations as the body of the Method is also defined by the AML
specification as TermList:
  DefMethod := MethodOp PkgLength NameString MethodFlags TermList
The only difference is: after evaluating control method, created named
objects may be freed due to no reference, while named objects created by
the table loading should only be freed after unloading the table.

So this patch follows the spec and the de-facto standard behavior, enables
the new grammar (TermList) for the table loading.

By doing so, beyond the fixes to the above issues, we can see additional
differences comparing to the old grammar based table loading:
1. Originally, beyond the scope opening terms (AMLCode/Scope),
   If/Else/While wrapped code blocks under the scope creating terms
   (Device/PowerResource/Processor/ThermalZone) are also supported as
   deferred MLC, which violates the spec defined grammar where ObjectList
   is enforced. With MLC support improved as non-deferred, the interpreter
   parses such scope creating terms as TermList rather ObjectList like the
   scope opening terms.
   After probing the Windows behavior and proving that it also parses these
   terms as TermList, we submitted an ECR (Engineering Change Request) to
   the ASWG (ACPI Specification Working Group) to clarify this. The ECR is
   titled as "ASL Grammar Clarification for Executable AML Opcodes" and has
   been accepted by the ASWG. The new grammar will appear in ACPI
   specification 6.2.
2. Originally, Buffer/Package/OperationRegion/CreateXXXField/BankField
   arguments are evaluated in a deferred way after loading the table. With
   MLC support improved, they are also parsed right in place during the
   table loading.
   This is also Windows compliant and the only difference is the removal
   of the debugging messages implemented before acpi_ds_execute_arguments(),
   see Link 1 for the details. A previous commit should have ensured that
   acpi_check_address_range() won't regress.

Note that enabling this feature may cause regressions due to long term
Linux ACPI support on top of the wrong grammar. So this patch also prepares
a global option to be used to roll back to the old grammar during the
period between a regression is reported and the regression is
root-cause-fixed. ACPICA BZ 963, fixed by Lv Zheng.

Link 1: https://bugzilla.kernel.org/show_bug.cgi?id=112911
Link 2: https://bugs.acpica.org/show_bug.cgi?id=963
Tested-by: Chris Bainbridge 
Signed-off-by: Lv Zheng 
---
 drivers/acpi/acpica/acnamesp.h |3 +
 drivers/acpi/acpica/acparser.h |2 +
 drivers/acpi/acpica/evrgnini.c |3 +-
 drivers/acpi/acpica/exconfig.c |6 +-
 drivers/acpi/acpica/nsload.c   |3 +-
 drivers/acpi/acpica/nsparse.c  |  163 
 drivers/acpi/acpica/psparse.c  |4 +-
 drivers/acpi/acpica/psxface.c  |   73 ++
 drivers/acpi/acpica/tbxfload.c |3 +-
 

[PATCH v2 0/4] ACPI 2.0: Enable TermList interpretion for table loading

[Lv Zheng]

MLC (module level code) is an ACPICA terminology describing the AML code
out of any control method, currently only Type1Opcode (If/Else/While)
wrapped MLC code blocks are executed by the AML interpreter after the table
loading. But the issue which is fixed by this patchset is:
   Not only Type1Opcode, but also Type2Opcode will be executed as MLC and
   MLC is not executed after loading the table, but is executed right in
   place.

The following AML code is assembled into a static loading SSDT, and used
as an instrumentation to pry into the de-facto standard AML interpreter
behaviors:
  Name (ECOK, Zero)
  Scope (\)
  {
  DBUG ("TermList 1")
  If (LEqual (ECOK, Zero))
  {
  DBUG ("TermList 2")
  Device (MDEV)
  {
  DEBUG (TermList 3")
  If (CondRefOf (MDEV))
  {
  DBUG ("MDEV exists")
  }
  If (CondRefOf (MDEV._STA))
  {
  DBUG ("MDEV._STA exists")
  }
  If (CondRefOf (\_SB.PCI0.EC))
  {
  DBUG ("\\_SB.PCI0.EC exists")
  }
  Name (_HID, EisaId ("PNP"))
  Method (_STA, 0, Serialized)
  {
  DEBUG ("\\_SB.MDEV._STA")
  Return (0x0F)
  }
  }
  DBUG ("TermList 4")
  }
  Method (_INI, 0, Serialized)
  {
  DBUG ("\\_SB._INI")
  }
  }
  Scope (_SB.PCI0)
  {
  Device (EC)
  {
  ...
  }
  }
The DBUG function is a function to write the debugging messages into a
SystemIo debug port.
Running Windows with the BIOS providing this SSDT via RSDT, the following
messages are obtained from the debug port:
  TermList 1
  TermList 2
  TermList 3
  \_SB.MDEV exists
  TermList 4
  \_SB._INI
  ...

This test reveals the de-facto grammar for the AMLCode to us:
1. During the table loading, MLC will be executed by the interpreter, this
   is partially supported by the current ACPICA;
2. For SystemIo, not only after the _REG(1, 1) is evaluated (current ACPICA
   interpreter limitation), but when the table is being loaded, the
   SystemIo (the debugging port) is accessible, this is recently fixed in
   the upstream, now all early operation regions are accessible during the
   table loading;
3. Not only Type1Opcode, but also Type2Opcode will be executed as MLC and
   MLC is not executed after loading the table, but is executed right in
   place, the Linux upstream is not compliant to this behavior.

The last compliance issue has already been clarified in ACPI 2.0
specification, so the compliance issue is not that Linux is not compliant
to the de-facto standard OS, but that Linux is not compliant to ACPI 2.0.
Definition block tables in fact is defined by the spec as TermList, which
has no difference than the control methods, thus the interpretion of the
table should be no difference that the control method evaluation:
 AMLCode := DefBlockHeader TermList
 DefMethod := MethodOp PkgLength NameString MethodFlags TermList

Why ACPICA interpreter is acting so differently from this definition? This
is because, there are many software entropies preventing this from being
enabled, such entropies need to be cleaned up first in order not to trigger
regressions for specific platforms. These entropies include:
1. ECDT support is broken. In fact, the original EC driver was correct, but
   devlopers started to use the namespace EC instead of ECDT just because
   several broken ECDT tables were reported on the bugzilla. They trusted
   the namespace EC settings rather than the ECDT ones, this led to the
   evaluation of _REG/_GPE/_CRS and namespace walk before executing the
   module level AML opcodes. And the fixes in fact finally disable early EC
   usages (used during table loading and early device enumeration
   processes).
2. _REG evaluations are wrong. ACPICA provides APIs for OSPMs to register
   operation region handlers. But for the early operation region accesses,
   ACPI spec declares that the evaluations of _REG are not required, but
   the ACPICA APIs do not avoid running _REG to meet this early
   requirements. Code to fix this is partially upstreamed during previous
   ACPICA release cycle.
3. _REG associations are wrong. ACPICA associates _REG control method to
   all operation region objects before executing the _REG control method.
   This can happen even when a control method is evaluated and operation
   regions defined in the method is initialized
   (acpi_ev_initialize_region). As a part of the ACPICA internal _REG
   evaluation state machine, it requires the namespace walk, and all
   namespace walk should be ensured to happen only "AFTER THE NAMESPACE IS
   INITIALIZED". But when this logic happens during the table loading, it
   may fail in finding the _REG method since the _REG method may not be
   created by the interpreter just because _REG is defined after the
   operation 

[PATCH v2 1/4] ACPICA: Dispatcher: Fix an issue that the opregions created by the linked MLC were not tracked

[Lv Zheng]

Operation regions created by MLC were not tracked by
acpi_check_address_range(), this patch fixes this issue. ACPICA BZ 1279. Fixed
by Lv Zheng.

Link: https://bugs.acpica.org/show_bug.cgi?id=1279
Signed-off-by: Lv Zheng 
---
 drivers/acpi/acpica/dsopcode.c |6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/acpi/acpica/dsopcode.c b/drivers/acpi/acpica/dsopcode.c
index 4cc9d98..96f2eef 100644
--- a/drivers/acpi/acpica/dsopcode.c
+++ b/drivers/acpi/acpica/dsopcode.c
@@ -455,6 +455,12 @@ acpi_ds_eval_region_operands(struct acpi_walk_state 
*walk_state,
/* Now the address and length are valid for this opregion */
 
obj_desc->region.flags |= AOPOBJ_DATA_VALID;
+   if (walk_state->parse_flags & ACPI_PARSE_MODULE_LEVEL) {
+   status = acpi_ut_add_address_range(obj_desc->region.space_id,
+  obj_desc->region.address,
+  obj_desc->region.length,
+  node);
+   }
return_ACPI_STATUS(status);
 }
 
-- 
1.7.10

[PATCH v2 0/4] ACPI 2.0: Enable TermList interpretion for table loading

[Lv Zheng]

MLC (module level code) is an ACPICA terminology describing the AML code
out of any control method, currently only Type1Opcode (If/Else/While)
wrapped MLC code blocks are executed by the AML interpreter after the table
loading. But the issue which is fixed by this patchset is:
   Not only Type1Opcode, but also Type2Opcode will be executed as MLC and
   MLC is not executed after loading the table, but is executed right in
   place.

The following AML code is assembled into a static loading SSDT, and used
as an instrumentation to pry into the de-facto standard AML interpreter
behaviors:
  Name (ECOK, Zero)
  Scope (\)
  {
  DBUG ("TermList 1")
  If (LEqual (ECOK, Zero))
  {
  DBUG ("TermList 2")
  Device (MDEV)
  {
  DEBUG (TermList 3")
  If (CondRefOf (MDEV))
  {
  DBUG ("MDEV exists")
  }
  If (CondRefOf (MDEV._STA))
  {
  DBUG ("MDEV._STA exists")
  }
  If (CondRefOf (\_SB.PCI0.EC))
  {
  DBUG ("\\_SB.PCI0.EC exists")
  }
  Name (_HID, EisaId ("PNP"))
  Method (_STA, 0, Serialized)
  {
  DEBUG ("\\_SB.MDEV._STA")
  Return (0x0F)
  }
  }
  DBUG ("TermList 4")
  }
  Method (_INI, 0, Serialized)
  {
  DBUG ("\\_SB._INI")
  }
  }
  Scope (_SB.PCI0)
  {
  Device (EC)
  {
  ...
  }
  }
The DBUG function is a function to write the debugging messages into a
SystemIo debug port.
Running Windows with the BIOS providing this SSDT via RSDT, the following
messages are obtained from the debug port:
  TermList 1
  TermList 2
  TermList 3
  \_SB.MDEV exists
  TermList 4
  \_SB._INI
  ...

This test reveals the de-facto grammar for the AMLCode to us:
1. During the table loading, MLC will be executed by the interpreter, this
   is partially supported by the current ACPICA;
2. For SystemIo, not only after the _REG(1, 1) is evaluated (current ACPICA
   interpreter limitation), but when the table is being loaded, the
   SystemIo (the debugging port) is accessible, this is recently fixed in
   the upstream, now all early operation regions are accessible during the
   table loading;
3. Not only Type1Opcode, but also Type2Opcode will be executed as MLC and
   MLC is not executed after loading the table, but is executed right in
   place, the Linux upstream is not compliant to this behavior.

The last compliance issue has already been clarified in ACPI 2.0
specification, so the compliance issue is not that Linux is not compliant
to the de-facto standard OS, but that Linux is not compliant to ACPI 2.0.
Definition block tables in fact is defined by the spec as TermList, which
has no difference than the control methods, thus the interpretion of the
table should be no difference that the control method evaluation:
 AMLCode := DefBlockHeader TermList
 DefMethod := MethodOp PkgLength NameString MethodFlags TermList

Why ACPICA interpreter is acting so differently from this definition? This
is because, there are many software entropies preventing this from being
enabled, such entropies need to be cleaned up first in order not to trigger
regressions for specific platforms. These entropies include:
1. ECDT support is broken. In fact, the original EC driver was correct, but
   devlopers started to use the namespace EC instead of ECDT just because
   several broken ECDT tables were reported on the bugzilla. They trusted
   the namespace EC settings rather than the ECDT ones, this led to the
   evaluation of _REG/_GPE/_CRS and namespace walk before executing the
   module level AML opcodes. And the fixes in fact finally disable early EC
   usages (used during table loading and early device enumeration
   processes).
2. _REG evaluations are wrong. ACPICA provides APIs for OSPMs to register
   operation region handlers. But for the early operation region accesses,
   ACPI spec declares that the evaluations of _REG are not required, but
   the ACPICA APIs do not avoid running _REG to meet this early
   requirements. Code to fix this is partially upstreamed during previous
   ACPICA release cycle.
3. _REG associations are wrong. ACPICA associates _REG control method to
   all operation region objects before executing the _REG control method.
   This can happen even when a control method is evaluated and operation
   regions defined in the method is initialized
   (acpi_ev_initialize_region). As a part of the ACPICA internal _REG
   evaluation state machine, it requires the namespace walk, and all
   namespace walk should be ensured to happen only "AFTER THE NAMESPACE IS
   INITIALIZED". But when this logic happens during the table loading, it
   may fail in finding the _REG method since the _REG method may not be
   created by the interpreter just because _REG is defined after the
   operation 

[PATCH v2 1/4] ACPICA: Dispatcher: Fix an issue that the opregions created by the linked MLC were not tracked

[Lv Zheng]

Operation regions created by MLC were not tracked by
acpi_check_address_range(), this patch fixes this issue. ACPICA BZ 1279. Fixed
by Lv Zheng.

Link: https://bugs.acpica.org/show_bug.cgi?id=1279
Signed-off-by: Lv Zheng 
---
 drivers/acpi/acpica/dsopcode.c |6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/acpi/acpica/dsopcode.c b/drivers/acpi/acpica/dsopcode.c
index 4cc9d98..96f2eef 100644
--- a/drivers/acpi/acpica/dsopcode.c
+++ b/drivers/acpi/acpica/dsopcode.c
@@ -455,6 +455,12 @@ acpi_ds_eval_region_operands(struct acpi_walk_state 
*walk_state,
/* Now the address and length are valid for this opregion */
 
obj_desc->region.flags |= AOPOBJ_DATA_VALID;
+   if (walk_state->parse_flags & ACPI_PARSE_MODULE_LEVEL) {
+   status = acpi_ut_add_address_range(obj_desc->region.space_id,
+  obj_desc->region.address,
+  obj_desc->region.length,
+  node);
+   }
return_ACPI_STATUS(status);
 }
 
-- 
1.7.10

Re: [PATCH 5/5] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported

[Alex Williamson]

On Fri, 13 May 2016 02:33:18 +
"Tian, Kevin"  wrote:

> > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > Sent: Friday, May 13, 2016 1:48 AM
> > 
> > On Thu, 12 May 2016 04:53:19 +
> > "Tian, Kevin"  wrote:
> >   
> > > > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > > > Sent: Thursday, May 12, 2016 10:21 AM
> > > >
> > > > On Thu, 12 May 2016 01:19:44 +
> > > > "Tian, Kevin"  wrote:
> > > >  
> > > > > > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > > > > > Sent: Wednesday, May 11, 2016 11:54 PM
> > > > > >
> > > > > > On Wed, 11 May 2016 06:29:06 +
> > > > > > "Tian, Kevin"  wrote:
> > > > > >  
> > > > > > > > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > > > > > > > Sent: Thursday, May 05, 2016 11:05 PM
> > > > > > > >
> > > > > > > > On Thu, 5 May 2016 12:15:46 +
> > > > > > > > "Tian, Kevin"  wrote:
> > > > > > > >  
> > > > > > > > > > From: Yongji Xie [mailto:xyj...@linux.vnet.ibm.com]
> > > > > > > > > > Sent: Thursday, May 05, 2016 7:43 PM
> > > > > > > > > >
> > > > > > > > > > Hi David and Kevin,
> > > > > > > > > >
> > > > > > > > > > On 2016/5/5 17:54, David Laight wrote:
> > > > > > > > > >  
> > > > > > > > > > > From: Tian, Kevin  
> > > > > > > > > > >> Sent: 05 May 2016 10:37  
> > > > > > > > > > > ...  
> > > > > > > > > > >>> Acutually, we are not aimed at accessing MSI-X table 
> > > > > > > > > > >>> from
> > > > > > > > > > >>> guest. So I think it's safe to passthrough MSI-X table 
> > > > > > > > > > >>> if we
> > > > > > > > > > >>> can make sure guest kernel would not touch MSI-X table 
> > > > > > > > > > >>> in
> > > > > > > > > > >>> normal code path such as para-virtualized guest kernel 
> > > > > > > > > > >>> on PPC64.
> > > > > > > > > > >>>  
> > > > > > > > > > >> Then how do you prevent malicious guest kernel accessing 
> > > > > > > > > > >> it?  
> > > > > > > > > > > Or a malicious guest driver for an ethernet card setting 
> > > > > > > > > > > up
> > > > > > > > > > > the receive buffer ring to contain a single word entry 
> > > > > > > > > > > that
> > > > > > > > > > > contains the address associated with an MSI-X interrupt 
> > > > > > > > > > > and
> > > > > > > > > > > then using a loopback mode to cause a specific packet be
> > > > > > > > > > > received that writes the required word through that 
> > > > > > > > > > > address.
> > > > > > > > > > >
> > > > > > > > > > > Remember the PCIe cycle for an interrupt is a normal 
> > > > > > > > > > > memory write
> > > > > > > > > > > cycle.
> > > > > > > > > > >
> > > > > > > > > > >   David
> > > > > > > > > > >  
> > > > > > > > > >
> > > > > > > > > > If we have enough permission to load a malicious driver or
> > > > > > > > > > kernel, we can easily break the guest without exposed
> > > > > > > > > > MSI-X table.
> > > > > > > > > >
> > > > > > > > > > I think it should be safe to expose MSI-X table if we can
> > > > > > > > > > make sure that malicious guest driver/kernel can't use
> > > > > > > > > > the MSI-X table to break other guest or host. The
> > > > > > > > > > capability of IRQ remapping could provide this
> > > > > > > > > > kind of protection.
> > > > > > > > > >  
> > > > > > > > >
> > > > > > > > > With IRQ remapping it doesn't mean you can pass through MSI-X
> > > > > > > > > structure to guest. I know actual IRQ remapping might be 
> > > > > > > > > platform
> > > > > > > > > specific, but at least for Intel VT-d specification, MSI-X 
> > > > > > > > > entry must
> > > > > > > > > be configured with a remappable format by host kernel which
> > > > > > > > > contains an index into IRQ remapping table. The index will 
> > > > > > > > > find a
> > > > > > > > > IRQ remapping entry which controls interrupt routing for a 
> > > > > > > > > specific
> > > > > > > > > device. If you allow a malicious program random index into 
> > > > > > > > > MSI-X
> > > > > > > > > entry of assigned device, the hole is obvious...
> > > > > > > > >
> > > > > > > > > Above might make sense only for a IRQ remapping implementation
> > > > > > > > > which doesn't rely on extended MSI-X format (e.g. simply 
> > > > > > > > > based on
> > > > > > > > > BDF). If that's the case for PPC, then you should build MSI-X
> > > > > > > > > passthrough based on this fact instead of general IRQ 
> > > > > > > > > remapping
> > > > > > > > > enabled or not.  
> > > > > > > >
> > > > > > > > I don't think anyone is expecting that we can expose the MSI-X 
> > > > > > > > vector
> > > > > > > > table to the guest and the guest can make direct use of it.  
> > > > > > > > The end
> > > > > > > > goal here is that the guest on a power system is already
> > > > > > > > paravirtualized to not program the device MSI-X by directly 
> > > > > > > > writing to
> > > > > > > > the MSI-X vector table.  They have hypercalls for this since 
> > > > > > > 

Re: [PATCH 5/5] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported

[Alex Williamson]

On Fri, 13 May 2016 02:33:18 +
"Tian, Kevin"  wrote:

> > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > Sent: Friday, May 13, 2016 1:48 AM
> > 
> > On Thu, 12 May 2016 04:53:19 +
> > "Tian, Kevin"  wrote:
> >   
> > > > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > > > Sent: Thursday, May 12, 2016 10:21 AM
> > > >
> > > > On Thu, 12 May 2016 01:19:44 +
> > > > "Tian, Kevin"  wrote:
> > > >  
> > > > > > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > > > > > Sent: Wednesday, May 11, 2016 11:54 PM
> > > > > >
> > > > > > On Wed, 11 May 2016 06:29:06 +
> > > > > > "Tian, Kevin"  wrote:
> > > > > >  
> > > > > > > > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > > > > > > > Sent: Thursday, May 05, 2016 11:05 PM
> > > > > > > >
> > > > > > > > On Thu, 5 May 2016 12:15:46 +
> > > > > > > > "Tian, Kevin"  wrote:
> > > > > > > >  
> > > > > > > > > > From: Yongji Xie [mailto:xyj...@linux.vnet.ibm.com]
> > > > > > > > > > Sent: Thursday, May 05, 2016 7:43 PM
> > > > > > > > > >
> > > > > > > > > > Hi David and Kevin,
> > > > > > > > > >
> > > > > > > > > > On 2016/5/5 17:54, David Laight wrote:
> > > > > > > > > >  
> > > > > > > > > > > From: Tian, Kevin  
> > > > > > > > > > >> Sent: 05 May 2016 10:37  
> > > > > > > > > > > ...  
> > > > > > > > > > >>> Acutually, we are not aimed at accessing MSI-X table 
> > > > > > > > > > >>> from
> > > > > > > > > > >>> guest. So I think it's safe to passthrough MSI-X table 
> > > > > > > > > > >>> if we
> > > > > > > > > > >>> can make sure guest kernel would not touch MSI-X table 
> > > > > > > > > > >>> in
> > > > > > > > > > >>> normal code path such as para-virtualized guest kernel 
> > > > > > > > > > >>> on PPC64.
> > > > > > > > > > >>>  
> > > > > > > > > > >> Then how do you prevent malicious guest kernel accessing 
> > > > > > > > > > >> it?  
> > > > > > > > > > > Or a malicious guest driver for an ethernet card setting 
> > > > > > > > > > > up
> > > > > > > > > > > the receive buffer ring to contain a single word entry 
> > > > > > > > > > > that
> > > > > > > > > > > contains the address associated with an MSI-X interrupt 
> > > > > > > > > > > and
> > > > > > > > > > > then using a loopback mode to cause a specific packet be
> > > > > > > > > > > received that writes the required word through that 
> > > > > > > > > > > address.
> > > > > > > > > > >
> > > > > > > > > > > Remember the PCIe cycle for an interrupt is a normal 
> > > > > > > > > > > memory write
> > > > > > > > > > > cycle.
> > > > > > > > > > >
> > > > > > > > > > >   David
> > > > > > > > > > >  
> > > > > > > > > >
> > > > > > > > > > If we have enough permission to load a malicious driver or
> > > > > > > > > > kernel, we can easily break the guest without exposed
> > > > > > > > > > MSI-X table.
> > > > > > > > > >
> > > > > > > > > > I think it should be safe to expose MSI-X table if we can
> > > > > > > > > > make sure that malicious guest driver/kernel can't use
> > > > > > > > > > the MSI-X table to break other guest or host. The
> > > > > > > > > > capability of IRQ remapping could provide this
> > > > > > > > > > kind of protection.
> > > > > > > > > >  
> > > > > > > > >
> > > > > > > > > With IRQ remapping it doesn't mean you can pass through MSI-X
> > > > > > > > > structure to guest. I know actual IRQ remapping might be 
> > > > > > > > > platform
> > > > > > > > > specific, but at least for Intel VT-d specification, MSI-X 
> > > > > > > > > entry must
> > > > > > > > > be configured with a remappable format by host kernel which
> > > > > > > > > contains an index into IRQ remapping table. The index will 
> > > > > > > > > find a
> > > > > > > > > IRQ remapping entry which controls interrupt routing for a 
> > > > > > > > > specific
> > > > > > > > > device. If you allow a malicious program random index into 
> > > > > > > > > MSI-X
> > > > > > > > > entry of assigned device, the hole is obvious...
> > > > > > > > >
> > > > > > > > > Above might make sense only for a IRQ remapping implementation
> > > > > > > > > which doesn't rely on extended MSI-X format (e.g. simply 
> > > > > > > > > based on
> > > > > > > > > BDF). If that's the case for PPC, then you should build MSI-X
> > > > > > > > > passthrough based on this fact instead of general IRQ 
> > > > > > > > > remapping
> > > > > > > > > enabled or not.  
> > > > > > > >
> > > > > > > > I don't think anyone is expecting that we can expose the MSI-X 
> > > > > > > > vector
> > > > > > > > table to the guest and the guest can make direct use of it.  
> > > > > > > > The end
> > > > > > > > goal here is that the guest on a power system is already
> > > > > > > > paravirtualized to not program the device MSI-X by directly 
> > > > > > > > writing to
> > > > > > > > the MSI-X vector table.  They have hypercalls for this since 
> > > > > > > > they
> > > > > > > > always run virtualized.  Therefore a) they never intend to 
> > > > > > > > touch the
> 

[PATCH V12 1/2] pinctrl: add DT binding doc for pincontrol of PMIC max77620/max20024

[Laxman Dewangan]

Maxim Semiconductor's PMIC MAX77620/MAX20024 has 8 GPIO pins
which act as GPIO as well as special function mode.

Add DT binding document to configure pins in function mode as
well as pin configuration parameters.

Signed-off-by: Laxman Dewangan 
Acked-by: Rob Herring 
Acked-by: Linus Walleij 

---
This was part of the max77620 series and mfd is merged. So it
can go in subsystem wise.

Changes from V4:
- Separate out from pincontrol driver

Changes from V5:
- Starting patch title with pinctrl instead of DT:pinctrl

Changes from V6/V7:
- None

Changes on V8:
- Collected Ack from Linus.

Changes from V9/10:
None
---
 .../bindings/pinctrl/pinctrl-max77620.txt  | 127 +
 1 file changed, 127 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/pinctrl/pinctrl-max77620.txt

diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-max77620.txt 
b/Documentation/devicetree/bindings/pinctrl/pinctrl-max77620.txt
new file mode 100644
index 000..ad4fce3
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-max77620.txt
@@ -0,0 +1,127 @@
+Pincontrol driver for MAX77620 Power management IC from Maxim Semiconductor.
+
+Device has 8 GPIO pins which can be configured as GPIO as well as the
+special IO functions.
+
+Please refer file 
+for details of the common pinctrl bindings used by client devices,
+including the meaning of the phrase "pin configuration node".
+
+Optional Pinmux properties:
+--
+Following properties are required if default setting of pins are required
+at boot.
+- pinctrl-names: A pinctrl state named per .
+- pinctrl[0...n]: Properties to contain the phandle for pinctrl states per
+   .
+
+The pin configurations are defined as child of the pinctrl states node. Each
+sub-node have following properties:
+
+Required properties:
+--
+- pins: List of pins. Valid values of pins properties are:
+ gpio0, gpio1, gpio2, gpio3, gpio4, gpio5, gpio6, gpio7.
+
+Optional properties:
+---
+Following are optional properties defined as pinmux DT binding document
+. Absence of properties will leave the configuration
+on default.
+   function,
+   drive-push-pull,
+   drive-open-drain,
+   bias-pull-up,
+   bias-pull-down.
+
+Valid values for function properties are:
+   gpio, lpm-control-in, fps-out, 32k-out, sd0-dvs-in, sd1-dvs-in,
+   reference-out
+
+Theres is also customised properties for the GPIO1, GPIO2 and GPIO3. These
+customised properties are required to configure FPS configuration parameters
+of these GPIOs. Please refer  for more
+detail of Flexible Power Sequence (FPS).
+
+- maxim,active-fps-source: FPS source for the GPIOs to get
+   enabled/disabled when system is in
+   active state.  Valid values are:
+   - MAX77620_FPS_SRC_0,
+   FPS source is FPS0.
+   - MAX77620_FPS_SRC_1,
+   FPS source is FPS1
+   - MAX77620_FPS_SRC_2 and
+   FPS source is FPS2
+   - MAX77620_FPS_SRC_NONE.
+   GPIO is not controlled
+   by FPS events and it gets
+   enabled/disabled by register
+   access.
+   Absence of this property will leave
+   the FPS configuration register for that
+   GPIO to default configuration.
+
+- maxim,active-fps-power-up-slot:  Sequencing event slot number on which
+   the GPIO get enabled when
+   master FPS input event set to HIGH.
+   Valid values are 0 to 7.
+   This is applicable if FPS source is
+   selected as FPS0, FPS1 or FPS2.
+
+- maxim,active-fps-power-down-slot:Sequencing event slot number on which
+   the GPIO get disabled when master
+   FPS input event set to LOW.
+   Valid values are 0 to 7.
+   This is applicable if FPS source is
+   selected as FPS0, FPS1 or FPS2.
+
+- maxim,suspend-fps-source:This is same as property
+   "maxim,active-fps-source" but value
+   

[PATCH V12 1/2] pinctrl: add DT binding doc for pincontrol of PMIC max77620/max20024

[Laxman Dewangan]

Maxim Semiconductor's PMIC MAX77620/MAX20024 has 8 GPIO pins
which act as GPIO as well as special function mode.

Add DT binding document to configure pins in function mode as
well as pin configuration parameters.

Signed-off-by: Laxman Dewangan 
Acked-by: Rob Herring 
Acked-by: Linus Walleij 

---
This was part of the max77620 series and mfd is merged. So it
can go in subsystem wise.

Changes from V4:
- Separate out from pincontrol driver

Changes from V5:
- Starting patch title with pinctrl instead of DT:pinctrl

Changes from V6/V7:
- None

Changes on V8:
- Collected Ack from Linus.

Changes from V9/10:
None
---
 .../bindings/pinctrl/pinctrl-max77620.txt  | 127 +
 1 file changed, 127 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/pinctrl/pinctrl-max77620.txt

diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-max77620.txt 
b/Documentation/devicetree/bindings/pinctrl/pinctrl-max77620.txt
new file mode 100644
index 000..ad4fce3
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-max77620.txt
@@ -0,0 +1,127 @@
+Pincontrol driver for MAX77620 Power management IC from Maxim Semiconductor.
+
+Device has 8 GPIO pins which can be configured as GPIO as well as the
+special IO functions.
+
+Please refer file 
+for details of the common pinctrl bindings used by client devices,
+including the meaning of the phrase "pin configuration node".
+
+Optional Pinmux properties:
+--
+Following properties are required if default setting of pins are required
+at boot.
+- pinctrl-names: A pinctrl state named per .
+- pinctrl[0...n]: Properties to contain the phandle for pinctrl states per
+   .
+
+The pin configurations are defined as child of the pinctrl states node. Each
+sub-node have following properties:
+
+Required properties:
+--
+- pins: List of pins. Valid values of pins properties are:
+ gpio0, gpio1, gpio2, gpio3, gpio4, gpio5, gpio6, gpio7.
+
+Optional properties:
+---
+Following are optional properties defined as pinmux DT binding document
+. Absence of properties will leave the configuration
+on default.
+   function,
+   drive-push-pull,
+   drive-open-drain,
+   bias-pull-up,
+   bias-pull-down.
+
+Valid values for function properties are:
+   gpio, lpm-control-in, fps-out, 32k-out, sd0-dvs-in, sd1-dvs-in,
+   reference-out
+
+Theres is also customised properties for the GPIO1, GPIO2 and GPIO3. These
+customised properties are required to configure FPS configuration parameters
+of these GPIOs. Please refer  for more
+detail of Flexible Power Sequence (FPS).
+
+- maxim,active-fps-source: FPS source for the GPIOs to get
+   enabled/disabled when system is in
+   active state.  Valid values are:
+   - MAX77620_FPS_SRC_0,
+   FPS source is FPS0.
+   - MAX77620_FPS_SRC_1,
+   FPS source is FPS1
+   - MAX77620_FPS_SRC_2 and
+   FPS source is FPS2
+   - MAX77620_FPS_SRC_NONE.
+   GPIO is not controlled
+   by FPS events and it gets
+   enabled/disabled by register
+   access.
+   Absence of this property will leave
+   the FPS configuration register for that
+   GPIO to default configuration.
+
+- maxim,active-fps-power-up-slot:  Sequencing event slot number on which
+   the GPIO get enabled when
+   master FPS input event set to HIGH.
+   Valid values are 0 to 7.
+   This is applicable if FPS source is
+   selected as FPS0, FPS1 or FPS2.
+
+- maxim,active-fps-power-down-slot:Sequencing event slot number on which
+   the GPIO get disabled when master
+   FPS input event set to LOW.
+   Valid values are 0 to 7.
+   This is applicable if FPS source is
+   selected as FPS0, FPS1 or FPS2.
+
+- maxim,suspend-fps-source:This is same as property
+   "maxim,active-fps-source" but value
+   get configured when system enters in
+ 

[PATCH V12 2/2] gpio: max77620: add gpio driver for MAX77620/MAX20024

[Laxman Dewangan]

MAXIM Semiconductor's PMIC, MAX77620/MAX20024 has 8 GPIO
pins. It also supports interrupts from these pins.

Add GPIO driver for these pins to control via GPIO APIs.

Signed-off-by: Laxman Dewangan 
Reviewed-by: Linus Walleij 

---
This as part of the max77620 series and mfd patch are already applied.
This can go in subsystem branch.

Changes from V1:
- Use the gpiochip_add_data and get the chip data from core APIs.
- Cleanups based on comment received on mfd/rtc.
- Avoid duplication on error message.

Changes form V2:
- Run coccicheck and checkpatch in strict mode for the alignment.
- update based on api changes from core.

Changes from V3:
- Change all sys initcall to module driver.
- change the max77620_read argument to unisgned int from u8.

Changes from V4:
- Added DT binding document as devicetree/bindings/gpio/gpio-max77620.txt

Changes from V5:
- Separate out DT binding doc for gpio.
- Added reviewed by for Linus W

Changes from V6/V7:
- None

Changes from V8:
- Run checkpatch --strict and fix error. Mostly to use unsigned int instead
  of unsigned.
- Use linux/gpio/driver.h

Changes from V9:
- Use devm_regmap_add_irq_chip() and devm_gpiochip_add_data()

Changes from V10:
None

Changes from V11:
- Change bool to tristate in CONFIG
---
 drivers/gpio/Kconfig |   9 ++
 drivers/gpio/Makefile|   1 +
 drivers/gpio/gpio-max77620.c | 238 +++
 3 files changed, 248 insertions(+)
 create mode 100644 drivers/gpio/gpio-max77620.c

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 48da857..9244381 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -870,6 +870,15 @@ config GPIO_LP3943
  LP3943 can be used as a GPIO expander which provides up to 16 GPIOs.
  Open drain outputs are required for this usage.
 
+config GPIO_MAX77620
+   tristate "GPIO support for PMIC MAX77620 and MAX20024"
+   depends on MFD_MAX77620
+   help
+ GPIO driver for MAX77620 and MAX20024 PMIC from Maxim Semiconductor.
+ MAX77620 PMIC has 8 pins that can be configured as GPIOs. The
+ driver also provides interrupt support for each of the gpios.
+ Say yes here to enable the max77620 to be used as gpio controller.
+
 config GPIO_MSIC
bool "Intel MSIC mixed signal gpio support"
depends on MFD_INTEL_MSIC
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 991598e..6e111fc 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -61,6 +61,7 @@ obj-$(CONFIG_GPIO_MAX730X)+= gpio-max730x.o
 obj-$(CONFIG_GPIO_MAX7300) += gpio-max7300.o
 obj-$(CONFIG_GPIO_MAX7301) += gpio-max7301.o
 obj-$(CONFIG_GPIO_MAX732X) += gpio-max732x.o
+obj-$(CONFIG_GPIO_MAX77620)+= gpio-max77620.o
 obj-$(CONFIG_GPIO_MB86S7X) += gpio-mb86s7x.o
 obj-$(CONFIG_GPIO_MENZ127) += gpio-menz127.o
 obj-$(CONFIG_GPIO_MC33880) += gpio-mc33880.o
diff --git a/drivers/gpio/gpio-max77620.c b/drivers/gpio/gpio-max77620.c
new file mode 100644
index 000..d927562
--- /dev/null
+++ b/drivers/gpio/gpio-max77620.c
@@ -0,0 +1,238 @@
+/*
+ * MAXIM MAX77620 GPIO driver
+ *
+ * Copyright (c) 2016, NVIDIA CORPORATION.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define GPIO_REG_ADDR(offset) (MAX77620_REG_GPIO0 + offset)
+
+struct max77620_gpio {
+   struct gpio_chipgpio_chip;
+   struct regmap   *rmap;
+   struct device   *dev;
+   int gpio_irq;
+   int irq_base;
+   int gpio_base;
+};
+
+static const struct regmap_irq max77620_gpio_irqs[] = {
+   REGMAP_IRQ_REG(0, 0, MAX77620_IRQ_LVL2_GPIO_EDGE0),
+   REGMAP_IRQ_REG(1, 0, MAX77620_IRQ_LVL2_GPIO_EDGE1),
+   REGMAP_IRQ_REG(2, 0, MAX77620_IRQ_LVL2_GPIO_EDGE2),
+   REGMAP_IRQ_REG(3, 0, MAX77620_IRQ_LVL2_GPIO_EDGE3),
+   REGMAP_IRQ_REG(4, 0, MAX77620_IRQ_LVL2_GPIO_EDGE4),
+   REGMAP_IRQ_REG(5, 0, MAX77620_IRQ_LVL2_GPIO_EDGE5),
+   REGMAP_IRQ_REG(6, 0, MAX77620_IRQ_LVL2_GPIO_EDGE6),
+   REGMAP_IRQ_REG(7, 0, MAX77620_IRQ_LVL2_GPIO_EDGE7),
+};
+
+static struct regmap_irq_chip max77620_gpio_irq_chip = {
+   .name = "max77620-gpio",
+   .irqs = max77620_gpio_irqs,
+   .num_irqs = ARRAY_SIZE(max77620_gpio_irqs),
+   .num_regs = 1,
+   .irq_reg_stride = 1,
+   .status_base = MAX77620_REG_IRQ_LVL2_GPIO,
+};
+
+static int max77620_gpio_dir_input(struct gpio_chip *gc, unsigned int offset)
+{
+   struct max77620_gpio *mgpio = gpiochip_get_data(gc);
+   int ret;
+
+   ret = regmap_update_bits(mgpio->rmap, GPIO_REG_ADDR(offset),
+

[PATCH V12 2/2] gpio: max77620: add gpio driver for MAX77620/MAX20024

[Laxman Dewangan]

MAXIM Semiconductor's PMIC, MAX77620/MAX20024 has 8 GPIO
pins. It also supports interrupts from these pins.

Add GPIO driver for these pins to control via GPIO APIs.

Signed-off-by: Laxman Dewangan 
Reviewed-by: Linus Walleij 

---
This as part of the max77620 series and mfd patch are already applied.
This can go in subsystem branch.

Changes from V1:
- Use the gpiochip_add_data and get the chip data from core APIs.
- Cleanups based on comment received on mfd/rtc.
- Avoid duplication on error message.

Changes form V2:
- Run coccicheck and checkpatch in strict mode for the alignment.
- update based on api changes from core.

Changes from V3:
- Change all sys initcall to module driver.
- change the max77620_read argument to unisgned int from u8.

Changes from V4:
- Added DT binding document as devicetree/bindings/gpio/gpio-max77620.txt

Changes from V5:
- Separate out DT binding doc for gpio.
- Added reviewed by for Linus W

Changes from V6/V7:
- None

Changes from V8:
- Run checkpatch --strict and fix error. Mostly to use unsigned int instead
  of unsigned.
- Use linux/gpio/driver.h

Changes from V9:
- Use devm_regmap_add_irq_chip() and devm_gpiochip_add_data()

Changes from V10:
None

Changes from V11:
- Change bool to tristate in CONFIG
---
 drivers/gpio/Kconfig |   9 ++
 drivers/gpio/Makefile|   1 +
 drivers/gpio/gpio-max77620.c | 238 +++
 3 files changed, 248 insertions(+)
 create mode 100644 drivers/gpio/gpio-max77620.c

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 48da857..9244381 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -870,6 +870,15 @@ config GPIO_LP3943
  LP3943 can be used as a GPIO expander which provides up to 16 GPIOs.
  Open drain outputs are required for this usage.
 
+config GPIO_MAX77620
+   tristate "GPIO support for PMIC MAX77620 and MAX20024"
+   depends on MFD_MAX77620
+   help
+ GPIO driver for MAX77620 and MAX20024 PMIC from Maxim Semiconductor.
+ MAX77620 PMIC has 8 pins that can be configured as GPIOs. The
+ driver also provides interrupt support for each of the gpios.
+ Say yes here to enable the max77620 to be used as gpio controller.
+
 config GPIO_MSIC
bool "Intel MSIC mixed signal gpio support"
depends on MFD_INTEL_MSIC
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 991598e..6e111fc 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -61,6 +61,7 @@ obj-$(CONFIG_GPIO_MAX730X)+= gpio-max730x.o
 obj-$(CONFIG_GPIO_MAX7300) += gpio-max7300.o
 obj-$(CONFIG_GPIO_MAX7301) += gpio-max7301.o
 obj-$(CONFIG_GPIO_MAX732X) += gpio-max732x.o
+obj-$(CONFIG_GPIO_MAX77620)+= gpio-max77620.o
 obj-$(CONFIG_GPIO_MB86S7X) += gpio-mb86s7x.o
 obj-$(CONFIG_GPIO_MENZ127) += gpio-menz127.o
 obj-$(CONFIG_GPIO_MC33880) += gpio-mc33880.o
diff --git a/drivers/gpio/gpio-max77620.c b/drivers/gpio/gpio-max77620.c
new file mode 100644
index 000..d927562
--- /dev/null
+++ b/drivers/gpio/gpio-max77620.c
@@ -0,0 +1,238 @@
+/*
+ * MAXIM MAX77620 GPIO driver
+ *
+ * Copyright (c) 2016, NVIDIA CORPORATION.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define GPIO_REG_ADDR(offset) (MAX77620_REG_GPIO0 + offset)
+
+struct max77620_gpio {
+   struct gpio_chipgpio_chip;
+   struct regmap   *rmap;
+   struct device   *dev;
+   int gpio_irq;
+   int irq_base;
+   int gpio_base;
+};
+
+static const struct regmap_irq max77620_gpio_irqs[] = {
+   REGMAP_IRQ_REG(0, 0, MAX77620_IRQ_LVL2_GPIO_EDGE0),
+   REGMAP_IRQ_REG(1, 0, MAX77620_IRQ_LVL2_GPIO_EDGE1),
+   REGMAP_IRQ_REG(2, 0, MAX77620_IRQ_LVL2_GPIO_EDGE2),
+   REGMAP_IRQ_REG(3, 0, MAX77620_IRQ_LVL2_GPIO_EDGE3),
+   REGMAP_IRQ_REG(4, 0, MAX77620_IRQ_LVL2_GPIO_EDGE4),
+   REGMAP_IRQ_REG(5, 0, MAX77620_IRQ_LVL2_GPIO_EDGE5),
+   REGMAP_IRQ_REG(6, 0, MAX77620_IRQ_LVL2_GPIO_EDGE6),
+   REGMAP_IRQ_REG(7, 0, MAX77620_IRQ_LVL2_GPIO_EDGE7),
+};
+
+static struct regmap_irq_chip max77620_gpio_irq_chip = {
+   .name = "max77620-gpio",
+   .irqs = max77620_gpio_irqs,
+   .num_irqs = ARRAY_SIZE(max77620_gpio_irqs),
+   .num_regs = 1,
+   .irq_reg_stride = 1,
+   .status_base = MAX77620_REG_IRQ_LVL2_GPIO,
+};
+
+static int max77620_gpio_dir_input(struct gpio_chip *gc, unsigned int offset)
+{
+   struct max77620_gpio *mgpio = gpiochip_get_data(gc);
+   int ret;
+
+   ret = regmap_update_bits(mgpio->rmap, GPIO_REG_ADDR(offset),
+MAX77620_CNFG_GPIO_DIR_MASK,
+

[PATCH V12 2/2] pinctrl: max77620: add pincontrol driver for MAX77620/MAX20024

[Laxman Dewangan]

MAXIM Semiconductor's PMIC, MAX77620/MAX20024 has 8 GPIO pins
which also act as the special function in alternate mode. Also
there is configuration like push-pull, open drain, FPS timing
etc for these pins.

Add pin control driver to configure these parameters through
pin control APIs.

Signed-off-by: Laxman Dewangan 
Reviewed-by: Linus Walleij 

---
This was part of the max77620 series and mfd is merged. So it
can go in subsystem wise.

Changes from V1:
- Cleanup code based on comment received on mfd/rtc.
- Avoid duplication on error message.

Changes form V2:
- Run coccicheck and checkpatch in strict mode for the alignment.
- update based on api changes from core.

Changes from V3:
- Change all sys initcall to module driver.
- change the max77620_read argument to unisgned int from u8.

Changes from V4:
- Added DT binding document as devicetree/bindings/pinctrl/pinctrl-max77620.txt
- Detail out properties as per review comment.

Changes from V5:
- Separate out DT binding doc for pincontrol.
- Added reviewed by for Linus W

Changes from V6:
- Use regmap APIs direct instead of max77620 abstraction APIs.

Changes from V7:
- None

Changes from V8:
- Run checkpatch --strict on final patch and fixes issue and changed
  unsigned to unsigned int.

Changes from V9:
None

Changes from V10:
Use new APIs for the dt_free_map.

Changes from V11:
- Change bool to tristate for the CONFIG.
- Use devm_pinctrl_tegister and get rid of remove callback.
---
 drivers/pinctrl/Kconfig|  10 +
 drivers/pinctrl/Makefile   |   1 +
 drivers/pinctrl/pinctrl-max77620.c | 678 +
 3 files changed, 689 insertions(+)
 create mode 100644 drivers/pinctrl/pinctrl-max77620.c

diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index fb8200b..612547c 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -196,6 +196,16 @@ config PINCTRL_COH901
  COH 901 335 and COH 901 571/3. They contain 3, 5 or 7
  ports of 8 GPIO pins each.
 
+config PINCTRL_MAX77620
+   tristate "MAX77620/MAX20024 Pincontrol support"
+   depends on MFD_MAX77620
+   select GENERIC_PINCONF
+   help
+ Say Yes here to enable Pin control support for Maxim PMIC MAX77620.
+ This PMIC has 8 GPIO pins that work as GPIO as well as special
+ function in alternate mode. This driver also configure push-pull,
+ open drain, FPS slots etc.
+
 config PINCTRL_PALMAS
bool "Pinctrl driver for the PALMAS Series MFD devices"
depends on OF && MFD_PALMAS
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index e4bc115..d6f349c 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_PINCTRL_AMD) += pinctrl-amd.o
 obj-$(CONFIG_PINCTRL_DIGICOLOR)+= pinctrl-digicolor.o
 obj-$(CONFIG_PINCTRL_FALCON)   += pinctrl-falcon.o
 obj-$(CONFIG_PINCTRL_MESON)+= meson/
+obj-$(CONFIG_PINCTRL_MAX77620) += pinctrl-max77620.o
 obj-$(CONFIG_PINCTRL_PALMAS)   += pinctrl-palmas.o
 obj-$(CONFIG_PINCTRL_PIC32)+= pinctrl-pic32.o
 obj-$(CONFIG_PINCTRL_PISTACHIO)+= pinctrl-pistachio.o
diff --git a/drivers/pinctrl/pinctrl-max77620.c 
b/drivers/pinctrl/pinctrl-max77620.c
new file mode 100644
index 000..19005a0
--- /dev/null
+++ b/drivers/pinctrl/pinctrl-max77620.c
@@ -0,0 +1,678 @@
+/*
+ * MAX77620 pin control driver.
+ *
+ * Copyright (c) 2016, NVIDIA CORPORATION.  All rights reserved.
+ *
+ * Author:
+ * Chaitanya Bandi 
+ * Laxman Dewangan 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "core.h"
+#include "pinconf.h"
+#include "pinctrl-utils.h"
+
+#define MAX77620_PIN_NUM 8
+
+enum max77620_pin_ppdrv {
+   MAX77620_PIN_UNCONFIG_DRV,
+   MAX77620_PIN_OD_DRV,
+   MAX77620_PIN_PP_DRV,
+};
+
+enum max77620_pinconf_param {
+   MAX77620_ACTIVE_FPS_SOURCE = PIN_CONFIG_END + 1,
+   MAX77620_ACTIVE_FPS_POWER_ON_SLOTS,
+   MAX77620_ACTIVE_FPS_POWER_DOWN_SLOTS,
+   MAX77620_SUSPEND_FPS_SOURCE,
+   MAX77620_SUSPEND_FPS_POWER_ON_SLOTS,
+   MAX77620_SUSPEND_FPS_POWER_DOWN_SLOTS,
+};
+
+struct max77620_pin_function {
+   const char *name;
+   const char * const *groups;
+   unsigned int ngroups;
+   int mux_option;
+};
+
+struct max77620_cfg_param {
+   const char *property;
+   enum max77620_pinconf_param param;
+};
+
+static const struct pinconf_generic_params max77620_cfg_params[] = {
+   {
+   .property = "maxim,active-fps-source",
+   .param = MAX77620_ACTIVE_FPS_SOURCE,
+   }, {
+   .property = 

[PATCH V12 1/2] gpio: add DT binding doc for gpio of PMIC max77620/max20024

[Laxman Dewangan]

Maxim Semiconductor's PMIC MAX77620/MAX20024 has 8 GPIO pins
which act as GPIO as well as special function mode.

Add DT binding document to support these pins in GPIO
mode via GPIO framework.

Signed-off-by: Laxman Dewangan 
Acked-by: Rob Herring 
Acked-by: Linus Walleij 

---
This as part of the max77620 series and mfd patch are already applied.
This can go in subsystem branch.

Changes from V4:
- Separate out from gpio driver

Changes from V5/V6/V7:
- None

Changes from V8:
- Collected Linus ack.

Changes from V9i/V10:
None
---
 .../devicetree/bindings/gpio/gpio-max77620.txt | 25 ++
 1 file changed, 25 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gpio/gpio-max77620.txt

diff --git a/Documentation/devicetree/bindings/gpio/gpio-max77620.txt 
b/Documentation/devicetree/bindings/gpio/gpio-max77620.txt
new file mode 100644
index 000..410e716
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-max77620.txt
@@ -0,0 +1,25 @@
+GPIO driver for MAX77620 Power management IC from Maxim Semiconductor.
+
+Device has 8 GPIO pins which can be configured as GPIO as well as the
+special IO functions.
+
+Required properties:
+---
+- gpio-controller :Marks the device node as a gpio controller.
+- #gpio-cells :Should be two.  The first cell is the pin number and
+   the second cell is used to specify the gpio polarity:
+   0 = active high
+   1 = active low
+For more details, please refer generic GPIO DT binding document
+.
+
+Example:
+
+#include 
+...
+max77620@3c {
+   compatible = "maxim,max77620";
+
+   gpio-controller;
+   #gpio-cells = <2>;
+};
-- 
2.1.4

[PATCH V12 2/2] pinctrl: max77620: add pincontrol driver for MAX77620/MAX20024

[Laxman Dewangan]

MAXIM Semiconductor's PMIC, MAX77620/MAX20024 has 8 GPIO pins
which also act as the special function in alternate mode. Also
there is configuration like push-pull, open drain, FPS timing
etc for these pins.

Add pin control driver to configure these parameters through
pin control APIs.

Signed-off-by: Laxman Dewangan 
Reviewed-by: Linus Walleij 

---
This was part of the max77620 series and mfd is merged. So it
can go in subsystem wise.

Changes from V1:
- Cleanup code based on comment received on mfd/rtc.
- Avoid duplication on error message.

Changes form V2:
- Run coccicheck and checkpatch in strict mode for the alignment.
- update based on api changes from core.

Changes from V3:
- Change all sys initcall to module driver.
- change the max77620_read argument to unisgned int from u8.

Changes from V4:
- Added DT binding document as devicetree/bindings/pinctrl/pinctrl-max77620.txt
- Detail out properties as per review comment.

Changes from V5:
- Separate out DT binding doc for pincontrol.
- Added reviewed by for Linus W

Changes from V6:
- Use regmap APIs direct instead of max77620 abstraction APIs.

Changes from V7:
- None

Changes from V8:
- Run checkpatch --strict on final patch and fixes issue and changed
  unsigned to unsigned int.

Changes from V9:
None

Changes from V10:
Use new APIs for the dt_free_map.

Changes from V11:
- Change bool to tristate for the CONFIG.
- Use devm_pinctrl_tegister and get rid of remove callback.
---
 drivers/pinctrl/Kconfig|  10 +
 drivers/pinctrl/Makefile   |   1 +
 drivers/pinctrl/pinctrl-max77620.c | 678 +
 3 files changed, 689 insertions(+)
 create mode 100644 drivers/pinctrl/pinctrl-max77620.c

diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index fb8200b..612547c 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -196,6 +196,16 @@ config PINCTRL_COH901
  COH 901 335 and COH 901 571/3. They contain 3, 5 or 7
  ports of 8 GPIO pins each.
 
+config PINCTRL_MAX77620
+   tristate "MAX77620/MAX20024 Pincontrol support"
+   depends on MFD_MAX77620
+   select GENERIC_PINCONF
+   help
+ Say Yes here to enable Pin control support for Maxim PMIC MAX77620.
+ This PMIC has 8 GPIO pins that work as GPIO as well as special
+ function in alternate mode. This driver also configure push-pull,
+ open drain, FPS slots etc.
+
 config PINCTRL_PALMAS
bool "Pinctrl driver for the PALMAS Series MFD devices"
depends on OF && MFD_PALMAS
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index e4bc115..d6f349c 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_PINCTRL_AMD) += pinctrl-amd.o
 obj-$(CONFIG_PINCTRL_DIGICOLOR)+= pinctrl-digicolor.o
 obj-$(CONFIG_PINCTRL_FALCON)   += pinctrl-falcon.o
 obj-$(CONFIG_PINCTRL_MESON)+= meson/
+obj-$(CONFIG_PINCTRL_MAX77620) += pinctrl-max77620.o
 obj-$(CONFIG_PINCTRL_PALMAS)   += pinctrl-palmas.o
 obj-$(CONFIG_PINCTRL_PIC32)+= pinctrl-pic32.o
 obj-$(CONFIG_PINCTRL_PISTACHIO)+= pinctrl-pistachio.o
diff --git a/drivers/pinctrl/pinctrl-max77620.c 
b/drivers/pinctrl/pinctrl-max77620.c
new file mode 100644
index 000..19005a0
--- /dev/null
+++ b/drivers/pinctrl/pinctrl-max77620.c
@@ -0,0 +1,678 @@
+/*
+ * MAX77620 pin control driver.
+ *
+ * Copyright (c) 2016, NVIDIA CORPORATION.  All rights reserved.
+ *
+ * Author:
+ * Chaitanya Bandi 
+ * Laxman Dewangan 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "core.h"
+#include "pinconf.h"
+#include "pinctrl-utils.h"
+
+#define MAX77620_PIN_NUM 8
+
+enum max77620_pin_ppdrv {
+   MAX77620_PIN_UNCONFIG_DRV,
+   MAX77620_PIN_OD_DRV,
+   MAX77620_PIN_PP_DRV,
+};
+
+enum max77620_pinconf_param {
+   MAX77620_ACTIVE_FPS_SOURCE = PIN_CONFIG_END + 1,
+   MAX77620_ACTIVE_FPS_POWER_ON_SLOTS,
+   MAX77620_ACTIVE_FPS_POWER_DOWN_SLOTS,
+   MAX77620_SUSPEND_FPS_SOURCE,
+   MAX77620_SUSPEND_FPS_POWER_ON_SLOTS,
+   MAX77620_SUSPEND_FPS_POWER_DOWN_SLOTS,
+};
+
+struct max77620_pin_function {
+   const char *name;
+   const char * const *groups;
+   unsigned int ngroups;
+   int mux_option;
+};
+
+struct max77620_cfg_param {
+   const char *property;
+   enum max77620_pinconf_param param;
+};
+
+static const struct pinconf_generic_params max77620_cfg_params[] = {
+   {
+   .property = "maxim,active-fps-source",
+   .param = MAX77620_ACTIVE_FPS_SOURCE,
+   }, {
+   .property = "maxim,active-fps-power-up-slot",
+   .param = MAX77620_ACTIVE_FPS_POWER_ON_SLOTS,
+   }, {

[PATCH V12 1/2] gpio: add DT binding doc for gpio of PMIC max77620/max20024

[Laxman Dewangan]

Maxim Semiconductor's PMIC MAX77620/MAX20024 has 8 GPIO pins
which act as GPIO as well as special function mode.

Add DT binding document to support these pins in GPIO
mode via GPIO framework.

Signed-off-by: Laxman Dewangan 
Acked-by: Rob Herring 
Acked-by: Linus Walleij 

---
This as part of the max77620 series and mfd patch are already applied.
This can go in subsystem branch.

Changes from V4:
- Separate out from gpio driver

Changes from V5/V6/V7:
- None

Changes from V8:
- Collected Linus ack.

Changes from V9i/V10:
None
---
 .../devicetree/bindings/gpio/gpio-max77620.txt | 25 ++
 1 file changed, 25 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gpio/gpio-max77620.txt

diff --git a/Documentation/devicetree/bindings/gpio/gpio-max77620.txt 
b/Documentation/devicetree/bindings/gpio/gpio-max77620.txt
new file mode 100644
index 000..410e716
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-max77620.txt
@@ -0,0 +1,25 @@
+GPIO driver for MAX77620 Power management IC from Maxim Semiconductor.
+
+Device has 8 GPIO pins which can be configured as GPIO as well as the
+special IO functions.
+
+Required properties:
+---
+- gpio-controller :Marks the device node as a gpio controller.
+- #gpio-cells :Should be two.  The first cell is the pin number and
+   the second cell is used to specify the gpio polarity:
+   0 = active high
+   1 = active low
+For more details, please refer generic GPIO DT binding document
+.
+
+Example:
+
+#include 
+...
+max77620@3c {
+   compatible = "maxim,max77620";
+
+   gpio-controller;
+   #gpio-cells = <2>;
+};
-- 
2.1.4

Re: [tip:sched/core] sched/fair: Correct unit of load_above_capacity

[Yuyang Du]

On Thu, May 12, 2016 at 03:31:51AM -0700, tip-bot for Morten Rasmussen wrote:
> Commit-ID:  cfa10334318d8212d007da8c771187643c9cef35
> Gitweb: http://git.kernel.org/tip/cfa10334318d8212d007da8c771187643c9cef35
> Author: Morten Rasmussen 
> AuthorDate: Fri, 29 Apr 2016 20:32:40 +0100
> Committer:  Ingo Molnar 
> CommitDate: Thu, 12 May 2016 09:55:33 +0200
> 
> sched/fair: Correct unit of load_above_capacity
> 
> In calculate_imbalance() load_above_capacity currently has the unit
> [capacity] while it is used as being [load/capacity]. Not only is it
> wrong it also makes it unlikely that load_above_capacity is ever used
> as the subsequent code picks the smaller of load_above_capacity and
> the avg_load
> 
> This patch ensures that load_above_capacity has the right unit
> [load/capacity].
> 
> Signed-off-by: Morten Rasmussen 
> [ Changed changelog to note it was in capacity unit; +rebase. ]
> Signed-off-by: Peter Zijlstra (Intel) 
> Cc: Dietmar Eggemann 
> Cc: Linus Torvalds 
> Cc: Mike Galbraith 
> Cc: Peter Zijlstra 
> Cc: Thomas Gleixner 
> Cc: linux-kernel@vger.kernel.org
> Link: 
> http://lkml.kernel.org/r/1461958364-675-4-git-send-email-dietmar.eggem...@arm.com
> Signed-off-by: Ingo Molnar 
> ---
>  kernel/sched/fair.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 2338105..218f8e8 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -7067,9 +7067,11 @@ static inline void calculate_imbalance(struct lb_env 
> *env, struct sd_lb_stats *s
>   if (busiest->group_type == group_overloaded &&
>   local->group_type   == group_overloaded) {
>   load_above_capacity = busiest->sum_nr_running * 
> SCHED_CAPACITY_SCALE;
> - if (load_above_capacity > busiest->group_capacity)
> + if (load_above_capacity > busiest->group_capacity) {
>   load_above_capacity -= busiest->group_capacity;
> - else
> + load_above_capacity *= NICE_0_LOAD;
> + load_above_capacity /= busiest->group_capacity;
> + } else
>   load_above_capacity = ~0UL;
>   }
  
Hi Morten,

I got the feeling this might be wrong, the NICE_0_LOAD should be scaled down.
But I hope I am wrong.

Vincent, could you take a look?

Re: [tip:sched/core] sched/fair: Correct unit of load_above_capacity

[Yuyang Du]

On Thu, May 12, 2016 at 03:31:51AM -0700, tip-bot for Morten Rasmussen wrote:
> Commit-ID:  cfa10334318d8212d007da8c771187643c9cef35
> Gitweb: http://git.kernel.org/tip/cfa10334318d8212d007da8c771187643c9cef35
> Author: Morten Rasmussen 
> AuthorDate: Fri, 29 Apr 2016 20:32:40 +0100
> Committer:  Ingo Molnar 
> CommitDate: Thu, 12 May 2016 09:55:33 +0200
> 
> sched/fair: Correct unit of load_above_capacity
> 
> In calculate_imbalance() load_above_capacity currently has the unit
> [capacity] while it is used as being [load/capacity]. Not only is it
> wrong it also makes it unlikely that load_above_capacity is ever used
> as the subsequent code picks the smaller of load_above_capacity and
> the avg_load
> 
> This patch ensures that load_above_capacity has the right unit
> [load/capacity].
> 
> Signed-off-by: Morten Rasmussen 
> [ Changed changelog to note it was in capacity unit; +rebase. ]
> Signed-off-by: Peter Zijlstra (Intel) 
> Cc: Dietmar Eggemann 
> Cc: Linus Torvalds 
> Cc: Mike Galbraith 
> Cc: Peter Zijlstra 
> Cc: Thomas Gleixner 
> Cc: linux-kernel@vger.kernel.org
> Link: 
> http://lkml.kernel.org/r/1461958364-675-4-git-send-email-dietmar.eggem...@arm.com
> Signed-off-by: Ingo Molnar 
> ---
>  kernel/sched/fair.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 2338105..218f8e8 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -7067,9 +7067,11 @@ static inline void calculate_imbalance(struct lb_env 
> *env, struct sd_lb_stats *s
>   if (busiest->group_type == group_overloaded &&
>   local->group_type   == group_overloaded) {
>   load_above_capacity = busiest->sum_nr_running * 
> SCHED_CAPACITY_SCALE;
> - if (load_above_capacity > busiest->group_capacity)
> + if (load_above_capacity > busiest->group_capacity) {
>   load_above_capacity -= busiest->group_capacity;
> - else
> + load_above_capacity *= NICE_0_LOAD;
> + load_above_capacity /= busiest->group_capacity;
> + } else
>   load_above_capacity = ~0UL;
>   }
  
Hi Morten,

I got the feeling this might be wrong, the NICE_0_LOAD should be scaled down.
But I hope I am wrong.

Vincent, could you take a look?

Re: UBSAN: Undefined behaviour in drivers/scsi/aic7xxx/aic7xxx_core.c:2831:31

[James Bottomley]

On Thu, 2016-05-12 at 17:56 -0400, Ilia Mirkin wrote:
> On Thu, May 12, 2016 at 4:08 PM, James Bottomley
>  wrote:
> > On Thu, 2016-05-12 at 19:02 +0300, Meelis Roos wrote:
> > > This is from a dual-AthlonMP 32-bit x86 system with onboard
> > > Adaptec
> > > SCSI
> > > controller, once during bootup.
> > > 
> > > [4.896307]
> > > =
> > > 
> > > ===
> > > [4.896471] UBSAN: Undefined behaviour in
> > > drivers/scsi/aic7xxx/aic7xxx_core.c:2831:31
> > > [4.896629] shift exponent -1 is negative
> > 
> > Is this some sort of false positive?  The shift in question is
> > 
> > devinfo->target_mask = (0x01 << devinfo->target_offset);
> > 
> > The code which calls this in ahc_linux_initialize_scsi_bus() looks
> > to
> > be looping from 0-16 (or variations).  Since the value passed in is
> > unsigned, it would have to be set to ~0, which doesn't seem
> > possible.
> 
> It's getting called from ahc_reset_channel, which does:
> 
> ahc_compile_devinfo(,
> CAM_TARGET_WILDCARD,
> CAM_TARGET_WILDCARD,
> CAM_LUN_WILDCARD,
> channel, ROLE_UNKNOWN);
> 
> drivers/scsi/aic7xxx/cam.h:#define  CAM_TARGET_WILDCARD 
> ((u_int)~0)

OK, thanks, you can mark it as a false positive because only the SPI
parameters are actually used for this version of devinfo.

James

Re: UBSAN: Undefined behaviour in drivers/scsi/aic7xxx/aic7xxx_core.c:2831:31

[James Bottomley]

On Thu, 2016-05-12 at 17:56 -0400, Ilia Mirkin wrote:
> On Thu, May 12, 2016 at 4:08 PM, James Bottomley
>  wrote:
> > On Thu, 2016-05-12 at 19:02 +0300, Meelis Roos wrote:
> > > This is from a dual-AthlonMP 32-bit x86 system with onboard
> > > Adaptec
> > > SCSI
> > > controller, once during bootup.
> > > 
> > > [4.896307]
> > > =
> > > 
> > > ===
> > > [4.896471] UBSAN: Undefined behaviour in
> > > drivers/scsi/aic7xxx/aic7xxx_core.c:2831:31
> > > [4.896629] shift exponent -1 is negative
> > 
> > Is this some sort of false positive?  The shift in question is
> > 
> > devinfo->target_mask = (0x01 << devinfo->target_offset);
> > 
> > The code which calls this in ahc_linux_initialize_scsi_bus() looks
> > to
> > be looping from 0-16 (or variations).  Since the value passed in is
> > unsigned, it would have to be set to ~0, which doesn't seem
> > possible.
> 
> It's getting called from ahc_reset_channel, which does:
> 
> ahc_compile_devinfo(,
> CAM_TARGET_WILDCARD,
> CAM_TARGET_WILDCARD,
> CAM_LUN_WILDCARD,
> channel, ROLE_UNKNOWN);
> 
> drivers/scsi/aic7xxx/cam.h:#define  CAM_TARGET_WILDCARD 
> ((u_int)~0)

OK, thanks, you can mark it as a false positive because only the SPI
parameters are actually used for this version of devinfo.

James

Re: transparent huge pages breaks KVM on AMD.

[Marc Haber]

On Thu, May 12, 2016 at 11:42:16PM +0300, Kirill A. Shutemov wrote:
> But I guess it should apply cleanly to v4.5. Or at least without major
> conflicts.

[11/511]mh@fan:~/linux/debug/linux$ curl 
'http://marc.info/?l=linux-rdma=146307074800836=2' | patch -p1
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
100 125290 125290 0   9844  0 --:--:--  0:00:01 --:--:--  9849
patching file include/linux/mm.h
Hunk #1 succeeded at 456 with fuzz 1 (offset -44 lines).
patching file include/linux/swap.h
Hunk #2 FAILED at 513.
1 out of 2 hunks FAILED -- saving rejects to file include/linux/swap.h.rej
patching file mm/huge_memory.c
Hunk #1 FAILED at 1298.
Hunk #2 FAILED at 2079.
Hunk #3 succeeded at 3340 (offset 117 lines).
2 out of 3 hunks FAILED -- saving rejects to file mm/huge_memory.c.rej
patching file mm/memory.c
Hunk #1 FAILED at 2373.
Hunk #2 succeeded at 2331 with fuzz 2 (offset -56 lines).
Hunk #3 FAILED at 2622.
2 out of 3 hunks FAILED -- saving rejects to file mm/memory.c.rej
patching file mm/swapfile.c
Hunk #1 FAILED at 922.
1 out of 1 hunk FAILED -- saving rejects to file mm/swapfile.c.rej
[12/512]mh@fan:~/linux/debug/linux$

It doesn't, and it doesn't apply to 4.6-rc3 as well:

[17/517]mh@fan:~/linux/debug/linux$ git checkout v4.6-rc3
Checking out files: 100% (9945/9945), done.
Previous HEAD position was b562e44... Linux 4.5
HEAD is now at bf16200... Linux 4.6-rc3
[18/518]mh@fan:~/linux/debug/linux$ curl 
'http://marc.info/?l=linux-rdma=146307074800836=2' | patch -p1
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
100 125290 125290 0   9692  0 --:--:--  0:00:01 --:--:--  9697
patching file include/linux/mm.h
patching file include/linux/swap.h
Hunk #2 FAILED at 513.
1 out of 2 hunks FAILED -- saving rejects to file include/linux/swap.h.rej
patching file mm/huge_memory.c
Hunk #1 FAILED at 1298.
Hunk #2 FAILED at 2079.
Hunk #3 succeeded at 3225 (offset 2 lines).
2 out of 3 hunks FAILED -- saving rejects to file mm/huge_memory.c.rej
patching file mm/memory.c
Hunk #1 FAILED at 2373.
Hunk #2 succeeded at 2354 (offset -33 lines).
Hunk #3 FAILED at 2622.
2 out of 3 hunks FAILED -- saving rejects to file mm/memory.c.rej
patching file mm/swapfile.c
Hunk #1 FAILED at 922.
1 out of 1 hunk FAILED -- saving rejects to file mm/swapfile.c.rej
[19/519]mh@fan:~/linux/debug/linux$

How do I apply this?

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Re: transparent huge pages breaks KVM on AMD.

[Marc Haber]

On Thu, May 12, 2016 at 11:42:16PM +0300, Kirill A. Shutemov wrote:
> But I guess it should apply cleanly to v4.5. Or at least without major
> conflicts.

[11/511]mh@fan:~/linux/debug/linux$ curl 
'http://marc.info/?l=linux-rdma=146307074800836=2' | patch -p1
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
100 125290 125290 0   9844  0 --:--:--  0:00:01 --:--:--  9849
patching file include/linux/mm.h
Hunk #1 succeeded at 456 with fuzz 1 (offset -44 lines).
patching file include/linux/swap.h
Hunk #2 FAILED at 513.
1 out of 2 hunks FAILED -- saving rejects to file include/linux/swap.h.rej
patching file mm/huge_memory.c
Hunk #1 FAILED at 1298.
Hunk #2 FAILED at 2079.
Hunk #3 succeeded at 3340 (offset 117 lines).
2 out of 3 hunks FAILED -- saving rejects to file mm/huge_memory.c.rej
patching file mm/memory.c
Hunk #1 FAILED at 2373.
Hunk #2 succeeded at 2331 with fuzz 2 (offset -56 lines).
Hunk #3 FAILED at 2622.
2 out of 3 hunks FAILED -- saving rejects to file mm/memory.c.rej
patching file mm/swapfile.c
Hunk #1 FAILED at 922.
1 out of 1 hunk FAILED -- saving rejects to file mm/swapfile.c.rej
[12/512]mh@fan:~/linux/debug/linux$

It doesn't, and it doesn't apply to 4.6-rc3 as well:

[17/517]mh@fan:~/linux/debug/linux$ git checkout v4.6-rc3
Checking out files: 100% (9945/9945), done.
Previous HEAD position was b562e44... Linux 4.5
HEAD is now at bf16200... Linux 4.6-rc3
[18/518]mh@fan:~/linux/debug/linux$ curl 
'http://marc.info/?l=linux-rdma=146307074800836=2' | patch -p1
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
100 125290 125290 0   9692  0 --:--:--  0:00:01 --:--:--  9697
patching file include/linux/mm.h
patching file include/linux/swap.h
Hunk #2 FAILED at 513.
1 out of 2 hunks FAILED -- saving rejects to file include/linux/swap.h.rej
patching file mm/huge_memory.c
Hunk #1 FAILED at 1298.
Hunk #2 FAILED at 2079.
Hunk #3 succeeded at 3225 (offset 2 lines).
2 out of 3 hunks FAILED -- saving rejects to file mm/huge_memory.c.rej
patching file mm/memory.c
Hunk #1 FAILED at 2373.
Hunk #2 succeeded at 2354 (offset -33 lines).
Hunk #3 FAILED at 2622.
2 out of 3 hunks FAILED -- saving rejects to file mm/memory.c.rej
patching file mm/swapfile.c
Hunk #1 FAILED at 922.
1 out of 1 hunk FAILED -- saving rejects to file mm/swapfile.c.rej
[19/519]mh@fan:~/linux/debug/linux$

How do I apply this?

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

RE: [PATCH v8 1/2] Documentation: DT: dma: Add Xilinx zynqmp dma device tree binding documentation

[Appana Durga Kedareswara Rao]

Hi Lars,

Thanks for the review...

> 
> On 05/12/2016 02:29 PM, Kedareswara rao Appana wrote:
> [...]
> > +- xlnx,include-sg  : Indicates the controller to operate in simple or
> > + scatter gather dma mode
> 
> This is also a software runtime configuration parameter.

Hmm I missed it will fix in the next version of the patch.

Regards,
Kedar.

RE: [PATCH v8 1/2] Documentation: DT: dma: Add Xilinx zynqmp dma device tree binding documentation

[Appana Durga Kedareswara Rao]

Hi Lars,

Thanks for the review...

> 
> On 05/12/2016 02:29 PM, Kedareswara rao Appana wrote:
> [...]
> > +- xlnx,include-sg  : Indicates the controller to operate in simple or
> > + scatter gather dma mode
> 
> This is also a software runtime configuration parameter.

Hmm I missed it will fix in the next version of the patch.

Regards,
Kedar.

Re: [PATCH 2/2] clk: rockchip: fix the rk3399 sdmmc sample shift

[Doug Anderson]

Shawn,

On Thu, May 12, 2016 at 4:47 PM, Shawn Lin  wrote:
> 在 2016/5/13 7:10, Brian Norris 写道:
>>
>> On Thu, May 12, 2016 at 11:03:17AM -0700, Doug Anderson wrote:
>>>
>>> Just like every other Rockhip device, the MMC "_sample" clocks should
>>> have a shift of 0, not a shift of 1.  The rk3399 TRM agrees.  Presumably
>>> these values were set to 0 because of a typo.
>>
>>
>> I'll semi-disagree about the TRM: the TRM doesn't seem to agree with
>> itself, so it sometimes agrees with you and sometimes doesn't :)
>>
>> On page 79 of the 2nd (?) book, it looks like {SDMMC,SDIO}_CON{0,}[2:1]
>> are {drv,sample}_degree. But on page 208 of the 1st book, those are put
>> at bits [1:0].
>>
>
>
> Please refer to Mobile Strorage Host Controller section for anything
> about sdmmc/sdio. So shift should be 1.
>
> Sometime I also get bothered to address it. Anyway, I will always keep
> a eye on it from now on.

I still in general have mistrust for TRM docs for things like this.
Have you verified that this was an intentional change for rk3399, or
could it be a  typo?  Typically SoCs don't change this type of stuff
for no reason.

This should be possible to verify in one of two ways.  If the TRM has
a typo and things truly _do_ start at 0 instead of 1, then:

1. There will be roughly mirrors of valid ranges.
2. Things won't match up if we change tuning to use 180 course offsets
and the rest fine offsets.

It would be ideal if you could confirm with the chip guys, but if you
can't I'll try to do more tests tomorrow.

Re: [PATCH 2/2] clk: rockchip: fix the rk3399 sdmmc sample shift

[Doug Anderson]

Shawn,

On Thu, May 12, 2016 at 4:47 PM, Shawn Lin  wrote:
> 在 2016/5/13 7:10, Brian Norris 写道:
>>
>> On Thu, May 12, 2016 at 11:03:17AM -0700, Doug Anderson wrote:
>>>
>>> Just like every other Rockhip device, the MMC "_sample" clocks should
>>> have a shift of 0, not a shift of 1.  The rk3399 TRM agrees.  Presumably
>>> these values were set to 0 because of a typo.
>>
>>
>> I'll semi-disagree about the TRM: the TRM doesn't seem to agree with
>> itself, so it sometimes agrees with you and sometimes doesn't :)
>>
>> On page 79 of the 2nd (?) book, it looks like {SDMMC,SDIO}_CON{0,}[2:1]
>> are {drv,sample}_degree. But on page 208 of the 1st book, those are put
>> at bits [1:0].
>>
>
>
> Please refer to Mobile Strorage Host Controller section for anything
> about sdmmc/sdio. So shift should be 1.
>
> Sometime I also get bothered to address it. Anyway, I will always keep
> a eye on it from now on.

I still in general have mistrust for TRM docs for things like this.
Have you verified that this was an intentional change for rk3399, or
could it be a  typo?  Typically SoCs don't change this type of stuff
for no reason.

This should be possible to verify in one of two ways.  If the TRM has
a typo and things truly _do_ start at 0 instead of 1, then:

1. There will be roughly mirrors of valid ranges.
2. Things won't match up if we change tuning to use 180 course offsets
and the rest fine offsets.

It would be ideal if you could confirm with the chip guys, but if you
can't I'll try to do more tests tomorrow.

RE: [PATCH v4 3/5] dmaengine: vdma: Add Support for Xilinx AXI Direct Memory Access Engine

[Appana Durga Kedareswara Rao]

Hi Paul,

> 
> Nice Kedar!
> 
> Is this getting applied? I would really like to see this get into the 
> mainline.

This patch got applied to the dma-next branch...
Here @ 
http://git.kernel.org/cgit/linux/kernel/git/vkoul/slave-dma.git/log/?h=next 

Thanks,
Kedar.

RE: [PATCH v4 3/5] dmaengine: vdma: Add Support for Xilinx AXI Direct Memory Access Engine

[Appana Durga Kedareswara Rao]

Hi Paul,

> 
> Nice Kedar!
> 
> Is this getting applied? I would really like to see this get into the 
> mainline.

This patch got applied to the dma-next branch...
Here @ 
http://git.kernel.org/cgit/linux/kernel/git/vkoul/slave-dma.git/log/?h=next 

Thanks,
Kedar.

arm build failures in -next due to 'sched/core: Add switch_mm_irqs_off() and use it in the scheduler'

[Guenter Roeck]

Hi Andy,

I see various arm build failures in -next. One example is spitz_defconfig.
Bisect points to commit 'sched/core: Add switch_mm_irqs_off() and use it
in the scheduler'. Reverting the commit fixes the problem.

In file included from include/linux/mmu_context.h:4:0,
 from drivers/usb/gadget/legacy/inode.c:27:
./arch/arm/include/asm/mmu_context.h:
In function 'finish_arch_post_lock_switch':
./arch/arm/include/asm/mmu_context.h:88:3: error:
implicit declaration of function 'preempt_enable_no_resched'

This has been going on for a while, so maybe it has been reported already.
If so, sorry for the noise.

Bisect log is attached.

Guenter

---
# bad: [dd1071fe27ec200ddc49a494e1275a8269248843] x86/rwsem: Save and restore 
all callee-clobbered regs in 32-bit down_write()
# good: [44549e8f5eea4e0a41b487b63e616cb089922b99] Linux 4.6-rc7
git bisect start 'HEAD' 'v4.6-rc7'
# good: [b6cf27d48f370bf2d42888921632ae05340aaca9] Merge remote-tracking branch 
'crypto/master'
git bisect good b6cf27d48f370bf2d42888921632ae05340aaca9
# bad: [607563e7793b7c4f3ab134dc200552a555ca5cb2] Merge remote-tracking branch 
'tip/auto-latest'
git bisect bad 607563e7793b7c4f3ab134dc200552a555ca5cb2
# good: [05454bc3dd6d8c4cff684ea881d79db952030075] Merge remote-tracking branch 
'block/for-next'
git bisect good 05454bc3dd6d8c4cff684ea881d79db952030075
# good: [3ed15da0d55d9147f6434fe57db60a5b4059cbfd] Merge remote-tracking branch 
'spi/for-next'
git bisect good 3ed15da0d55d9147f6434fe57db60a5b4059cbfd
# good: [25ea4e608611c03ad9829a727f6cc198db952d06] Merge branch 'perf/core'
git bisect good 25ea4e608611c03ad9829a727f6cc198db952d06
# bad: [df9f17497431a073c33aea6994f3b5b53fd89806] manual merge of x86/asm
git bisect bad df9f17497431a073c33aea6994f3b5b53fd89806
# bad: [d10c98b20678fb22506d6c712d7a0af6885001a1] Merge branch 'timers/core'
git bisect bad d10c98b20678fb22506d6c712d7a0af6885001a1
# bad: [b52fad2db5d792d89975cebf2fe1646a7af28ed0] sched/fair: Update rq clock 
before updating nohz CPU load
git bisect bad b52fad2db5d792d89975cebf2fe1646a7af28ed0
# good: [1f41906a6fda1114debd3898668bd7ab6470ee41] sched/fair: Correctly handle 
nohz ticks CPU load accounting
git bisect good 1f41906a6fda1114debd3898668bd7ab6470ee41
# bad: [64b7aad579847852e110878ccaae4c3aaa34] Merge branch 'sched/urgent' 
into sched/core, to pick up fixes before applying new changes
git bisect bad 64b7aad579847852e110878ccaae4c3aaa34
# good: [8efd755ac2fe262d4c8d5c9bbe054bb67dae93da] mm/mmu_context, sched/core: 
Fix mmu_context.h assumption
git bisect good 8efd755ac2fe262d4c8d5c9bbe054bb67dae93da
# bad: [e1074888c326038340a1ada9129d679e661f2ea6] x86/mm: Build 
arch/x86/mm/tlb.c even on !SMP
git bisect bad e1074888c326038340a1ada9129d679e661f2ea6
# bad: [f98db6013c557c216da5038d9c52045be55cd039] sched/core: Add 
switch_mm_irqs_off() and use it in the scheduler
git bisect bad f98db6013c557c216da5038d9c52045be55cd039
# first bad commit: [f98db6013c557c216da5038d9c52045be55cd039] sched/core: Add 
switch_mm_irqs_off() and use it in the scheduler

arm build failures in -next due to 'sched/core: Add switch_mm_irqs_off() and use it in the scheduler'

[Guenter Roeck]

Hi Andy,

I see various arm build failures in -next. One example is spitz_defconfig.
Bisect points to commit 'sched/core: Add switch_mm_irqs_off() and use it
in the scheduler'. Reverting the commit fixes the problem.

In file included from include/linux/mmu_context.h:4:0,
 from drivers/usb/gadget/legacy/inode.c:27:
./arch/arm/include/asm/mmu_context.h:
In function 'finish_arch_post_lock_switch':
./arch/arm/include/asm/mmu_context.h:88:3: error:
implicit declaration of function 'preempt_enable_no_resched'

This has been going on for a while, so maybe it has been reported already.
If so, sorry for the noise.

Bisect log is attached.

Guenter

---
# bad: [dd1071fe27ec200ddc49a494e1275a8269248843] x86/rwsem: Save and restore 
all callee-clobbered regs in 32-bit down_write()
# good: [44549e8f5eea4e0a41b487b63e616cb089922b99] Linux 4.6-rc7
git bisect start 'HEAD' 'v4.6-rc7'
# good: [b6cf27d48f370bf2d42888921632ae05340aaca9] Merge remote-tracking branch 
'crypto/master'
git bisect good b6cf27d48f370bf2d42888921632ae05340aaca9
# bad: [607563e7793b7c4f3ab134dc200552a555ca5cb2] Merge remote-tracking branch 
'tip/auto-latest'
git bisect bad 607563e7793b7c4f3ab134dc200552a555ca5cb2
# good: [05454bc3dd6d8c4cff684ea881d79db952030075] Merge remote-tracking branch 
'block/for-next'
git bisect good 05454bc3dd6d8c4cff684ea881d79db952030075
# good: [3ed15da0d55d9147f6434fe57db60a5b4059cbfd] Merge remote-tracking branch 
'spi/for-next'
git bisect good 3ed15da0d55d9147f6434fe57db60a5b4059cbfd
# good: [25ea4e608611c03ad9829a727f6cc198db952d06] Merge branch 'perf/core'
git bisect good 25ea4e608611c03ad9829a727f6cc198db952d06
# bad: [df9f17497431a073c33aea6994f3b5b53fd89806] manual merge of x86/asm
git bisect bad df9f17497431a073c33aea6994f3b5b53fd89806
# bad: [d10c98b20678fb22506d6c712d7a0af6885001a1] Merge branch 'timers/core'
git bisect bad d10c98b20678fb22506d6c712d7a0af6885001a1
# bad: [b52fad2db5d792d89975cebf2fe1646a7af28ed0] sched/fair: Update rq clock 
before updating nohz CPU load
git bisect bad b52fad2db5d792d89975cebf2fe1646a7af28ed0
# good: [1f41906a6fda1114debd3898668bd7ab6470ee41] sched/fair: Correctly handle 
nohz ticks CPU load accounting
git bisect good 1f41906a6fda1114debd3898668bd7ab6470ee41
# bad: [64b7aad579847852e110878ccaae4c3aaa34] Merge branch 'sched/urgent' 
into sched/core, to pick up fixes before applying new changes
git bisect bad 64b7aad579847852e110878ccaae4c3aaa34
# good: [8efd755ac2fe262d4c8d5c9bbe054bb67dae93da] mm/mmu_context, sched/core: 
Fix mmu_context.h assumption
git bisect good 8efd755ac2fe262d4c8d5c9bbe054bb67dae93da
# bad: [e1074888c326038340a1ada9129d679e661f2ea6] x86/mm: Build 
arch/x86/mm/tlb.c even on !SMP
git bisect bad e1074888c326038340a1ada9129d679e661f2ea6
# bad: [f98db6013c557c216da5038d9c52045be55cd039] sched/core: Add 
switch_mm_irqs_off() and use it in the scheduler
git bisect bad f98db6013c557c216da5038d9c52045be55cd039
# first bad commit: [f98db6013c557c216da5038d9c52045be55cd039] sched/core: Add 
switch_mm_irqs_off() and use it in the scheduler

Re: [PATCH] driver: input :touchscreen : add Raydium I2C touch driver

[Dmitry Torokhov]

Hi Jeffrey,
On Fri, Apr 29, 2016 at 05:45:13PM +0800, jeffrey.lin wrote:
> Raydium I2C touch driver.
> 
> Signed-off-by: jeffrey.lin 

I was looking at the driver and there were a few issues (buffer
overflows, forgetting releasing firmware, general flow, etc), that I
tried correcting in the attached patch. Please try incorporating it into
yours (it should apply to this version of Raydium driver) and let me
know if it still works. There are a few questionable points that I
marked with "XXX FIXME" in the code, please respond to them by either
confirming that they are correct or fixing them.

Thanks.

-- 
Dmitry


Input: raydium misc changes

From: Dmitry Torokhov 

Signed-off-by: Dmitry Torokhov 
---
 drivers/input/touchscreen/raydium_i2c_ts.c |  941 ++--
 1 file changed, 482 insertions(+), 459 deletions(-)

diff --git a/drivers/input/touchscreen/raydium_i2c_ts.c 
b/drivers/input/touchscreen/raydium_i2c_ts.c
index cee46e8..1e4e3de 100644
--- a/drivers/input/touchscreen/raydium_i2c_ts.c
+++ b/drivers/input/touchscreen/raydium_i2c_ts.c
@@ -20,107 +20,105 @@
  * Contact Raydium Semiconductor Corporation at www.rad-ic.com
  */
 
-#include 
-#include 
-#include 
-#include 
+#include 
 #include 
-#include 
 #include 
+#include 
+#include 
+#include 
 #include 
-#include 
+#include 
+#include 
 #include 
 #include 
+#include 
 #include 
-#include 
 
-/* Device, Driver information */
-#define DEVICE_NAME"raydium_i2c"
-
-/* Slave I2C mode*/
-#define RM_BOOT_BLDR   0x02
-#define RM_BOOT_MAIN   0x03
-
-/*I2C bl command */
-#define CMD_BOOT_PAGE_WRT  0x0B/*send bl page write*/
-#define CMD_BOOT_WRT   0x11/*send bl write*/
-#define CMD_BOOT_ACK   0x22/*send ack*/
-#define CMD_BOOT_CHK   0x33/*send data check*/
-#define CMD_BOOT_READ  0x44/*send wait bl data ready*/
-#define BOOT_RDY   0xFF/*bl data ready*/
-/*I2C main command*/
-#define CMD_QUERY_BANK 0x2B
-#define CMD_DATA_BANK  0x4D
-#define CMD_ENTER_SLEEP0x4E
-#define CMD_BANK_SWITCH0xAA
+/* Slave I2C mode */
+#define RM_BOOT_BLDR   0x02
+#define RM_BOOT_MAIN   0x03
 
-/* Touch relative info */
-#define MAX_RETRIES3
-#define MAX_TOUCH_NUM  10
-#define MAX_PkG_SIZE   50
-#define BOOT_DELAY_MS  100
+/* I2C bootoloader commands */
+#define RM_CMD_BOOT_PAGE_WRT   0x0B/* send bl page write */
+#define RM_CMD_BOOT_WRT0x11/* send bl write */
+#define RM_CMD_BOOT_ACK0x22/* send ack*/
+#define RM_CMD_BOOT_CHK0x33/* send data check */
+#define RM_CMD_BOOT_READ   0x44/* send wait bl data ready*/
 
-/*Bootloader relative info */
-#define CMD_BOOT_HEADER_LEN3   /*bl flash wrt cmd size*/
-#define RAYDIUM_TRANS_BUFSIZE  32  /*bl wrt pkg size*/
-#define MAX_BOOT_WRT_LEN   (RAYDIUM_TRANS_BUFSIZE + CMD_BOOT_HEADER_LEN)
-#define MAX_FW_UPDATE_RETRIES  30
+#define RM_BOOT_RDY0xFF/* bl data ready */
+
+/* I2C main commands */
+#define RM_CMD_QUERY_BANK  0x2B
+#define RM_CMD_DATA_BANK   0x4D
+#define RM_CMD_ENTER_SLEEP 0x4E
+#define RM_CMD_BANK_SWITCH 0xAA
+
+#define RM_RESET_MSG_ADDR  0x4004
+#define RM_FASTBOOT_MSG_ADDR   0x5620
+
+#define RM_MAX_READ_SIZE   63
+
+/* Touch relative info */
+#define RM_MAX_RETRIES 3
+#define RM_MAX_TOUCH_NUM   10
+#define RM_BOOT_DELAY_MS   100
+
+/* Offsets in contact data */
+#define RM_CONTACT_STATE_POS   0
+#define RM_CONTACT_X_POS   1
+#define RM_CONTACT_Y_POS   3
+#define RM_CONTACT_PRESSURE_POS5 // XXX - check - original was 4
+#define RM_CONTACT_WIDTH_X_POS 6
+#define RM_CONTACT_WIDTH_Y_POS 7
+
+/* Bootloader relative info */
+#define RM_BL_WRT_CMD_SIZE 3   /* bl flash wrt cmd size */
+#define RM_BL_WRT_PKG_SIZE 32  /* bl wrt pkg size */
+#define RM_BL_WRT_LEN  (RM_BL_WRT_PKG_SIZE + RM_BL_WRT_CMD_SIZE)
+#define RM_FW_PAGE_SIZE128
+#define RM_MAX_FW_RETRIES  30
+
+#define RM_POWERON_DELAY_USEC  500
+#define RM_RESET_DELAY_MSEC50
 
 enum raydium_bl_cmd {
-   HEADER = 0,
-   PAGE_STR,
-   PKG_IDX,
-   DATA_STR,
+   BL_HEADER = 0,
+   BL_PAGE_STR,
+   BL_PKG_IDX,
+   BL_DATA_STR,
 };
 
 enum raydium_bl_ack {
-   ACK_NULL = 0,
-   WAIT_READY,
-   PATH_READY,
+   RAYDIUM_ACK_NULL = 0,
+   RAYDIUM_WAIT_READY,
+   RAYDIUM_PATH_READY,
 };
 
-#define RAYDIUM_PAGE_SIZE  128
-#define RAYDIUM_POWERON_DELAY_USEC 500
-#define RAYDIUM_RESET_DELAY_MSEC   50
-
-#define ADDR_INDEX 0x03
-#define DATA_INDEX 0x04
-
-#define HEADER_SIZE4
-
 enum raydium_boot_mode {

Re: [PATCH] driver: input :touchscreen : add Raydium I2C touch driver

[Dmitry Torokhov]

Hi Jeffrey,
On Fri, Apr 29, 2016 at 05:45:13PM +0800, jeffrey.lin wrote:
> Raydium I2C touch driver.
> 
> Signed-off-by: jeffrey.lin 

I was looking at the driver and there were a few issues (buffer
overflows, forgetting releasing firmware, general flow, etc), that I
tried correcting in the attached patch. Please try incorporating it into
yours (it should apply to this version of Raydium driver) and let me
know if it still works. There are a few questionable points that I
marked with "XXX FIXME" in the code, please respond to them by either
confirming that they are correct or fixing them.

Thanks.

-- 
Dmitry


Input: raydium misc changes

From: Dmitry Torokhov 

Signed-off-by: Dmitry Torokhov 
---
 drivers/input/touchscreen/raydium_i2c_ts.c |  941 ++--
 1 file changed, 482 insertions(+), 459 deletions(-)

diff --git a/drivers/input/touchscreen/raydium_i2c_ts.c 
b/drivers/input/touchscreen/raydium_i2c_ts.c
index cee46e8..1e4e3de 100644
--- a/drivers/input/touchscreen/raydium_i2c_ts.c
+++ b/drivers/input/touchscreen/raydium_i2c_ts.c
@@ -20,107 +20,105 @@
  * Contact Raydium Semiconductor Corporation at www.rad-ic.com
  */
 
-#include 
-#include 
-#include 
-#include 
+#include 
 #include 
-#include 
 #include 
+#include 
+#include 
+#include 
 #include 
-#include 
+#include 
+#include 
 #include 
 #include 
+#include 
 #include 
-#include 
 
-/* Device, Driver information */
-#define DEVICE_NAME"raydium_i2c"
-
-/* Slave I2C mode*/
-#define RM_BOOT_BLDR   0x02
-#define RM_BOOT_MAIN   0x03
-
-/*I2C bl command */
-#define CMD_BOOT_PAGE_WRT  0x0B/*send bl page write*/
-#define CMD_BOOT_WRT   0x11/*send bl write*/
-#define CMD_BOOT_ACK   0x22/*send ack*/
-#define CMD_BOOT_CHK   0x33/*send data check*/
-#define CMD_BOOT_READ  0x44/*send wait bl data ready*/
-#define BOOT_RDY   0xFF/*bl data ready*/
-/*I2C main command*/
-#define CMD_QUERY_BANK 0x2B
-#define CMD_DATA_BANK  0x4D
-#define CMD_ENTER_SLEEP0x4E
-#define CMD_BANK_SWITCH0xAA
+/* Slave I2C mode */
+#define RM_BOOT_BLDR   0x02
+#define RM_BOOT_MAIN   0x03
 
-/* Touch relative info */
-#define MAX_RETRIES3
-#define MAX_TOUCH_NUM  10
-#define MAX_PkG_SIZE   50
-#define BOOT_DELAY_MS  100
+/* I2C bootoloader commands */
+#define RM_CMD_BOOT_PAGE_WRT   0x0B/* send bl page write */
+#define RM_CMD_BOOT_WRT0x11/* send bl write */
+#define RM_CMD_BOOT_ACK0x22/* send ack*/
+#define RM_CMD_BOOT_CHK0x33/* send data check */
+#define RM_CMD_BOOT_READ   0x44/* send wait bl data ready*/
 
-/*Bootloader relative info */
-#define CMD_BOOT_HEADER_LEN3   /*bl flash wrt cmd size*/
-#define RAYDIUM_TRANS_BUFSIZE  32  /*bl wrt pkg size*/
-#define MAX_BOOT_WRT_LEN   (RAYDIUM_TRANS_BUFSIZE + CMD_BOOT_HEADER_LEN)
-#define MAX_FW_UPDATE_RETRIES  30
+#define RM_BOOT_RDY0xFF/* bl data ready */
+
+/* I2C main commands */
+#define RM_CMD_QUERY_BANK  0x2B
+#define RM_CMD_DATA_BANK   0x4D
+#define RM_CMD_ENTER_SLEEP 0x4E
+#define RM_CMD_BANK_SWITCH 0xAA
+
+#define RM_RESET_MSG_ADDR  0x4004
+#define RM_FASTBOOT_MSG_ADDR   0x5620
+
+#define RM_MAX_READ_SIZE   63
+
+/* Touch relative info */
+#define RM_MAX_RETRIES 3
+#define RM_MAX_TOUCH_NUM   10
+#define RM_BOOT_DELAY_MS   100
+
+/* Offsets in contact data */
+#define RM_CONTACT_STATE_POS   0
+#define RM_CONTACT_X_POS   1
+#define RM_CONTACT_Y_POS   3
+#define RM_CONTACT_PRESSURE_POS5 // XXX - check - original was 4
+#define RM_CONTACT_WIDTH_X_POS 6
+#define RM_CONTACT_WIDTH_Y_POS 7
+
+/* Bootloader relative info */
+#define RM_BL_WRT_CMD_SIZE 3   /* bl flash wrt cmd size */
+#define RM_BL_WRT_PKG_SIZE 32  /* bl wrt pkg size */
+#define RM_BL_WRT_LEN  (RM_BL_WRT_PKG_SIZE + RM_BL_WRT_CMD_SIZE)
+#define RM_FW_PAGE_SIZE128
+#define RM_MAX_FW_RETRIES  30
+
+#define RM_POWERON_DELAY_USEC  500
+#define RM_RESET_DELAY_MSEC50
 
 enum raydium_bl_cmd {
-   HEADER = 0,
-   PAGE_STR,
-   PKG_IDX,
-   DATA_STR,
+   BL_HEADER = 0,
+   BL_PAGE_STR,
+   BL_PKG_IDX,
+   BL_DATA_STR,
 };
 
 enum raydium_bl_ack {
-   ACK_NULL = 0,
-   WAIT_READY,
-   PATH_READY,
+   RAYDIUM_ACK_NULL = 0,
+   RAYDIUM_WAIT_READY,
+   RAYDIUM_PATH_READY,
 };
 
-#define RAYDIUM_PAGE_SIZE  128
-#define RAYDIUM_POWERON_DELAY_USEC 500
-#define RAYDIUM_RESET_DELAY_MSEC   50
-
-#define ADDR_INDEX 0x03
-#define DATA_INDEX 0x04
-
-#define HEADER_SIZE4
-
 enum raydium_boot_mode {
RAYDIUM_TS_MAIN = 0,
RAYDIUM_TS_BLDR,
 };
 
-enum raydium_abs_idx {
-   

Re: [PATCH 2/2] mm, oom: protect !costly allocations some more for !CONFIG_COMPACTION

[Hillf Danton]

> From: Michal Hocko 
> 
> Joonsoo has reported that he is able to trigger OOM for !costly high
> order requests (heavy fork() workload close the OOM) with the new
> oom detection rework. This is because we rely only on should_reclaim_retry
> when the compaction is disabled and it only checks watermarks for the
> requested order and so we might trigger OOM when there is a lot of free
> memory.
> 
> It is not very clear what are the usual workloads when the compaction
> is disabled. Relying on high order allocations heavily without any
> mechanism to create those orders except for unbound amount of reclaim is
> certainly not a good idea.
> 
> To prevent from potential regressions let's help this configuration
> some. We have to sacrifice the determinsm though because there simply is
> none here possible. should_compact_retry implementation for
> !CONFIG_COMPACTION, which was empty so far, will do watermark check
> for order-0 on all eligible zones. This will cause retrying until either
> the reclaim cannot make any further progress or all the zones are
> depleted even for order-0 pages. This means that the number of retries
> is basically unbounded for !costly orders but that was the case before
> the rework as well so this shouldn't regress.
> 
> Reported-by: Joonsoo Kim 
> Signed-off-by: Michal Hocko 
> ---
Acked-by: Hillf Danton 

>  mm/page_alloc.c | 18 ++
>  1 file changed, 18 insertions(+)
> 
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 620ec002aea2..7e2defbfe55b 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -3310,6 +3310,24 @@ should_compact_retry(struct alloc_context *ac, 
> unsigned int order, int alloc_fla
>enum migrate_mode *migrate_mode,
>int compaction_retries)
>  {
> + struct zone *zone;
> + struct zoneref *z;
> +
> + if (!order || order > PAGE_ALLOC_COSTLY_ORDER)
> + return false;
> +
> + /*
> +  * There are setups with compaction disabled which would prefer to loop
> +  * inside the allocator rather than hit the oom killer prematurely. 
> Let's
> +  * give them a good hope and keep retrying while the order-0 watermarks
> +  * are OK.
> +  */
> + for_each_zone_zonelist_nodemask(zone, z, ac->zonelist, ac->high_zoneidx,
> + ac->nodemask) {
> + if(zone_watermark_ok(zone, 0, min_wmark_pages(zone),

s/if(zone_/if (zone_/
> + ac_classzone_idx(ac), alloc_flags))
> + return true;
> + }
>   return false;
>  }
>  #endif /* CONFIG_COMPACTION */
> --
> 2.8.1

Re: [PATCH 2/2] mm, oom: protect !costly allocations some more for !CONFIG_COMPACTION

[Hillf Danton]

> From: Michal Hocko 
> 
> Joonsoo has reported that he is able to trigger OOM for !costly high
> order requests (heavy fork() workload close the OOM) with the new
> oom detection rework. This is because we rely only on should_reclaim_retry
> when the compaction is disabled and it only checks watermarks for the
> requested order and so we might trigger OOM when there is a lot of free
> memory.
> 
> It is not very clear what are the usual workloads when the compaction
> is disabled. Relying on high order allocations heavily without any
> mechanism to create those orders except for unbound amount of reclaim is
> certainly not a good idea.
> 
> To prevent from potential regressions let's help this configuration
> some. We have to sacrifice the determinsm though because there simply is
> none here possible. should_compact_retry implementation for
> !CONFIG_COMPACTION, which was empty so far, will do watermark check
> for order-0 on all eligible zones. This will cause retrying until either
> the reclaim cannot make any further progress or all the zones are
> depleted even for order-0 pages. This means that the number of retries
> is basically unbounded for !costly orders but that was the case before
> the rework as well so this shouldn't regress.
> 
> Reported-by: Joonsoo Kim 
> Signed-off-by: Michal Hocko 
> ---
Acked-by: Hillf Danton 

>  mm/page_alloc.c | 18 ++
>  1 file changed, 18 insertions(+)
> 
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 620ec002aea2..7e2defbfe55b 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -3310,6 +3310,24 @@ should_compact_retry(struct alloc_context *ac, 
> unsigned int order, int alloc_fla
>enum migrate_mode *migrate_mode,
>int compaction_retries)
>  {
> + struct zone *zone;
> + struct zoneref *z;
> +
> + if (!order || order > PAGE_ALLOC_COSTLY_ORDER)
> + return false;
> +
> + /*
> +  * There are setups with compaction disabled which would prefer to loop
> +  * inside the allocator rather than hit the oom killer prematurely. 
> Let's
> +  * give them a good hope and keep retrying while the order-0 watermarks
> +  * are OK.
> +  */
> + for_each_zone_zonelist_nodemask(zone, z, ac->zonelist, ac->high_zoneidx,
> + ac->nodemask) {
> + if(zone_watermark_ok(zone, 0, min_wmark_pages(zone),

s/if(zone_/if (zone_/
> + ac_classzone_idx(ac), alloc_flags))
> + return true;
> + }
>   return false;
>  }
>  #endif /* CONFIG_COMPACTION */
> --
> 2.8.1

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

[Andrew Lunn]

> >>+   gpiod = fwnode_get_named_gpiod(>fwnode, "reset-gpios");
> >>+   /* Deassert the reset signal */
> >>+   if (!IS_ERR(gpiod))
> >>+   gpiod_direction_output(gpiod, 0);
> >
> >This is wrong I think. You must only ignore -ENODEV, all other error
> 
>At least -ENOSYS should also be ignored (it's returned when
> gpiolib is not configured), right? When does -ENODEV gets returned
> (it's not easy to follow)?
> 
> >codes should be passed to the caller.
> 
>The caller doesn't care anyway...

It should do. What if fwnode_get_named_gpiod() returns -EPROBE_DEFER
because the GPIO driver has not been loaded yet?

Andrew

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

[Andrew Lunn]

> >>+   gpiod = fwnode_get_named_gpiod(>fwnode, "reset-gpios");
> >>+   /* Deassert the reset signal */
> >>+   if (!IS_ERR(gpiod))
> >>+   gpiod_direction_output(gpiod, 0);
> >
> >This is wrong I think. You must only ignore -ENODEV, all other error
> 
>At least -ENOSYS should also be ignored (it's returned when
> gpiolib is not configured), right? When does -ENODEV gets returned
> (it's not easy to follow)?
> 
> >codes should be passed to the caller.
> 
>The caller doesn't care anyway...

It should do. What if fwnode_get_named_gpiod() returns -EPROBE_DEFER
because the GPIO driver has not been loaded yet?

Andrew

Re: [PATCH 1/2] mmotm: mm-oom-rework-oom-detection-fix

[Hillf Danton]

> From: Michal Hocko 
> 
> watermark check should use classzone_idx rather than high_zoneidx
> to check reserves against the correct (preferred) zone.
> 
> Signed-off-by: Michal Hocko 
> ---
Acked-by: Hillf Danton 

>  mm/page_alloc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 0d9008042efa..620ec002aea2 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -3496,7 +3496,7 @@ should_reclaim_retry(gfp_t gfp_mask, unsigned order,
>* available?
>*/
>   if (__zone_watermark_ok(zone, order, min_wmark_pages(zone),
> - ac->high_zoneidx, alloc_flags, available)) {
> + ac_classzone_idx(ac), alloc_flags, available)) {
>   /*
>* If we didn't make any progress and have a lot of
>* dirty + writeback pages then we should wait for
> --
> 2.8.1

Re: [PATCH 1/2] mmotm: mm-oom-rework-oom-detection-fix

[Hillf Danton]

> From: Michal Hocko 
> 
> watermark check should use classzone_idx rather than high_zoneidx
> to check reserves against the correct (preferred) zone.
> 
> Signed-off-by: Michal Hocko 
> ---
Acked-by: Hillf Danton 

>  mm/page_alloc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 0d9008042efa..620ec002aea2 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -3496,7 +3496,7 @@ should_reclaim_retry(gfp_t gfp_mask, unsigned order,
>* available?
>*/
>   if (__zone_watermark_ok(zone, order, min_wmark_pages(zone),
> - ac->high_zoneidx, alloc_flags, available)) {
> + ac_classzone_idx(ac), alloc_flags, available)) {
>   /*
>* If we didn't make any progress and have a lot of
>* dirty + writeback pages then we should wait for
> --
> 2.8.1

Re: [RFC 2/3] drm/mediatek: add support for Mediatek SoC MT2701

[CK Hu]

Hi, YT:

On Thu, 2016-05-12 at 19:49 +0800, yt.s...@mediatek.com wrote:
> From: YT Shen 
> 
> This patch add support for the Mediatek MT2701 DISP subsystem.
> There is only one OVL engine in MT2701, and we have shadow
> register support here.
> 
> Signed-off-by: YT Shen 
> ---

> @@ -385,12 +422,16 @@ static void mtk_drm_crtc_atomic_begin(struct drm_crtc 
> *crtc,
>   mtk_crtc->event = state->base.event;
>   state->base.event = NULL;
>   }
> +
> + if (priv->data->shadow_register)
> + mtk_disp_mutex_acquire(mtk_crtc->mutex);
>  }
>  
> @@ -409,6 +450,11 @@ static void mtk_drm_crtc_atomic_flush(struct drm_crtc 
> *crtc,
>   }
>   if (pending_planes)
>   mtk_crtc->pending_planes = true;
> +
> + if (priv->data->shadow_register) {
> + mtk_crtc_ddp_config(crtc);
> + mtk_disp_mutex_release(mtk_crtc->mutex);
> + }
>  }
>  

I think it's better to call mtk_disp_mutex_acquire() and
mtk_disp_mutex_release() as near as possible to prevent mutex locked for
a long time. All HW register access of this atomic setting is in
mtk_crtc_ddp_config(), so it's better to move mtk_disp_mutex_acquire()
just before mtk_crtc_ddp_config().

Regards,
CK

Re: [RFC 2/3] drm/mediatek: add support for Mediatek SoC MT2701

[CK Hu]

Hi, YT:

On Thu, 2016-05-12 at 19:49 +0800, yt.s...@mediatek.com wrote:
> From: YT Shen 
> 
> This patch add support for the Mediatek MT2701 DISP subsystem.
> There is only one OVL engine in MT2701, and we have shadow
> register support here.
> 
> Signed-off-by: YT Shen 
> ---

> @@ -385,12 +422,16 @@ static void mtk_drm_crtc_atomic_begin(struct drm_crtc 
> *crtc,
>   mtk_crtc->event = state->base.event;
>   state->base.event = NULL;
>   }
> +
> + if (priv->data->shadow_register)
> + mtk_disp_mutex_acquire(mtk_crtc->mutex);
>  }
>  
> @@ -409,6 +450,11 @@ static void mtk_drm_crtc_atomic_flush(struct drm_crtc 
> *crtc,
>   }
>   if (pending_planes)
>   mtk_crtc->pending_planes = true;
> +
> + if (priv->data->shadow_register) {
> + mtk_crtc_ddp_config(crtc);
> + mtk_disp_mutex_release(mtk_crtc->mutex);
> + }
>  }
>  

I think it's better to call mtk_disp_mutex_acquire() and
mtk_disp_mutex_release() as near as possible to prevent mutex locked for
a long time. All HW register access of this atomic setting is in
mtk_crtc_ddp_config(), so it's better to move mtk_disp_mutex_acquire()
just before mtk_crtc_ddp_config().

Regards,
CK

why the count nr_file_pages is not equal to nr_inactive_file + nr_active_file ?

[Xishi Qiu]

I find the count nr_file_pages is not equal to nr_inactive_file + 
nr_active_file.
There are 8 cpus, 2 zones in my system.

I think may be the pagevec trigger the problem, but PAGEVEC_SIZE is only 14.
Does anyone know the reason?

Thanks,
Xishi Qiu

root@hi3650:/ # cat /proc/vmstat 
nr_free_pages 54192
nr_inactive_anon 39830
nr_active_anon 28794
nr_inactive_file 432444
nr_active_file 20659
nr_unevictable 2363
nr_mlock 0
nr_anon_pages 65249
nr_mapped 19742
nr_file_pages 462723
nr_dirty 20
nr_writeback 0
...


nr_inactive_file 432444
nr_active_file 20659
total is 453103

nr_file_pages 462723

why the count nr_file_pages is not equal to nr_inactive_file + nr_active_file ?

[Xishi Qiu]

I find the count nr_file_pages is not equal to nr_inactive_file + 
nr_active_file.
There are 8 cpus, 2 zones in my system.

I think may be the pagevec trigger the problem, but PAGEVEC_SIZE is only 14.
Does anyone know the reason?

Thanks,
Xishi Qiu

root@hi3650:/ # cat /proc/vmstat 
nr_free_pages 54192
nr_inactive_anon 39830
nr_active_anon 28794
nr_inactive_file 432444
nr_active_file 20659
nr_unevictable 2363
nr_mlock 0
nr_anon_pages 65249
nr_mapped 19742
nr_file_pages 462723
nr_dirty 20
nr_writeback 0
...


nr_inactive_file 432444
nr_active_file 20659
total is 453103

nr_file_pages 462723

[PATCH v3 0/2] mfd: lp873x: Add lp873x PMIC support

[Keerthy]

The LP873X chip is a power management IC for Portable Navigation Systems
and Tablet Computing devices. It contains the following components:

 - Regulators.
 - Configurable General Purpose Output Signals(GPO).

PMIC interacts with the main processor through i2c. PMIC has
couple of LDOs(Linear Regulators), couple of BUCKs (Step-Down DC-DC
Converter Cores) and GPOs(General Purpose Output Signals). At this
time only the regulator functionality is made available.

The regulator patch is already queued:
http://marc.info/?l=linux-kernel=146298767110771=2

Hence posting the remaining patches of the series with
the comments fixed on mfd driver. 

Keerthy (2):
  Documentation: mfd: LP873X: Add information for the mfd and regulator
drivers
  mfd: lp873x: Add lp873x PMIC support

 Documentation/devicetree/bindings/mfd/lp873x.txt |  55 +
 drivers/mfd/Kconfig  |  14 ++
 drivers/mfd/Makefile |   2 +
 drivers/mfd/lp873x.c |  96 +
 include/linux/mfd/lp873x.h   | 264 +++
 5 files changed, 431 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/lp873x.txt
 create mode 100644 drivers/mfd/lp873x.c
 create mode 100644 include/linux/mfd/lp873x.h

-- 
1.9.1

[PATCH v3 2/2] mfd: lp873x: Add lp873x PMIC support

[Keerthy]

The LP873X chip is a power management IC for Portable Navigation Systems
and Tablet Computing devices. It contains the following components:

 - Regulators.
 - Configurable General Purpose Output Signals(GPO).

PMIC interacts with the main processor through i2c. PMIC has
couple of LDOs(Linear Regulators), couple of BUCKs (Step-Down DC-DC
Converter Cores) and GPOs(General Purpose Output Signals).

Signed-off-by: Keerthy 
---

Changes in v3:

  * Reordered the probe code.
  * Fixed Typo in Kconfig description.
  * Removed unused member from struct lp873x.

 drivers/mfd/Kconfig|  14 +++
 drivers/mfd/Makefile   |   2 +
 drivers/mfd/lp873x.c   |  96 +
 include/linux/mfd/lp873x.h | 264 +
 4 files changed, 376 insertions(+)
 create mode 100644 drivers/mfd/lp873x.c
 create mode 100644 include/linux/mfd/lp873x.h

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index eea61e3..a7e48e7 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1185,6 +1185,20 @@ config MFD_TPS65217
  This driver can also be built as a module.  If so, the module
  will be called tps65217.
 
+config MFD_LP873X
+   tristate "TI LP873X Power Management IC"
+   depends on I2C
+   select MFD_CORE
+   select REGMAP_I2C
+   help
+ If you say yes here then you get support for the LP873X series of
+ power management integrated circuits(PMIC).
+ These include voltage regulators, Thermal protection, Configurable
+ general purpose outputs(GPO) that are used in portable devices.
+
+ This driver can also be built as a module.  If so, the module
+ will be called lp873x.
+
 config MFD_TPS65218
tristate "TI TPS65218 Power Management chips"
depends on I2C
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 5eaa6465d..617c688 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -22,6 +22,8 @@ obj-$(CONFIG_HTC_EGPIO)   += htc-egpio.o
 obj-$(CONFIG_HTC_PASIC3)   += htc-pasic3.o
 obj-$(CONFIG_HTC_I2CPLD)   += htc-i2cpld.o
 
+obj-$(CONFIG_MFD_LP873X)   += lp873x.o
+
 obj-$(CONFIG_MFD_DAVINCI_VOICECODEC)   += davinci_voicecodec.o
 obj-$(CONFIG_MFD_DM355EVM_MSP) += dm355evm_msp.o
 obj-$(CONFIG_MFD_TI_AM335X_TSCADC) += ti_am335x_tscadc.o
diff --git a/drivers/mfd/lp873x.c b/drivers/mfd/lp873x.c
new file mode 100644
index 000..ba49d56
--- /dev/null
+++ b/drivers/mfd/lp873x.c
@@ -0,0 +1,96 @@
+/*
+ * Copyright (C) 2016 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+static const struct regmap_config lp873x_regmap_config = {
+   .reg_bits = 8,
+   .val_bits = 8,
+   .max_register = LP873X_REG_MAX,
+};
+
+static const struct mfd_cell lp873x_cells[] = {
+   { .name = "lp873x-regulator", },
+};
+
+static int lp873x_probe(struct i2c_client *client,
+   const struct i2c_device_id *ids)
+{
+   struct lp873x *lp873;
+   int ret;
+   unsigned int otpid;
+
+   lp873 = devm_kzalloc(>dev, sizeof(*lp873), GFP_KERNEL);
+   if (!lp873)
+   return -ENOMEM;
+
+   lp873->dev = >dev;
+
+   lp873->regmap = devm_regmap_init_i2c(client, _regmap_config);
+   if (IS_ERR(lp873->regmap)) {
+   ret = PTR_ERR(lp873->regmap);
+   dev_err(lp873->dev, "Failed to initialize register map: %d\n",
+   ret);
+   return ret;
+   }
+
+   mutex_init(>lp873_lock);
+
+   ret = regmap_read(lp873->regmap, LP873X_REG_OTP_REV, );
+   if (ret) {
+   dev_err(lp873->dev, "Failed to read OTP ID\n");
+   return ret;
+   }
+
+   lp873->rev = otpid & LP873X_OTP_REV_OTP_ID;
+   i2c_set_clientdata(client, lp873);
+   ret = mfd_add_devices(lp873->dev, PLATFORM_DEVID_AUTO, lp873x_cells,
+ ARRAY_SIZE(lp873x_cells), NULL, 0, NULL);
+
+   return ret;
+}
+
+static const struct of_device_id of_lp873x_match_table[] = {
+   { .compatible = "ti,lp8733", },
+   { .compatible = "ti,lp8732", },
+   {}
+};
+MODULE_DEVICE_TABLE(of, of_lp873x_match_table);
+
+static const struct i2c_device_id lp873x_id_table[] = {
+   { "lp873x", LP873X },
+   { "lp8732", LP873X },
+   { "lp8733", LP873X },
+   { },
+};
+MODULE_DEVICE_TABLE(i2c, lp873x_id_table);
+
+static struct i2c_driver lp873x_driver = {

[PATCH v3 0/2] mfd: lp873x: Add lp873x PMIC support

[Keerthy]

The LP873X chip is a power management IC for Portable Navigation Systems
and Tablet Computing devices. It contains the following components:

 - Regulators.
 - Configurable General Purpose Output Signals(GPO).

PMIC interacts with the main processor through i2c. PMIC has
couple of LDOs(Linear Regulators), couple of BUCKs (Step-Down DC-DC
Converter Cores) and GPOs(General Purpose Output Signals). At this
time only the regulator functionality is made available.

The regulator patch is already queued:
http://marc.info/?l=linux-kernel=146298767110771=2

Hence posting the remaining patches of the series with
the comments fixed on mfd driver. 

Keerthy (2):
  Documentation: mfd: LP873X: Add information for the mfd and regulator
drivers
  mfd: lp873x: Add lp873x PMIC support

 Documentation/devicetree/bindings/mfd/lp873x.txt |  55 +
 drivers/mfd/Kconfig  |  14 ++
 drivers/mfd/Makefile |   2 +
 drivers/mfd/lp873x.c |  96 +
 include/linux/mfd/lp873x.h   | 264 +++
 5 files changed, 431 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/lp873x.txt
 create mode 100644 drivers/mfd/lp873x.c
 create mode 100644 include/linux/mfd/lp873x.h

-- 
1.9.1

[PATCH v3 2/2] mfd: lp873x: Add lp873x PMIC support

[Keerthy]

The LP873X chip is a power management IC for Portable Navigation Systems
and Tablet Computing devices. It contains the following components:

 - Regulators.
 - Configurable General Purpose Output Signals(GPO).

PMIC interacts with the main processor through i2c. PMIC has
couple of LDOs(Linear Regulators), couple of BUCKs (Step-Down DC-DC
Converter Cores) and GPOs(General Purpose Output Signals).

Signed-off-by: Keerthy 
---

Changes in v3:

  * Reordered the probe code.
  * Fixed Typo in Kconfig description.
  * Removed unused member from struct lp873x.

 drivers/mfd/Kconfig|  14 +++
 drivers/mfd/Makefile   |   2 +
 drivers/mfd/lp873x.c   |  96 +
 include/linux/mfd/lp873x.h | 264 +
 4 files changed, 376 insertions(+)
 create mode 100644 drivers/mfd/lp873x.c
 create mode 100644 include/linux/mfd/lp873x.h

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index eea61e3..a7e48e7 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1185,6 +1185,20 @@ config MFD_TPS65217
  This driver can also be built as a module.  If so, the module
  will be called tps65217.
 
+config MFD_LP873X
+   tristate "TI LP873X Power Management IC"
+   depends on I2C
+   select MFD_CORE
+   select REGMAP_I2C
+   help
+ If you say yes here then you get support for the LP873X series of
+ power management integrated circuits(PMIC).
+ These include voltage regulators, Thermal protection, Configurable
+ general purpose outputs(GPO) that are used in portable devices.
+
+ This driver can also be built as a module.  If so, the module
+ will be called lp873x.
+
 config MFD_TPS65218
tristate "TI TPS65218 Power Management chips"
depends on I2C
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 5eaa6465d..617c688 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -22,6 +22,8 @@ obj-$(CONFIG_HTC_EGPIO)   += htc-egpio.o
 obj-$(CONFIG_HTC_PASIC3)   += htc-pasic3.o
 obj-$(CONFIG_HTC_I2CPLD)   += htc-i2cpld.o
 
+obj-$(CONFIG_MFD_LP873X)   += lp873x.o
+
 obj-$(CONFIG_MFD_DAVINCI_VOICECODEC)   += davinci_voicecodec.o
 obj-$(CONFIG_MFD_DM355EVM_MSP) += dm355evm_msp.o
 obj-$(CONFIG_MFD_TI_AM335X_TSCADC) += ti_am335x_tscadc.o
diff --git a/drivers/mfd/lp873x.c b/drivers/mfd/lp873x.c
new file mode 100644
index 000..ba49d56
--- /dev/null
+++ b/drivers/mfd/lp873x.c
@@ -0,0 +1,96 @@
+/*
+ * Copyright (C) 2016 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+static const struct regmap_config lp873x_regmap_config = {
+   .reg_bits = 8,
+   .val_bits = 8,
+   .max_register = LP873X_REG_MAX,
+};
+
+static const struct mfd_cell lp873x_cells[] = {
+   { .name = "lp873x-regulator", },
+};
+
+static int lp873x_probe(struct i2c_client *client,
+   const struct i2c_device_id *ids)
+{
+   struct lp873x *lp873;
+   int ret;
+   unsigned int otpid;
+
+   lp873 = devm_kzalloc(>dev, sizeof(*lp873), GFP_KERNEL);
+   if (!lp873)
+   return -ENOMEM;
+
+   lp873->dev = >dev;
+
+   lp873->regmap = devm_regmap_init_i2c(client, _regmap_config);
+   if (IS_ERR(lp873->regmap)) {
+   ret = PTR_ERR(lp873->regmap);
+   dev_err(lp873->dev, "Failed to initialize register map: %d\n",
+   ret);
+   return ret;
+   }
+
+   mutex_init(>lp873_lock);
+
+   ret = regmap_read(lp873->regmap, LP873X_REG_OTP_REV, );
+   if (ret) {
+   dev_err(lp873->dev, "Failed to read OTP ID\n");
+   return ret;
+   }
+
+   lp873->rev = otpid & LP873X_OTP_REV_OTP_ID;
+   i2c_set_clientdata(client, lp873);
+   ret = mfd_add_devices(lp873->dev, PLATFORM_DEVID_AUTO, lp873x_cells,
+ ARRAY_SIZE(lp873x_cells), NULL, 0, NULL);
+
+   return ret;
+}
+
+static const struct of_device_id of_lp873x_match_table[] = {
+   { .compatible = "ti,lp8733", },
+   { .compatible = "ti,lp8732", },
+   {}
+};
+MODULE_DEVICE_TABLE(of, of_lp873x_match_table);
+
+static const struct i2c_device_id lp873x_id_table[] = {
+   { "lp873x", LP873X },
+   { "lp8732", LP873X },
+   { "lp8733", LP873X },
+   { },
+};
+MODULE_DEVICE_TABLE(i2c, lp873x_id_table);
+
+static struct i2c_driver lp873x_driver = {
+   .driver   

[PATCH v3 1/2] Documentation: mfd: LP873X: Add information for the mfd and regulator drivers

[Keerthy]

Add information for the mfd and regulator drivers.

Acked-by: Rob Herring 
Signed-off-by: Keerthy 
---

Changes in v3:

  * Changed the example node lable to pmic from lp8733.

 Documentation/devicetree/bindings/mfd/lp873x.txt | 55 
 1 file changed, 55 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/lp873x.txt

diff --git a/Documentation/devicetree/bindings/mfd/lp873x.txt 
b/Documentation/devicetree/bindings/mfd/lp873x.txt
new file mode 100644
index 000..8f3ef0d
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/lp873x.txt
@@ -0,0 +1,55 @@
+TI LP3943 MFD driver
+
+Required properties:
+  - compatible: "ti,lp8732", "ti,lp8733"
+  - reg: I2C slave address.
+
+For the lp873x regulator properties please refer to:
+../bindings/regulator/lp873x.txt
+
+Example:
+
+pmic: lp8733@60 {
+   compatible = "ti,lp8733";
+   reg = <0x60>;
+
+   regulators {
+   lp8733_buck0: buck0 {
+   regulator-name = "lp8733-buck0";
+   regulator-min-microvolt = <80>;
+   regulator-max-microvolt = <140>;
+   regulator-min-microamp = <150>;
+   regulator-max-microamp = <400>;
+   regulator-ramp-delay = <1>;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+
+   lp8733_buck1: buck1 {
+   regulator-name = "lp8733-buck1";
+   regulator-min-microvolt = <80>;
+   regulator-max-microvolt = <140>;
+   regulator-min-microamp = <150>;
+   regulator-max-microamp = <400>;
+   regulator-ramp-delay = <1>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+
+   lp8733_ldo0: ldo0 {
+   regulator-name = "lp8733-ldo0";
+   regulator-min-microvolt = <80>;
+   regulator-max-microvolt = <300>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+
+   lp8733_ldo1: ldo1 {
+   regulator-name = "lp8733-ldo1";
+   regulator-min-microvolt = <80>;
+   regulator-max-microvolt = <300>;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+   };
+};
-- 
1.9.1

[PATCH v3 1/2] Documentation: mfd: LP873X: Add information for the mfd and regulator drivers

[Keerthy]

Add information for the mfd and regulator drivers.

Acked-by: Rob Herring 
Signed-off-by: Keerthy 
---

Changes in v3:

  * Changed the example node lable to pmic from lp8733.

 Documentation/devicetree/bindings/mfd/lp873x.txt | 55 
 1 file changed, 55 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/lp873x.txt

diff --git a/Documentation/devicetree/bindings/mfd/lp873x.txt 
b/Documentation/devicetree/bindings/mfd/lp873x.txt
new file mode 100644
index 000..8f3ef0d
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/lp873x.txt
@@ -0,0 +1,55 @@
+TI LP3943 MFD driver
+
+Required properties:
+  - compatible: "ti,lp8732", "ti,lp8733"
+  - reg: I2C slave address.
+
+For the lp873x regulator properties please refer to:
+../bindings/regulator/lp873x.txt
+
+Example:
+
+pmic: lp8733@60 {
+   compatible = "ti,lp8733";
+   reg = <0x60>;
+
+   regulators {
+   lp8733_buck0: buck0 {
+   regulator-name = "lp8733-buck0";
+   regulator-min-microvolt = <80>;
+   regulator-max-microvolt = <140>;
+   regulator-min-microamp = <150>;
+   regulator-max-microamp = <400>;
+   regulator-ramp-delay = <1>;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+
+   lp8733_buck1: buck1 {
+   regulator-name = "lp8733-buck1";
+   regulator-min-microvolt = <80>;
+   regulator-max-microvolt = <140>;
+   regulator-min-microamp = <150>;
+   regulator-max-microamp = <400>;
+   regulator-ramp-delay = <1>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+
+   lp8733_ldo0: ldo0 {
+   regulator-name = "lp8733-ldo0";
+   regulator-min-microvolt = <80>;
+   regulator-max-microvolt = <300>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+
+   lp8733_ldo1: ldo1 {
+   regulator-name = "lp8733-ldo1";
+   regulator-min-microvolt = <80>;
+   regulator-max-microvolt = <300>;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+   };
+};
-- 
1.9.1

[Patch v5 0/8] Qualcomm SCM Rework

[Andy Gross]

The following set of patches does a bit of rework on the existing
Qualcomm SCM firmware.  The first couple of patches deals with turning
the current SCM into a platform driver.  The next couple are cleanups
that make adding the 64 support a little easier.  I added in a patch to
convert the scm-32 to use DMA streaming APIs.

I took Kumar's 64 bit support patch and modified it to use the arm_smccc
calls.  This simplified things quite a bit.

Lastly, there are a few DT patches to add the firmware node for a couple of the
supported platforms.

Changes from v4:
  * Fix Documentation error
  * Fix misc review comments

Changes from v3:
  * Added compatibles for the specific platforms requiring one clock.
  * All other platforms will use the generic binding that requires 3 clocks.

Changes from v2:
  * Added use of streaming DMA APIs for scm-32.
  * Changed DT binding to simplify compats.
  * Removed Kconfig.platform change that selected QCOM_SCM for ARM64
  * Fixed misc comments
  * Changed init function to populate the device differently.
  * Fixed missing of_node_put

Changes from v1:
  * Changed binding to reflect proper firmware node usage
  * Added arch_initcall to populate the firmware device, if present
  * Fixed various review comments
  * Removed extraneous includes from SCM 64 file.


Andy Gross (7):
  dt/bindings: firmware: Add Qualcomm SCM binding
  firmware: qcom: scm: Convert SCM to platform driver
  firmware: qcom: scm: Use atomic SCM for cold boot
  firmware: qcom: scm: Generalize shared error map
  firmware: qcom: scm: Convert to streaming DMA APIS
  dts: qcom: apq8084: Add SCM firmware node
  arm64: dts: msm8916: Add SCM firmware node

Kumar Gala (1):
  firmware: qcom: scm: Add support for ARM64 SoCs

 .../devicetree/bindings/firmware/qcom,scm.txt  |  28 +++
 arch/arm/boot/dts/qcom-apq8084.dtsi|   8 +
 arch/arm64/boot/dts/qcom/msm8916.dtsi  |   8 +
 drivers/firmware/qcom_scm-32.c | 271 -
 drivers/firmware/qcom_scm-64.c | 199 ++-
 drivers/firmware/qcom_scm.c| 171 -
 drivers/firmware/qcom_scm.h|  31 ++-
 7 files changed, 523 insertions(+), 193 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/firmware/qcom,scm.txt

-- 
1.9.1

[Patch v5 0/8] Qualcomm SCM Rework

[Andy Gross]

The following set of patches does a bit of rework on the existing
Qualcomm SCM firmware.  The first couple of patches deals with turning
the current SCM into a platform driver.  The next couple are cleanups
that make adding the 64 support a little easier.  I added in a patch to
convert the scm-32 to use DMA streaming APIs.

I took Kumar's 64 bit support patch and modified it to use the arm_smccc
calls.  This simplified things quite a bit.

Lastly, there are a few DT patches to add the firmware node for a couple of the
supported platforms.

Changes from v4:
  * Fix Documentation error
  * Fix misc review comments

Changes from v3:
  * Added compatibles for the specific platforms requiring one clock.
  * All other platforms will use the generic binding that requires 3 clocks.

Changes from v2:
  * Added use of streaming DMA APIs for scm-32.
  * Changed DT binding to simplify compats.
  * Removed Kconfig.platform change that selected QCOM_SCM for ARM64
  * Fixed misc comments
  * Changed init function to populate the device differently.
  * Fixed missing of_node_put

Changes from v1:
  * Changed binding to reflect proper firmware node usage
  * Added arch_initcall to populate the firmware device, if present
  * Fixed various review comments
  * Removed extraneous includes from SCM 64 file.


Andy Gross (7):
  dt/bindings: firmware: Add Qualcomm SCM binding
  firmware: qcom: scm: Convert SCM to platform driver
  firmware: qcom: scm: Use atomic SCM for cold boot
  firmware: qcom: scm: Generalize shared error map
  firmware: qcom: scm: Convert to streaming DMA APIS
  dts: qcom: apq8084: Add SCM firmware node
  arm64: dts: msm8916: Add SCM firmware node

Kumar Gala (1):
  firmware: qcom: scm: Add support for ARM64 SoCs

 .../devicetree/bindings/firmware/qcom,scm.txt  |  28 +++
 arch/arm/boot/dts/qcom-apq8084.dtsi|   8 +
 arch/arm64/boot/dts/qcom/msm8916.dtsi  |   8 +
 drivers/firmware/qcom_scm-32.c | 271 -
 drivers/firmware/qcom_scm-64.c | 199 ++-
 drivers/firmware/qcom_scm.c| 171 -
 drivers/firmware/qcom_scm.h|  31 ++-
 7 files changed, 523 insertions(+), 193 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/firmware/qcom,scm.txt

-- 
1.9.1

[Patch v5 2/8] firmware: qcom: scm: Convert SCM to platform driver

[Andy Gross]

This patch converts the Qualcomm SCM firmware driver into a platform
driver.

Signed-off-by: Andy Gross 
---
 drivers/firmware/qcom_scm.c | 165 +---
 1 file changed, 156 insertions(+), 9 deletions(-)

diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
index 45c008d..4d6ae32 100644
--- a/drivers/firmware/qcom_scm.c
+++ b/drivers/firmware/qcom_scm.c
@@ -10,19 +10,61 @@
  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  * GNU General Public License for more details.
  *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
- * 02110-1301, USA.
  */
-
+#include 
+#include 
 #include 
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 
 #include "qcom_scm.h"
 
+struct qcom_scm {
+   struct device *dev;
+   struct clk *core_clk;
+   struct clk *iface_clk;
+   struct clk *bus_clk;
+};
+
+static struct qcom_scm *__scm;
+
+static int qcom_scm_clk_enable(void)
+{
+   int ret;
+
+   ret = clk_prepare_enable(__scm->core_clk);
+   if (ret)
+   goto bail;
+
+   ret = clk_prepare_enable(__scm->iface_clk);
+   if (ret)
+   goto disable_core;
+
+   ret = clk_prepare_enable(__scm->bus_clk);
+   if (ret)
+   goto disable_iface;
+
+   return 0;
+
+disable_iface:
+   clk_disable_unprepare(__scm->iface_clk);
+disable_core:
+   clk_disable_unprepare(__scm->core_clk);
+bail:
+   return ret;
+}
+
+static void qcom_scm_clk_disable(void)
+{
+   clk_disable_unprepare(__scm->core_clk);
+   clk_disable_unprepare(__scm->iface_clk);
+   clk_disable_unprepare(__scm->bus_clk);
+}
+
 /**
  * qcom_scm_set_cold_boot_addr() - Set the cold boot address for cpus
  * @entry: Entry point function for the cpus
@@ -72,12 +114,17 @@ EXPORT_SYMBOL(qcom_scm_cpu_power_down);
  */
 bool qcom_scm_hdcp_available(void)
 {
-   int ret;
+   int ret = qcom_scm_clk_enable();
+
+   if (ret)
+   return ret;
 
ret = __qcom_scm_is_call_available(QCOM_SCM_SVC_HDCP,
-   QCOM_SCM_CMD_HDCP);
+   QCOM_SCM_CMD_HDCP);
+
+   qcom_scm_clk_disable();
 
-   return (ret > 0) ? true : false;
+   return ret > 0 ? true : false;
 }
 EXPORT_SYMBOL(qcom_scm_hdcp_available);
 
@@ -91,6 +138,106 @@ EXPORT_SYMBOL(qcom_scm_hdcp_available);
  */
 int qcom_scm_hdcp_req(struct qcom_scm_hdcp_req *req, u32 req_cnt, u32 *resp)
 {
-   return __qcom_scm_hdcp_req(req, req_cnt, resp);
+   int ret = qcom_scm_clk_enable();
+
+   if (ret)
+   return ret;
+
+   ret = __qcom_scm_hdcp_req(req, req_cnt, resp);
+   qcom_scm_clk_disable();
+   return ret;
 }
 EXPORT_SYMBOL(qcom_scm_hdcp_req);
+
+static int qcom_scm_probe(struct platform_device *pdev)
+{
+   struct qcom_scm *scm;
+   int ret;
+
+   scm = devm_kzalloc(>dev, sizeof(*scm), GFP_KERNEL);
+   if (!scm)
+   return -ENOMEM;
+
+   scm->core_clk = devm_clk_get(>dev, "core");
+   if (IS_ERR(scm->core_clk)) {
+   if (PTR_ERR(scm->core_clk) != -EPROBE_DEFER)
+   dev_err(>dev, "failed to acquire core clk\n");
+   return PTR_ERR(scm->core_clk);
+   }
+
+   if (of_device_is_compatible(pdev->dev.of_node, "qcom,scm")) {
+   scm->iface_clk = devm_clk_get(>dev, "iface");
+   if (IS_ERR(scm->iface_clk)) {
+   if (PTR_ERR(scm->iface_clk) != -EPROBE_DEFER)
+   dev_err(>dev, "failed to acquire iface 
clk\n");
+   return PTR_ERR(scm->iface_clk);
+   }
+
+   scm->bus_clk = devm_clk_get(>dev, "bus");
+   if (IS_ERR(scm->bus_clk)) {
+   if (PTR_ERR(scm->bus_clk) != -EPROBE_DEFER)
+   dev_err(>dev, "failed to acquire bus 
clk\n");
+   return PTR_ERR(scm->bus_clk);
+   }
+   }
+
+   /* vote for max clk rate for highest performance */
+   ret = clk_set_rate(scm->core_clk, INT_MAX);
+   if (ret)
+   return ret;
+
+   __scm = scm;
+   __scm->dev = >dev;
+
+   return 0;
+}
+
+static const struct of_device_id qcom_scm_dt_match[] = {
+   { .compatible = "qcom,scm-apq8064",},
+   { .compatible = "qcom,scm-msm8660",},
+   { .compatible = "qcom,scm-msm8960",},
+   { .compatible = "qcom,scm",},
+   {}
+};
+
+MODULE_DEVICE_TABLE(of, qcom_scm_dt_match);
+
+static struct platform_driver qcom_scm_driver = {
+   .driver = {
+   .name   = "qcom_scm",
+   .of_match_table = qcom_scm_dt_match,
+   },
+   .probe = qcom_scm_probe,
+};
+
+static int __init qcom_scm_init(void)
+{
+   struct device_node 

[Patch v5 2/8] firmware: qcom: scm: Convert SCM to platform driver

[Andy Gross]

This patch converts the Qualcomm SCM firmware driver into a platform
driver.

Signed-off-by: Andy Gross 
---
 drivers/firmware/qcom_scm.c | 165 +---
 1 file changed, 156 insertions(+), 9 deletions(-)

diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
index 45c008d..4d6ae32 100644
--- a/drivers/firmware/qcom_scm.c
+++ b/drivers/firmware/qcom_scm.c
@@ -10,19 +10,61 @@
  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  * GNU General Public License for more details.
  *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
- * 02110-1301, USA.
  */
-
+#include 
+#include 
 #include 
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 
 #include "qcom_scm.h"
 
+struct qcom_scm {
+   struct device *dev;
+   struct clk *core_clk;
+   struct clk *iface_clk;
+   struct clk *bus_clk;
+};
+
+static struct qcom_scm *__scm;
+
+static int qcom_scm_clk_enable(void)
+{
+   int ret;
+
+   ret = clk_prepare_enable(__scm->core_clk);
+   if (ret)
+   goto bail;
+
+   ret = clk_prepare_enable(__scm->iface_clk);
+   if (ret)
+   goto disable_core;
+
+   ret = clk_prepare_enable(__scm->bus_clk);
+   if (ret)
+   goto disable_iface;
+
+   return 0;
+
+disable_iface:
+   clk_disable_unprepare(__scm->iface_clk);
+disable_core:
+   clk_disable_unprepare(__scm->core_clk);
+bail:
+   return ret;
+}
+
+static void qcom_scm_clk_disable(void)
+{
+   clk_disable_unprepare(__scm->core_clk);
+   clk_disable_unprepare(__scm->iface_clk);
+   clk_disable_unprepare(__scm->bus_clk);
+}
+
 /**
  * qcom_scm_set_cold_boot_addr() - Set the cold boot address for cpus
  * @entry: Entry point function for the cpus
@@ -72,12 +114,17 @@ EXPORT_SYMBOL(qcom_scm_cpu_power_down);
  */
 bool qcom_scm_hdcp_available(void)
 {
-   int ret;
+   int ret = qcom_scm_clk_enable();
+
+   if (ret)
+   return ret;
 
ret = __qcom_scm_is_call_available(QCOM_SCM_SVC_HDCP,
-   QCOM_SCM_CMD_HDCP);
+   QCOM_SCM_CMD_HDCP);
+
+   qcom_scm_clk_disable();
 
-   return (ret > 0) ? true : false;
+   return ret > 0 ? true : false;
 }
 EXPORT_SYMBOL(qcom_scm_hdcp_available);
 
@@ -91,6 +138,106 @@ EXPORT_SYMBOL(qcom_scm_hdcp_available);
  */
 int qcom_scm_hdcp_req(struct qcom_scm_hdcp_req *req, u32 req_cnt, u32 *resp)
 {
-   return __qcom_scm_hdcp_req(req, req_cnt, resp);
+   int ret = qcom_scm_clk_enable();
+
+   if (ret)
+   return ret;
+
+   ret = __qcom_scm_hdcp_req(req, req_cnt, resp);
+   qcom_scm_clk_disable();
+   return ret;
 }
 EXPORT_SYMBOL(qcom_scm_hdcp_req);
+
+static int qcom_scm_probe(struct platform_device *pdev)
+{
+   struct qcom_scm *scm;
+   int ret;
+
+   scm = devm_kzalloc(>dev, sizeof(*scm), GFP_KERNEL);
+   if (!scm)
+   return -ENOMEM;
+
+   scm->core_clk = devm_clk_get(>dev, "core");
+   if (IS_ERR(scm->core_clk)) {
+   if (PTR_ERR(scm->core_clk) != -EPROBE_DEFER)
+   dev_err(>dev, "failed to acquire core clk\n");
+   return PTR_ERR(scm->core_clk);
+   }
+
+   if (of_device_is_compatible(pdev->dev.of_node, "qcom,scm")) {
+   scm->iface_clk = devm_clk_get(>dev, "iface");
+   if (IS_ERR(scm->iface_clk)) {
+   if (PTR_ERR(scm->iface_clk) != -EPROBE_DEFER)
+   dev_err(>dev, "failed to acquire iface 
clk\n");
+   return PTR_ERR(scm->iface_clk);
+   }
+
+   scm->bus_clk = devm_clk_get(>dev, "bus");
+   if (IS_ERR(scm->bus_clk)) {
+   if (PTR_ERR(scm->bus_clk) != -EPROBE_DEFER)
+   dev_err(>dev, "failed to acquire bus 
clk\n");
+   return PTR_ERR(scm->bus_clk);
+   }
+   }
+
+   /* vote for max clk rate for highest performance */
+   ret = clk_set_rate(scm->core_clk, INT_MAX);
+   if (ret)
+   return ret;
+
+   __scm = scm;
+   __scm->dev = >dev;
+
+   return 0;
+}
+
+static const struct of_device_id qcom_scm_dt_match[] = {
+   { .compatible = "qcom,scm-apq8064",},
+   { .compatible = "qcom,scm-msm8660",},
+   { .compatible = "qcom,scm-msm8960",},
+   { .compatible = "qcom,scm",},
+   {}
+};
+
+MODULE_DEVICE_TABLE(of, qcom_scm_dt_match);
+
+static struct platform_driver qcom_scm_driver = {
+   .driver = {
+   .name   = "qcom_scm",
+   .of_match_table = qcom_scm_dt_match,
+   },
+   .probe = qcom_scm_probe,
+};
+
+static int __init qcom_scm_init(void)
+{
+   struct device_node *np, *parent;
+   int 

[Patch v5 6/8] firmware: qcom: scm: Add support for ARM64 SoCs

[Andy Gross]

From: Kumar Gala 

Add an implementation of the SCM interface that works on ARM64 SoCs.  This
is used by things like determine if we have HDCP support or not on the
system.

Signed-off-by: Kumar Gala 
Signed-off-by: Andy Gross 
---
 drivers/firmware/qcom_scm-32.c |   4 +
 drivers/firmware/qcom_scm-64.c | 199 +++--
 drivers/firmware/qcom_scm.c|   2 +
 drivers/firmware/qcom_scm.h|   5 ++
 4 files changed, 205 insertions(+), 5 deletions(-)

diff --git a/drivers/firmware/qcom_scm-32.c b/drivers/firmware/qcom_scm-32.c
index e92bf7a..4971b55 100644
--- a/drivers/firmware/qcom_scm-32.c
+++ b/drivers/firmware/qcom_scm-32.c
@@ -420,3 +420,7 @@ int __qcom_scm_hdcp_req(struct device *dev, struct 
qcom_scm_hdcp_req *req,
return qcom_scm_call(dev, QCOM_SCM_SVC_HDCP, QCOM_SCM_CMD_HDCP,
req, req_cnt * sizeof(*req), resp, sizeof(*resp));
 }
+
+void __qcom_scm_init(void)
+{
+}
diff --git a/drivers/firmware/qcom_scm-64.c b/drivers/firmware/qcom_scm-64.c
index bb6555f..43ed4de 100644
--- a/drivers/firmware/qcom_scm-64.c
+++ b/drivers/firmware/qcom_scm-64.c
@@ -12,7 +12,143 @@
 
 #include 
 #include 
+#include 
+#include 
+#include 
+#include 
 #include 
+#include 
+#include 
+
+#include "qcom_scm.h"
+
+#define QCOM_SCM_FNID(s, c) s) & 0xFF) << 8) | ((c) & 0xFF))
+
+#define MAX_QCOM_SCM_ARGS 10
+#define MAX_QCOM_SCM_RETS 3
+
+#define QCOM_SCM_ARGS_IMPL(num, a, b, c, d, e, f, g, h, i, j, ...) (\
+  (((a) & 0x3) << 4) | \
+  (((b) & 0x3) << 6) | \
+  (((c) & 0x3) << 8) | \
+  (((d) & 0x3) << 10) | \
+  (((e) & 0x3) << 12) | \
+  (((f) & 0x3) << 14) | \
+  (((g) & 0x3) << 16) | \
+  (((h) & 0x3) << 18) | \
+  (((i) & 0x3) << 20) | \
+  (((j) & 0x3) << 22) | \
+  (num & 0xf))
+
+#define QCOM_SCM_ARGS(...) QCOM_SCM_ARGS_IMPL(__VA_ARGS__, 0, 0, 0, 0, 0, 0, 
0, 0, 0, 0)
+
+/**
+ * struct qcom_scm_desc
+ * @arginfo:   Metadata describing the arguments in args[]
+ * @args:  The array of arguments for the secure syscall
+ * @res:   The values returned by the secure syscall
+ */
+struct qcom_scm_desc {
+   u32 arginfo;
+   u64 args[MAX_QCOM_SCM_ARGS];
+   struct arm_smccc_res res;
+};
+
+static u64 qcom_smccc_convention = -1;
+static DEFINE_MUTEX(qcom_scm_lock);
+
+#define QCOM_SCM_EBUSY_WAIT_MS 30
+#define QCOM_SCM_EBUSY_MAX_RETRY 20
+
+#define N_EXT_QCOM_SCM_ARGS 7
+#define FIRST_EXT_ARG_IDX 3
+#define N_REGISTER_ARGS (MAX_QCOM_SCM_ARGS - N_EXT_QCOM_SCM_ARGS + 1)
+
+/**
+ * qcom_scm_call() - Invoke a syscall in the secure world
+ * @dev:   device
+ * @svc_id:service identifier
+ * @cmd_id:command identifier
+ * @desc:  Descriptor structure containing arguments and return values
+ *
+ * Sends a command to the SCM and waits for the command to finish processing.
+ * This should *only* be called in pre-emptible context.
+*/
+static int qcom_scm_call(struct device *dev, u32 svc_id, u32 cmd_id,
+struct qcom_scm_desc *desc)
+{
+   int arglen = desc->arginfo & 0xf;
+   int retry_count = 0, i;
+   u32 fn_id = QCOM_SCM_FNID(svc_id, cmd_id);
+   u64 cmd, x5 = desc->args[FIRST_EXT_ARG_IDX];
+   dma_addr_t args_phys = 0;
+   void *args_virt = NULL;
+   size_t alloc_len;
+
+   if (unlikely(arglen > N_REGISTER_ARGS)) {
+   alloc_len = N_EXT_QCOM_SCM_ARGS * sizeof(u64);
+   args_virt = kzalloc(PAGE_ALIGN(alloc_len), GFP_KERNEL);
+
+   if (!args_virt)
+   return qcom_scm_remap_error(-ENOMEM);
+
+   if (qcom_smccc_convention == ARM_SMCCC_SMC_32) {
+   __le32 *args = args_virt;
+
+   for (i = 0; i < N_EXT_QCOM_SCM_ARGS; i++)
+   args[i] = cpu_to_le32(desc->args[i +
+ FIRST_EXT_ARG_IDX]);
+   } else {
+   __le64 *args = args_virt;
+
+   for (i = 0; i < N_EXT_QCOM_SCM_ARGS; i++)
+   args[i] = cpu_to_le64(desc->args[i +
+ FIRST_EXT_ARG_IDX]);
+   }
+
+   args_phys = dma_map_single(dev, args_virt, alloc_len,
+  DMA_TO_DEVICE);
+
+   if (dma_mapping_error(dev, args_phys)) {
+   kfree(args_virt);
+   return qcom_scm_remap_error(-ENOMEM);
+   }
+
+   x5 = args_phys;
+   }
+
+   do {
+   mutex_lock(_scm_lock);
+
+   cmd = ARM_SMCCC_CALL_VAL(ARM_SMCCC_STD_CALL,
+

[Patch v5 6/8] firmware: qcom: scm: Add support for ARM64 SoCs

[Andy Gross]

From: Kumar Gala 

Add an implementation of the SCM interface that works on ARM64 SoCs.  This
is used by things like determine if we have HDCP support or not on the
system.

Signed-off-by: Kumar Gala 
Signed-off-by: Andy Gross 
---
 drivers/firmware/qcom_scm-32.c |   4 +
 drivers/firmware/qcom_scm-64.c | 199 +++--
 drivers/firmware/qcom_scm.c|   2 +
 drivers/firmware/qcom_scm.h|   5 ++
 4 files changed, 205 insertions(+), 5 deletions(-)

diff --git a/drivers/firmware/qcom_scm-32.c b/drivers/firmware/qcom_scm-32.c
index e92bf7a..4971b55 100644
--- a/drivers/firmware/qcom_scm-32.c
+++ b/drivers/firmware/qcom_scm-32.c
@@ -420,3 +420,7 @@ int __qcom_scm_hdcp_req(struct device *dev, struct 
qcom_scm_hdcp_req *req,
return qcom_scm_call(dev, QCOM_SCM_SVC_HDCP, QCOM_SCM_CMD_HDCP,
req, req_cnt * sizeof(*req), resp, sizeof(*resp));
 }
+
+void __qcom_scm_init(void)
+{
+}
diff --git a/drivers/firmware/qcom_scm-64.c b/drivers/firmware/qcom_scm-64.c
index bb6555f..43ed4de 100644
--- a/drivers/firmware/qcom_scm-64.c
+++ b/drivers/firmware/qcom_scm-64.c
@@ -12,7 +12,143 @@
 
 #include 
 #include 
+#include 
+#include 
+#include 
+#include 
 #include 
+#include 
+#include 
+
+#include "qcom_scm.h"
+
+#define QCOM_SCM_FNID(s, c) s) & 0xFF) << 8) | ((c) & 0xFF))
+
+#define MAX_QCOM_SCM_ARGS 10
+#define MAX_QCOM_SCM_RETS 3
+
+#define QCOM_SCM_ARGS_IMPL(num, a, b, c, d, e, f, g, h, i, j, ...) (\
+  (((a) & 0x3) << 4) | \
+  (((b) & 0x3) << 6) | \
+  (((c) & 0x3) << 8) | \
+  (((d) & 0x3) << 10) | \
+  (((e) & 0x3) << 12) | \
+  (((f) & 0x3) << 14) | \
+  (((g) & 0x3) << 16) | \
+  (((h) & 0x3) << 18) | \
+  (((i) & 0x3) << 20) | \
+  (((j) & 0x3) << 22) | \
+  (num & 0xf))
+
+#define QCOM_SCM_ARGS(...) QCOM_SCM_ARGS_IMPL(__VA_ARGS__, 0, 0, 0, 0, 0, 0, 
0, 0, 0, 0)
+
+/**
+ * struct qcom_scm_desc
+ * @arginfo:   Metadata describing the arguments in args[]
+ * @args:  The array of arguments for the secure syscall
+ * @res:   The values returned by the secure syscall
+ */
+struct qcom_scm_desc {
+   u32 arginfo;
+   u64 args[MAX_QCOM_SCM_ARGS];
+   struct arm_smccc_res res;
+};
+
+static u64 qcom_smccc_convention = -1;
+static DEFINE_MUTEX(qcom_scm_lock);
+
+#define QCOM_SCM_EBUSY_WAIT_MS 30
+#define QCOM_SCM_EBUSY_MAX_RETRY 20
+
+#define N_EXT_QCOM_SCM_ARGS 7
+#define FIRST_EXT_ARG_IDX 3
+#define N_REGISTER_ARGS (MAX_QCOM_SCM_ARGS - N_EXT_QCOM_SCM_ARGS + 1)
+
+/**
+ * qcom_scm_call() - Invoke a syscall in the secure world
+ * @dev:   device
+ * @svc_id:service identifier
+ * @cmd_id:command identifier
+ * @desc:  Descriptor structure containing arguments and return values
+ *
+ * Sends a command to the SCM and waits for the command to finish processing.
+ * This should *only* be called in pre-emptible context.
+*/
+static int qcom_scm_call(struct device *dev, u32 svc_id, u32 cmd_id,
+struct qcom_scm_desc *desc)
+{
+   int arglen = desc->arginfo & 0xf;
+   int retry_count = 0, i;
+   u32 fn_id = QCOM_SCM_FNID(svc_id, cmd_id);
+   u64 cmd, x5 = desc->args[FIRST_EXT_ARG_IDX];
+   dma_addr_t args_phys = 0;
+   void *args_virt = NULL;
+   size_t alloc_len;
+
+   if (unlikely(arglen > N_REGISTER_ARGS)) {
+   alloc_len = N_EXT_QCOM_SCM_ARGS * sizeof(u64);
+   args_virt = kzalloc(PAGE_ALIGN(alloc_len), GFP_KERNEL);
+
+   if (!args_virt)
+   return qcom_scm_remap_error(-ENOMEM);
+
+   if (qcom_smccc_convention == ARM_SMCCC_SMC_32) {
+   __le32 *args = args_virt;
+
+   for (i = 0; i < N_EXT_QCOM_SCM_ARGS; i++)
+   args[i] = cpu_to_le32(desc->args[i +
+ FIRST_EXT_ARG_IDX]);
+   } else {
+   __le64 *args = args_virt;
+
+   for (i = 0; i < N_EXT_QCOM_SCM_ARGS; i++)
+   args[i] = cpu_to_le64(desc->args[i +
+ FIRST_EXT_ARG_IDX]);
+   }
+
+   args_phys = dma_map_single(dev, args_virt, alloc_len,
+  DMA_TO_DEVICE);
+
+   if (dma_mapping_error(dev, args_phys)) {
+   kfree(args_virt);
+   return qcom_scm_remap_error(-ENOMEM);
+   }
+
+   x5 = args_phys;
+   }
+
+   do {
+   mutex_lock(_scm_lock);
+
+   cmd = ARM_SMCCC_CALL_VAL(ARM_SMCCC_STD_CALL,
+qcom_smccc_convention,
+   

[Patch v5 4/8] firmware: qcom: scm: Generalize shared error map

[Andy Gross]

This patch moves the qcom_scm_remap_error function to the include file
where can be used by both the 32 and 64 bit versions of the code.

Reviewed-by: Stephen Boyd 
Acked-by: Bjorn Andersson 
Signed-off-by: Andy Gross 
Signed-off-by: Andy Gross 
---
 drivers/firmware/qcom_scm-32.c | 17 -
 drivers/firmware/qcom_scm.h| 16 
 2 files changed, 16 insertions(+), 17 deletions(-)

diff --git a/drivers/firmware/qcom_scm-32.c b/drivers/firmware/qcom_scm-32.c
index 5be6a12..4388d13 100644
--- a/drivers/firmware/qcom_scm-32.c
+++ b/drivers/firmware/qcom_scm-32.c
@@ -168,23 +168,6 @@ static inline void *qcom_scm_get_response_buffer(const 
struct qcom_scm_response
return (void *)rsp + le32_to_cpu(rsp->buf_offset);
 }
 
-static int qcom_scm_remap_error(int err)
-{
-   pr_err("qcom_scm_call failed with error code %d\n", err);
-   switch (err) {
-   case QCOM_SCM_ERROR:
-   return -EIO;
-   case QCOM_SCM_EINVAL_ADDR:
-   case QCOM_SCM_EINVAL_ARG:
-   return -EINVAL;
-   case QCOM_SCM_EOPNOTSUPP:
-   return -EOPNOTSUPP;
-   case QCOM_SCM_ENOMEM:
-   return -ENOMEM;
-   }
-   return -EINVAL;
-}
-
 static u32 smc(u32 cmd_addr)
 {
int context_id;
diff --git a/drivers/firmware/qcom_scm.h b/drivers/firmware/qcom_scm.h
index 2cce75c..7dcc733 100644
--- a/drivers/firmware/qcom_scm.h
+++ b/drivers/firmware/qcom_scm.h
@@ -44,4 +44,20 @@ extern int __qcom_scm_hdcp_req(struct qcom_scm_hdcp_req 
*req, u32 req_cnt,
 #define QCOM_SCM_ERROR -1
 #define QCOM_SCM_INTERRUPTED   1
 
+static inline int qcom_scm_remap_error(int err)
+{
+   switch (err) {
+   case QCOM_SCM_ERROR:
+   return -EIO;
+   case QCOM_SCM_EINVAL_ADDR:
+   case QCOM_SCM_EINVAL_ARG:
+   return -EINVAL;
+   case QCOM_SCM_EOPNOTSUPP:
+   return -EOPNOTSUPP;
+   case QCOM_SCM_ENOMEM:
+   return -ENOMEM;
+   }
+   return -EINVAL;
+}
+
 #endif
-- 
1.9.1

[Patch v5 4/8] firmware: qcom: scm: Generalize shared error map

[Andy Gross]

This patch moves the qcom_scm_remap_error function to the include file
where can be used by both the 32 and 64 bit versions of the code.

Reviewed-by: Stephen Boyd 
Acked-by: Bjorn Andersson 
Signed-off-by: Andy Gross 
Signed-off-by: Andy Gross 
---
 drivers/firmware/qcom_scm-32.c | 17 -
 drivers/firmware/qcom_scm.h| 16 
 2 files changed, 16 insertions(+), 17 deletions(-)

diff --git a/drivers/firmware/qcom_scm-32.c b/drivers/firmware/qcom_scm-32.c
index 5be6a12..4388d13 100644
--- a/drivers/firmware/qcom_scm-32.c
+++ b/drivers/firmware/qcom_scm-32.c
@@ -168,23 +168,6 @@ static inline void *qcom_scm_get_response_buffer(const 
struct qcom_scm_response
return (void *)rsp + le32_to_cpu(rsp->buf_offset);
 }
 
-static int qcom_scm_remap_error(int err)
-{
-   pr_err("qcom_scm_call failed with error code %d\n", err);
-   switch (err) {
-   case QCOM_SCM_ERROR:
-   return -EIO;
-   case QCOM_SCM_EINVAL_ADDR:
-   case QCOM_SCM_EINVAL_ARG:
-   return -EINVAL;
-   case QCOM_SCM_EOPNOTSUPP:
-   return -EOPNOTSUPP;
-   case QCOM_SCM_ENOMEM:
-   return -ENOMEM;
-   }
-   return -EINVAL;
-}
-
 static u32 smc(u32 cmd_addr)
 {
int context_id;
diff --git a/drivers/firmware/qcom_scm.h b/drivers/firmware/qcom_scm.h
index 2cce75c..7dcc733 100644
--- a/drivers/firmware/qcom_scm.h
+++ b/drivers/firmware/qcom_scm.h
@@ -44,4 +44,20 @@ extern int __qcom_scm_hdcp_req(struct qcom_scm_hdcp_req 
*req, u32 req_cnt,
 #define QCOM_SCM_ERROR -1
 #define QCOM_SCM_INTERRUPTED   1
 
+static inline int qcom_scm_remap_error(int err)
+{
+   switch (err) {
+   case QCOM_SCM_ERROR:
+   return -EIO;
+   case QCOM_SCM_EINVAL_ADDR:
+   case QCOM_SCM_EINVAL_ARG:
+   return -EINVAL;
+   case QCOM_SCM_EOPNOTSUPP:
+   return -EOPNOTSUPP;
+   case QCOM_SCM_ENOMEM:
+   return -ENOMEM;
+   }
+   return -EINVAL;
+}
+
 #endif
-- 
1.9.1

[Patch v5 7/8] dts: qcom: apq8084: Add SCM firmware node

[Andy Gross]

This patch adds the firmware node for the SCM

Acked-by: Bjorn Andersson 
Signed-off-by: Andy Gross 
---
 arch/arm/boot/dts/qcom-apq8084.dtsi | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-apq8084.dtsi 
b/arch/arm/boot/dts/qcom-apq8084.dtsi
index a33a09f..7c2df06 100644
--- a/arch/arm/boot/dts/qcom-apq8084.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8084.dtsi
@@ -86,6 +86,14 @@
};
};
 
+   firmware {
+   scm {
+   compatible = "qcom,scm";
+   clocks = < GCC_CE1_CLK> , < GCC_CE1_AXI_CLK>, 
< GCC_CE1_AHB_CLK>;
+   clock-names = "core", "bus", "iface";
+   };
+   };
+
cpu-pmu {
compatible = "qcom,krait-pmu";
interrupts = <1 7 0xf04>;
-- 
1.9.1

[Patch v5 8/8] arm64: dts: msm8916: Add SCM firmware node

[Andy Gross]

This adds the devicetree node for the SCM firmware.

Acked-by: Bjorn Andersson 
Signed-off-by: Andy Gross 
---
 arch/arm64/boot/dts/qcom/msm8916.dtsi | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi 
b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index 9681200..01c7b0c 100644
--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -122,6 +122,14 @@
hwlocks = <_mutex 3>;
};
 
+   firmware {
+   scm {
+   compatible = "qcom,scm";
+   clocks = < GCC_CRYPTO_CLK>, < 
GCC_CRYPTO_AXI_CLK>, < GCC_CRYPTO_AHB_CLK>;
+   clock-names = "core", "bus", "iface";
+   };
+   };
+
soc: soc {
#address-cells = <1>;
#size-cells = <1>;
-- 
1.9.1

[Patch v5 5/8] firmware: qcom: scm: Convert to streaming DMA APIS

[Andy Gross]

This patch converts the Qualcomm SCM driver to use the streaming DMA APIs
for communication buffers.

Signed-off-by: Andy Gross 
---
 drivers/firmware/qcom_scm-32.c | 189 +++--
 drivers/firmware/qcom_scm.c|   6 +-
 drivers/firmware/qcom_scm.h|  10 ++-
 3 files changed, 59 insertions(+), 146 deletions(-)

diff --git a/drivers/firmware/qcom_scm-32.c b/drivers/firmware/qcom_scm-32.c
index 4388d13..e92bf7a 100644
--- a/drivers/firmware/qcom_scm-32.c
+++ b/drivers/firmware/qcom_scm-32.c
@@ -23,8 +23,7 @@
 #include 
 #include 
 #include 
-
-#include 
+#include 
 
 #include "qcom_scm.h"
 
@@ -64,11 +63,11 @@ static DEFINE_MUTEX(qcom_scm_lock);
  *
  * --- <--- struct qcom_scm_command
  * | command header  |
- * --- <--- qcom_scm_get_command_buffer()
+ * --- <--- buf[0]
  * | command buffer  |
- * --- <--- struct qcom_scm_response and
- * | response header |  qcom_scm_command_to_response()
- * --- <--- qcom_scm_get_response_buffer()
+ * --- <--- struct qcom_scm_response
+ * | response header |
+ * ---
  * | response buffer |
  * ---
  *
@@ -96,79 +95,7 @@ struct qcom_scm_response {
__le32 is_complete;
 };
 
-/**
- * alloc_qcom_scm_command() - Allocate an SCM command
- * @cmd_size: size of the command buffer
- * @resp_size: size of the response buffer
- *
- * Allocate an SCM command, including enough room for the command
- * and response headers as well as the command and response buffers.
- *
- * Returns a valid _scm_command on success or %NULL if the allocation 
fails.
- */
-static struct qcom_scm_command *alloc_qcom_scm_command(size_t cmd_size, size_t 
resp_size)
-{
-   struct qcom_scm_command *cmd;
-   size_t len = sizeof(*cmd) + sizeof(struct qcom_scm_response) + cmd_size 
+
-   resp_size;
-   u32 offset;
-
-   cmd = kzalloc(PAGE_ALIGN(len), GFP_KERNEL);
-   if (cmd) {
-   cmd->len = cpu_to_le32(len);
-   offset = offsetof(struct qcom_scm_command, buf);
-   cmd->buf_offset = cpu_to_le32(offset);
-   cmd->resp_hdr_offset = cpu_to_le32(offset + cmd_size);
-   }
-   return cmd;
-}
-
-/**
- * free_qcom_scm_command() - Free an SCM command
- * @cmd: command to free
- *
- * Free an SCM command.
- */
-static inline void free_qcom_scm_command(struct qcom_scm_command *cmd)
-{
-   kfree(cmd);
-}
-
-/**
- * qcom_scm_command_to_response() - Get a pointer to a qcom_scm_response
- * @cmd: command
- *
- * Returns a pointer to a response for a command.
- */
-static inline struct qcom_scm_response *qcom_scm_command_to_response(
-   const struct qcom_scm_command *cmd)
-{
-   return (void *)cmd + le32_to_cpu(cmd->resp_hdr_offset);
-}
-
-/**
- * qcom_scm_get_command_buffer() - Get a pointer to a command buffer
- * @cmd: command
- *
- * Returns a pointer to the command buffer of a command.
- */
-static inline void *qcom_scm_get_command_buffer(const struct qcom_scm_command 
*cmd)
-{
-   return (void *)cmd->buf;
-}
-
-/**
- * qcom_scm_get_response_buffer() - Get a pointer to a response buffer
- * @rsp: response
- *
- * Returns a pointer to a response buffer of a response.
- */
-static inline void *qcom_scm_get_response_buffer(const struct 
qcom_scm_response *rsp)
-{
-   return (void *)rsp + le32_to_cpu(rsp->buf_offset);
-}
-
-static u32 smc(u32 cmd_addr)
+static u32 smc(dma_addr_t cmd_addr)
 {
int context_id;
register u32 r0 asm("r0") = 1;
@@ -192,45 +119,9 @@ static u32 smc(u32 cmd_addr)
return r0;
 }
 
-static int __qcom_scm_call(const struct qcom_scm_command *cmd)
-{
-   int ret;
-   u32 cmd_addr = virt_to_phys(cmd);
-
-   /*
-* Flush the command buffer so that the secure world sees
-* the correct data.
-*/
-   secure_flush_area(cmd, cmd->len);
-
-   ret = smc(cmd_addr);
-   if (ret < 0)
-   ret = qcom_scm_remap_error(ret);
-
-   return ret;
-}
-
-static void qcom_scm_inv_range(unsigned long start, unsigned long end)
-{
-   u32 cacheline_size, ctr;
-
-   asm volatile("mrc p15, 0, %0, c0, c0, 1" : "=r" (ctr));
-   cacheline_size = 4 << ((ctr >> 16) & 0xf);
-
-   start = round_down(start, cacheline_size);
-   end = round_up(end, cacheline_size);
-   outer_inv_range(start, end);
-   while (start < end) {
-   asm ("mcr p15, 0, %0, c7, c6, 1" : : "r" (start)
-: "memory");
-   start += cacheline_size;
-   }
-   dsb();
-   isb();
-}
-
 /**
  * qcom_scm_call() - Send an SCM command
+ * @dev: struct device
  * @svc_id: service identifier
  * @cmd_id: command identifier
  * @cmd_buf: command buffer
@@ -247,42 +138,59 @@ static void qcom_scm_inv_range(unsigned long start, 
unsigned long end)
  * and 

[Patch v5 7/8] dts: qcom: apq8084: Add SCM firmware node

[Andy Gross]

This patch adds the firmware node for the SCM

Acked-by: Bjorn Andersson 
Signed-off-by: Andy Gross 
---
 arch/arm/boot/dts/qcom-apq8084.dtsi | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-apq8084.dtsi 
b/arch/arm/boot/dts/qcom-apq8084.dtsi
index a33a09f..7c2df06 100644
--- a/arch/arm/boot/dts/qcom-apq8084.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8084.dtsi
@@ -86,6 +86,14 @@
};
};
 
+   firmware {
+   scm {
+   compatible = "qcom,scm";
+   clocks = < GCC_CE1_CLK> , < GCC_CE1_AXI_CLK>, 
< GCC_CE1_AHB_CLK>;
+   clock-names = "core", "bus", "iface";
+   };
+   };
+
cpu-pmu {
compatible = "qcom,krait-pmu";
interrupts = <1 7 0xf04>;
-- 
1.9.1

[Patch v5 8/8] arm64: dts: msm8916: Add SCM firmware node

[Andy Gross]

This adds the devicetree node for the SCM firmware.

Acked-by: Bjorn Andersson 
Signed-off-by: Andy Gross 
---
 arch/arm64/boot/dts/qcom/msm8916.dtsi | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi 
b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index 9681200..01c7b0c 100644
--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -122,6 +122,14 @@
hwlocks = <_mutex 3>;
};
 
+   firmware {
+   scm {
+   compatible = "qcom,scm";
+   clocks = < GCC_CRYPTO_CLK>, < 
GCC_CRYPTO_AXI_CLK>, < GCC_CRYPTO_AHB_CLK>;
+   clock-names = "core", "bus", "iface";
+   };
+   };
+
soc: soc {
#address-cells = <1>;
#size-cells = <1>;
-- 
1.9.1

[Patch v5 5/8] firmware: qcom: scm: Convert to streaming DMA APIS

[Andy Gross]

This patch converts the Qualcomm SCM driver to use the streaming DMA APIs
for communication buffers.

Signed-off-by: Andy Gross 
---
 drivers/firmware/qcom_scm-32.c | 189 +++--
 drivers/firmware/qcom_scm.c|   6 +-
 drivers/firmware/qcom_scm.h|  10 ++-
 3 files changed, 59 insertions(+), 146 deletions(-)

diff --git a/drivers/firmware/qcom_scm-32.c b/drivers/firmware/qcom_scm-32.c
index 4388d13..e92bf7a 100644
--- a/drivers/firmware/qcom_scm-32.c
+++ b/drivers/firmware/qcom_scm-32.c
@@ -23,8 +23,7 @@
 #include 
 #include 
 #include 
-
-#include 
+#include 
 
 #include "qcom_scm.h"
 
@@ -64,11 +63,11 @@ static DEFINE_MUTEX(qcom_scm_lock);
  *
  * --- <--- struct qcom_scm_command
  * | command header  |
- * --- <--- qcom_scm_get_command_buffer()
+ * --- <--- buf[0]
  * | command buffer  |
- * --- <--- struct qcom_scm_response and
- * | response header |  qcom_scm_command_to_response()
- * --- <--- qcom_scm_get_response_buffer()
+ * --- <--- struct qcom_scm_response
+ * | response header |
+ * ---
  * | response buffer |
  * ---
  *
@@ -96,79 +95,7 @@ struct qcom_scm_response {
__le32 is_complete;
 };
 
-/**
- * alloc_qcom_scm_command() - Allocate an SCM command
- * @cmd_size: size of the command buffer
- * @resp_size: size of the response buffer
- *
- * Allocate an SCM command, including enough room for the command
- * and response headers as well as the command and response buffers.
- *
- * Returns a valid _scm_command on success or %NULL if the allocation 
fails.
- */
-static struct qcom_scm_command *alloc_qcom_scm_command(size_t cmd_size, size_t 
resp_size)
-{
-   struct qcom_scm_command *cmd;
-   size_t len = sizeof(*cmd) + sizeof(struct qcom_scm_response) + cmd_size 
+
-   resp_size;
-   u32 offset;
-
-   cmd = kzalloc(PAGE_ALIGN(len), GFP_KERNEL);
-   if (cmd) {
-   cmd->len = cpu_to_le32(len);
-   offset = offsetof(struct qcom_scm_command, buf);
-   cmd->buf_offset = cpu_to_le32(offset);
-   cmd->resp_hdr_offset = cpu_to_le32(offset + cmd_size);
-   }
-   return cmd;
-}
-
-/**
- * free_qcom_scm_command() - Free an SCM command
- * @cmd: command to free
- *
- * Free an SCM command.
- */
-static inline void free_qcom_scm_command(struct qcom_scm_command *cmd)
-{
-   kfree(cmd);
-}
-
-/**
- * qcom_scm_command_to_response() - Get a pointer to a qcom_scm_response
- * @cmd: command
- *
- * Returns a pointer to a response for a command.
- */
-static inline struct qcom_scm_response *qcom_scm_command_to_response(
-   const struct qcom_scm_command *cmd)
-{
-   return (void *)cmd + le32_to_cpu(cmd->resp_hdr_offset);
-}
-
-/**
- * qcom_scm_get_command_buffer() - Get a pointer to a command buffer
- * @cmd: command
- *
- * Returns a pointer to the command buffer of a command.
- */
-static inline void *qcom_scm_get_command_buffer(const struct qcom_scm_command 
*cmd)
-{
-   return (void *)cmd->buf;
-}
-
-/**
- * qcom_scm_get_response_buffer() - Get a pointer to a response buffer
- * @rsp: response
- *
- * Returns a pointer to a response buffer of a response.
- */
-static inline void *qcom_scm_get_response_buffer(const struct 
qcom_scm_response *rsp)
-{
-   return (void *)rsp + le32_to_cpu(rsp->buf_offset);
-}
-
-static u32 smc(u32 cmd_addr)
+static u32 smc(dma_addr_t cmd_addr)
 {
int context_id;
register u32 r0 asm("r0") = 1;
@@ -192,45 +119,9 @@ static u32 smc(u32 cmd_addr)
return r0;
 }
 
-static int __qcom_scm_call(const struct qcom_scm_command *cmd)
-{
-   int ret;
-   u32 cmd_addr = virt_to_phys(cmd);
-
-   /*
-* Flush the command buffer so that the secure world sees
-* the correct data.
-*/
-   secure_flush_area(cmd, cmd->len);
-
-   ret = smc(cmd_addr);
-   if (ret < 0)
-   ret = qcom_scm_remap_error(ret);
-
-   return ret;
-}
-
-static void qcom_scm_inv_range(unsigned long start, unsigned long end)
-{
-   u32 cacheline_size, ctr;
-
-   asm volatile("mrc p15, 0, %0, c0, c0, 1" : "=r" (ctr));
-   cacheline_size = 4 << ((ctr >> 16) & 0xf);
-
-   start = round_down(start, cacheline_size);
-   end = round_up(end, cacheline_size);
-   outer_inv_range(start, end);
-   while (start < end) {
-   asm ("mcr p15, 0, %0, c7, c6, 1" : : "r" (start)
-: "memory");
-   start += cacheline_size;
-   }
-   dsb();
-   isb();
-}
-
 /**
  * qcom_scm_call() - Send an SCM command
+ * @dev: struct device
  * @svc_id: service identifier
  * @cmd_id: command identifier
  * @cmd_buf: command buffer
@@ -247,42 +138,59 @@ static void qcom_scm_inv_range(unsigned long start, 
unsigned long end)
  * and response buffers is taken 

Re: next: fuloong2e qemu boot failure due to 'MIPS: Loongson: AddLoongson-3A R2 basic support'

[Guenter Roeck]

On 04/19/2016 10:41 PM, Huacai Chen wrote:

This is a kernel bug, I'll send a patch.



Did you ever send a patch to fix this problem ? It is still broken in 
next-20160512.

Guenter


Huacai

On Wed, Apr 20, 2016 at 12:43 PM, Guenter Roeck <li...@roeck-us.net> wrote:

On 04/19/2016 08:37 PM, 陈华才 wrote:


Hi,

Could you please remove the line "#define cpu_hwrena_impl_bits
0xc000" in arch/mips/include/asm/mach-loongson64/cpu-feature-overrides.h
and try again?Thanks.



That fixes the problem.

Does this need to be addressed in qemu or in the Linux kernel ?

Thanks,
Guenter



Huacai

-- Original --
From:  "Guenter Roeck"<li...@roeck-us.net>;
Date:  Wed, Apr 20, 2016 10:54 AM
To:  "Huacai Chen"<che...@lemote.com>;
Cc:  "Ralf Baechle"<r...@linux-mips.org>;
"linux-mips"<linux-m...@linux-mips.org>;
"linux-next"<linux-n...@vger.kernel.org>;
"linux-kernel"<linux-kernel@vger.kernel.org>;
Subject:  next: fuloong2e qemu boot failure due to 'MIPS: Loongson:
AddLoongson-3A R2 basic support'

Hi,

qemu fails to boot in -next for machine fulong2e with configuration
fuloong2e_defconfig. Bisect points to commit 'MIPS: Loongson: Add
Loongson-3A R2 basic support'. qemu hangs in boot, after displaying
"Inode-cache hash table entries: 16384 (order: 3, 131072 bytes)".

Bisect log is attached.

Guenter

---
# bad: [1bd7a2081d2c7b096f75aa934658e404ccaba5fd] Add linux-next specific
files for 20160418
# good: [bf16200689118d19de1b8d2a3c314fc21f5dc7bb] Linux 4.6-rc3
git bisect start 'HEAD' 'v4.6-rc3'
# bad: [493ac92ff65ec4c4cd4c43870e778760a012951d] Merge remote-tracking
branch 'ipvs-next/master'
git bisect bad 493ac92ff65ec4c4cd4c43870e778760a012951d
# bad: [20ca3ae9c517eee9b2f1bd0fb2a06e2d14153792] Merge remote-tracking
branch 'btrfs-kdave/for-next'
git bisect bad 20ca3ae9c517eee9b2f1bd0fb2a06e2d14153792
# good: [c454e65fb9ade11d0f84718d06a6888e2c92804d] Merge remote-tracking
branch 'omap/for-next'
git bisect good c454e65fb9ade11d0f84718d06a6888e2c92804d
# good: [6f5c70fb9b4fc0534157bfa40cea9b402e6f2506] Merge remote-tracking
branch 'microblaze/next'
git bisect good 6f5c70fb9b4fc0534157bfa40cea9b402e6f2506
# bad: [7f053cd68fd14243c8f202b4086d7dd75c409e6f] MIPS: Loongson-3:
Introduce CONFIG_LOONGSON3_ENHANCEMENT
git bisect bad 7f053cd68fd14243c8f202b4086d7dd75c409e6f
# good: [e9aacdd7f0b66c4ace17e5950c48e7cc61a253c8] MIPS: Allow RIXI to be
used on non-R2 or R6 cores
git bisect good e9aacdd7f0b66c4ace17e5950c48e7cc61a253c8
# good: [d1e8b9a8dc6c7fa9add5dfa7083e035ce037e56d] MAINTAINERS: add
Loongson1 architecture entry
git bisect good d1e8b9a8dc6c7fa9add5dfa7083e035ce037e56d
# good: [13ff6275bb389c3669082d3ef8483592a31eb0ea] MIPS: Fix siginfo.h to
use strict posix types
git bisect good 13ff6275bb389c3669082d3ef8483592a31eb0ea
# good: [66e74bdd51e617023fa2e79a807b704fb3eed8aa] MIPS: Enable ptrace hw
watchpoints on MIPS R6
git bisect good 66e74bdd51e617023fa2e79a807b704fb3eed8aa
# good: [f7cabc2dac8adf5986dbc700584bc3b8fe493d4d] MIPS: Loongson-3:
Adjust irq dispatch to speedup processing
git bisect good f7cabc2dac8adf5986dbc700584bc3b8fe493d4d
# bad: [4978c8477e96fb9e9d870d8f42328dcabf1a65e9] MIPS: Loongson-3: Set
cache flush handlers to cache_noop
git bisect bad 4978c8477e96fb9e9d870d8f42328dcabf1a65e9
# bad: [04a35922c1dac1b4864b8b366a37474e9e51d8c0] MIPS: Loongson: Add
Loongson-3A R2 basic support
git bisect bad 04a35922c1dac1b4864b8b366a37474e9e51d8c0
# first bad commit: [04a35922c1dac1b4864b8b366a37474e9e51d8c0] MIPS:
Loongson: Add Loongson-3A R2 basic support

[Patch v5 1/8] dt/bindings: firmware: Add Qualcomm SCM binding

[Andy Gross]

This patch adds the device tree support for the Qualcomm SCM firmware.

Signed-off-by: Andy Gross 
---
 .../devicetree/bindings/firmware/qcom,scm.txt  | 28 ++
 1 file changed, 28 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/firmware/qcom,scm.txt

diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.txt 
b/Documentation/devicetree/bindings/firmware/qcom,scm.txt
new file mode 100644
index 000..3b4436e
--- /dev/null
+++ b/Documentation/devicetree/bindings/firmware/qcom,scm.txt
@@ -0,0 +1,28 @@
+QCOM Secure Channel Manager (SCM)
+
+Qualcomm processors include an interface to communicate to the secure firmware.
+This interface allows for clients to request different types of actions.  These
+can include CPU power up/down, HDCP requests, loading of firmware, and other
+assorted actions.
+
+Required properties:
+- compatible: must contain one of the following:
+ * "qcom,scm-apq8064" for APQ8064 platforms
+ * "qcom,scm-msm8660" for MSM8660 platforms
+ * "qcom,scm-msm8690" for MSM8690 platforms
+ * "qcom,scm" for later processors (MSM8916, APQ8084, MSM8974, etc)
+- clocks: One to three clocks may be required based on compatible.
+ * Only core clock required for "qcom,scm-apq8064", "qcom,scm-msm8660", and 
"qcom,scm-msm8960"
+ * Core, iface, and bus clocks required for "qcom,scm"
+- clock-names: Must contain "core" for the core clock, "iface" for the 
interface
+  clock and "bus" for the bus clock per the requirements of the compatible.
+
+Example for MSM8916:
+
+   firmware {
+   scm {
+   compatible = "qcom,scm";
+   clocks = < GCC_CRYPTO_CLK> , < 
GCC_CRYPTO_AXI_CLK>, < GCC_CRYPTO_AHB_CLK>;
+   clock-names = "core", "bus", "iface";
+   };
+   };
-- 
1.9.1

[Patch v5 3/8] firmware: qcom: scm: Use atomic SCM for cold boot

[Andy Gross]

This patch changes the cold_set_boot_addr function to use atomic SCM
calls.  cold_set_boot_addr required adding qcom_scm_call_atomic2 to
support the two arguments going to the smc call.  Using atomic removes
the need for memory allocation and instead places all arguments in
registers.

Signed-off-by: Andy Gross 
---
 drivers/firmware/qcom_scm-32.c | 63 ++
 1 file changed, 45 insertions(+), 18 deletions(-)

diff --git a/drivers/firmware/qcom_scm-32.c b/drivers/firmware/qcom_scm-32.c
index 0883292..5be6a12 100644
--- a/drivers/firmware/qcom_scm-32.c
+++ b/drivers/firmware/qcom_scm-32.c
@@ -342,6 +342,41 @@ static s32 qcom_scm_call_atomic1(u32 svc, u32 cmd, u32 
arg1)
return r0;
 }
 
+/**
+ * qcom_scm_call_atomic2() - Send an atomic SCM command with two arguments
+ * @svc_id:service identifier
+ * @cmd_id:command identifier
+ * @arg1:  first argument
+ * @arg2:  second argument
+ *
+ * This shall only be used with commands that are guaranteed to be
+ * uninterruptable, atomic and SMP safe.
+ */
+static s32 qcom_scm_call_atomic2(u32 svc, u32 cmd, u32 arg1, u32 arg2)
+{
+   int context_id;
+
+   register u32 r0 asm("r0") = SCM_ATOMIC(svc, cmd, 2);
+   register u32 r1 asm("r1") = (u32)_id;
+   register u32 r2 asm("r2") = arg1;
+   register u32 r3 asm("r3") = arg2;
+
+   asm volatile(
+   __asmeq("%0", "r0")
+   __asmeq("%1", "r0")
+   __asmeq("%2", "r1")
+   __asmeq("%3", "r2")
+   __asmeq("%4", "r3")
+#ifdef REQUIRES_SEC
+   ".arch_extension sec\n"
+#endif
+   "smc#0  @ switch to secure world\n"
+   : "=r" (r0)
+   : "r" (r0), "r" (r1), "r" (r2), "r" (r3)
+   );
+   return r0;
+}
+
 u32 qcom_scm_get_version(void)
 {
int context_id;
@@ -378,22 +413,6 @@ u32 qcom_scm_get_version(void)
 }
 EXPORT_SYMBOL(qcom_scm_get_version);
 
-/*
- * Set the cold/warm boot address for one of the CPU cores.
- */
-static int qcom_scm_set_boot_addr(u32 addr, int flags)
-{
-   struct {
-   __le32 flags;
-   __le32 addr;
-   } cmd;
-
-   cmd.addr = cpu_to_le32(addr);
-   cmd.flags = cpu_to_le32(flags);
-   return qcom_scm_call(QCOM_SCM_SVC_BOOT, QCOM_SCM_BOOT_ADDR,
-   , sizeof(cmd), NULL, 0);
-}
-
 /**
  * qcom_scm_set_cold_boot_addr() - Set the cold boot address for cpus
  * @entry: Entry point function for the cpus
@@ -423,7 +442,8 @@ int __qcom_scm_set_cold_boot_addr(void *entry, const 
cpumask_t *cpus)
set_cpu_present(cpu, false);
}
 
-   return qcom_scm_set_boot_addr(virt_to_phys(entry), flags);
+   return qcom_scm_call_atomic2(QCOM_SCM_SVC_BOOT, QCOM_SCM_BOOT_ADDR,
+   flags, virt_to_phys(entry));
 }
 
 /**
@@ -439,6 +459,10 @@ int __qcom_scm_set_warm_boot_addr(void *entry, const 
cpumask_t *cpus)
int ret;
int flags = 0;
int cpu;
+   struct {
+   __le32 flags;
+   __le32 addr;
+   } cmd;
 
/*
 * Reassign only if we are switching from hotplug entry point
@@ -454,7 +478,10 @@ int __qcom_scm_set_warm_boot_addr(void *entry, const 
cpumask_t *cpus)
if (!flags)
return 0;
 
-   ret = qcom_scm_set_boot_addr(virt_to_phys(entry), flags);
+   cmd.addr = cpu_to_le32(virt_to_phys(entry));
+   cmd.flags = cpu_to_le32(flags);
+   ret = qcom_scm_call(QCOM_SCM_SVC_BOOT, QCOM_SCM_BOOT_ADDR,
+   , sizeof(cmd), NULL, 0);
if (!ret) {
for_each_cpu(cpu, cpus)
qcom_scm_wb[cpu].entry = entry;
-- 
1.9.1

Re: next: fuloong2e qemu boot failure due to 'MIPS: Loongson: AddLoongson-3A R2 basic support'

[Guenter Roeck]

On 04/19/2016 10:41 PM, Huacai Chen wrote:

This is a kernel bug, I'll send a patch.



Did you ever send a patch to fix this problem ? It is still broken in 
next-20160512.

Guenter


Huacai

On Wed, Apr 20, 2016 at 12:43 PM, Guenter Roeck  wrote:

On 04/19/2016 08:37 PM, 陈华才 wrote:


Hi,

Could you please remove the line "#define cpu_hwrena_impl_bits
0xc000" in arch/mips/include/asm/mach-loongson64/cpu-feature-overrides.h
and try again?Thanks.



That fixes the problem.

Does this need to be addressed in qemu or in the Linux kernel ?

Thanks,
Guenter



Huacai

-- Original --
From:  "Guenter Roeck";
Date:  Wed, Apr 20, 2016 10:54 AM
To:  "Huacai Chen";
Cc:  "Ralf Baechle";
"linux-mips";
"linux-next";
"linux-kernel";
Subject:  next: fuloong2e qemu boot failure due to 'MIPS: Loongson:
AddLoongson-3A R2 basic support'

Hi,

qemu fails to boot in -next for machine fulong2e with configuration
fuloong2e_defconfig. Bisect points to commit 'MIPS: Loongson: Add
Loongson-3A R2 basic support'. qemu hangs in boot, after displaying
"Inode-cache hash table entries: 16384 (order: 3, 131072 bytes)".

Bisect log is attached.

Guenter

---
# bad: [1bd7a2081d2c7b096f75aa934658e404ccaba5fd] Add linux-next specific
files for 20160418
# good: [bf16200689118d19de1b8d2a3c314fc21f5dc7bb] Linux 4.6-rc3
git bisect start 'HEAD' 'v4.6-rc3'
# bad: [493ac92ff65ec4c4cd4c43870e778760a012951d] Merge remote-tracking
branch 'ipvs-next/master'
git bisect bad 493ac92ff65ec4c4cd4c43870e778760a012951d
# bad: [20ca3ae9c517eee9b2f1bd0fb2a06e2d14153792] Merge remote-tracking
branch 'btrfs-kdave/for-next'
git bisect bad 20ca3ae9c517eee9b2f1bd0fb2a06e2d14153792
# good: [c454e65fb9ade11d0f84718d06a6888e2c92804d] Merge remote-tracking
branch 'omap/for-next'
git bisect good c454e65fb9ade11d0f84718d06a6888e2c92804d
# good: [6f5c70fb9b4fc0534157bfa40cea9b402e6f2506] Merge remote-tracking
branch 'microblaze/next'
git bisect good 6f5c70fb9b4fc0534157bfa40cea9b402e6f2506
# bad: [7f053cd68fd14243c8f202b4086d7dd75c409e6f] MIPS: Loongson-3:
Introduce CONFIG_LOONGSON3_ENHANCEMENT
git bisect bad 7f053cd68fd14243c8f202b4086d7dd75c409e6f
# good: [e9aacdd7f0b66c4ace17e5950c48e7cc61a253c8] MIPS: Allow RIXI to be
used on non-R2 or R6 cores
git bisect good e9aacdd7f0b66c4ace17e5950c48e7cc61a253c8
# good: [d1e8b9a8dc6c7fa9add5dfa7083e035ce037e56d] MAINTAINERS: add
Loongson1 architecture entry
git bisect good d1e8b9a8dc6c7fa9add5dfa7083e035ce037e56d
# good: [13ff6275bb389c3669082d3ef8483592a31eb0ea] MIPS: Fix siginfo.h to
use strict posix types
git bisect good 13ff6275bb389c3669082d3ef8483592a31eb0ea
# good: [66e74bdd51e617023fa2e79a807b704fb3eed8aa] MIPS: Enable ptrace hw
watchpoints on MIPS R6
git bisect good 66e74bdd51e617023fa2e79a807b704fb3eed8aa
# good: [f7cabc2dac8adf5986dbc700584bc3b8fe493d4d] MIPS: Loongson-3:
Adjust irq dispatch to speedup processing
git bisect good f7cabc2dac8adf5986dbc700584bc3b8fe493d4d
# bad: [4978c8477e96fb9e9d870d8f42328dcabf1a65e9] MIPS: Loongson-3: Set
cache flush handlers to cache_noop
git bisect bad 4978c8477e96fb9e9d870d8f42328dcabf1a65e9
# bad: [04a35922c1dac1b4864b8b366a37474e9e51d8c0] MIPS: Loongson: Add
Loongson-3A R2 basic support
git bisect bad 04a35922c1dac1b4864b8b366a37474e9e51d8c0
# first bad commit: [04a35922c1dac1b4864b8b366a37474e9e51d8c0] MIPS:
Loongson: Add Loongson-3A R2 basic support

[Patch v5 1/8] dt/bindings: firmware: Add Qualcomm SCM binding

[Andy Gross]

This patch adds the device tree support for the Qualcomm SCM firmware.

Signed-off-by: Andy Gross 
---
 .../devicetree/bindings/firmware/qcom,scm.txt  | 28 ++
 1 file changed, 28 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/firmware/qcom,scm.txt

diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.txt 
b/Documentation/devicetree/bindings/firmware/qcom,scm.txt
new file mode 100644
index 000..3b4436e
--- /dev/null
+++ b/Documentation/devicetree/bindings/firmware/qcom,scm.txt
@@ -0,0 +1,28 @@
+QCOM Secure Channel Manager (SCM)
+
+Qualcomm processors include an interface to communicate to the secure firmware.
+This interface allows for clients to request different types of actions.  These
+can include CPU power up/down, HDCP requests, loading of firmware, and other
+assorted actions.
+
+Required properties:
+- compatible: must contain one of the following:
+ * "qcom,scm-apq8064" for APQ8064 platforms
+ * "qcom,scm-msm8660" for MSM8660 platforms
+ * "qcom,scm-msm8690" for MSM8690 platforms
+ * "qcom,scm" for later processors (MSM8916, APQ8084, MSM8974, etc)
+- clocks: One to three clocks may be required based on compatible.
+ * Only core clock required for "qcom,scm-apq8064", "qcom,scm-msm8660", and 
"qcom,scm-msm8960"
+ * Core, iface, and bus clocks required for "qcom,scm"
+- clock-names: Must contain "core" for the core clock, "iface" for the 
interface
+  clock and "bus" for the bus clock per the requirements of the compatible.
+
+Example for MSM8916:
+
+   firmware {
+   scm {
+   compatible = "qcom,scm";
+   clocks = < GCC_CRYPTO_CLK> , < 
GCC_CRYPTO_AXI_CLK>, < GCC_CRYPTO_AHB_CLK>;
+   clock-names = "core", "bus", "iface";
+   };
+   };
-- 
1.9.1

[Patch v5 3/8] firmware: qcom: scm: Use atomic SCM for cold boot

[Andy Gross]

This patch changes the cold_set_boot_addr function to use atomic SCM
calls.  cold_set_boot_addr required adding qcom_scm_call_atomic2 to
support the two arguments going to the smc call.  Using atomic removes
the need for memory allocation and instead places all arguments in
registers.

Signed-off-by: Andy Gross 
---
 drivers/firmware/qcom_scm-32.c | 63 ++
 1 file changed, 45 insertions(+), 18 deletions(-)

diff --git a/drivers/firmware/qcom_scm-32.c b/drivers/firmware/qcom_scm-32.c
index 0883292..5be6a12 100644
--- a/drivers/firmware/qcom_scm-32.c
+++ b/drivers/firmware/qcom_scm-32.c
@@ -342,6 +342,41 @@ static s32 qcom_scm_call_atomic1(u32 svc, u32 cmd, u32 
arg1)
return r0;
 }
 
+/**
+ * qcom_scm_call_atomic2() - Send an atomic SCM command with two arguments
+ * @svc_id:service identifier
+ * @cmd_id:command identifier
+ * @arg1:  first argument
+ * @arg2:  second argument
+ *
+ * This shall only be used with commands that are guaranteed to be
+ * uninterruptable, atomic and SMP safe.
+ */
+static s32 qcom_scm_call_atomic2(u32 svc, u32 cmd, u32 arg1, u32 arg2)
+{
+   int context_id;
+
+   register u32 r0 asm("r0") = SCM_ATOMIC(svc, cmd, 2);
+   register u32 r1 asm("r1") = (u32)_id;
+   register u32 r2 asm("r2") = arg1;
+   register u32 r3 asm("r3") = arg2;
+
+   asm volatile(
+   __asmeq("%0", "r0")
+   __asmeq("%1", "r0")
+   __asmeq("%2", "r1")
+   __asmeq("%3", "r2")
+   __asmeq("%4", "r3")
+#ifdef REQUIRES_SEC
+   ".arch_extension sec\n"
+#endif
+   "smc#0  @ switch to secure world\n"
+   : "=r" (r0)
+   : "r" (r0), "r" (r1), "r" (r2), "r" (r3)
+   );
+   return r0;
+}
+
 u32 qcom_scm_get_version(void)
 {
int context_id;
@@ -378,22 +413,6 @@ u32 qcom_scm_get_version(void)
 }
 EXPORT_SYMBOL(qcom_scm_get_version);
 
-/*
- * Set the cold/warm boot address for one of the CPU cores.
- */
-static int qcom_scm_set_boot_addr(u32 addr, int flags)
-{
-   struct {
-   __le32 flags;
-   __le32 addr;
-   } cmd;
-
-   cmd.addr = cpu_to_le32(addr);
-   cmd.flags = cpu_to_le32(flags);
-   return qcom_scm_call(QCOM_SCM_SVC_BOOT, QCOM_SCM_BOOT_ADDR,
-   , sizeof(cmd), NULL, 0);
-}
-
 /**
  * qcom_scm_set_cold_boot_addr() - Set the cold boot address for cpus
  * @entry: Entry point function for the cpus
@@ -423,7 +442,8 @@ int __qcom_scm_set_cold_boot_addr(void *entry, const 
cpumask_t *cpus)
set_cpu_present(cpu, false);
}
 
-   return qcom_scm_set_boot_addr(virt_to_phys(entry), flags);
+   return qcom_scm_call_atomic2(QCOM_SCM_SVC_BOOT, QCOM_SCM_BOOT_ADDR,
+   flags, virt_to_phys(entry));
 }
 
 /**
@@ -439,6 +459,10 @@ int __qcom_scm_set_warm_boot_addr(void *entry, const 
cpumask_t *cpus)
int ret;
int flags = 0;
int cpu;
+   struct {
+   __le32 flags;
+   __le32 addr;
+   } cmd;
 
/*
 * Reassign only if we are switching from hotplug entry point
@@ -454,7 +478,10 @@ int __qcom_scm_set_warm_boot_addr(void *entry, const 
cpumask_t *cpus)
if (!flags)
return 0;
 
-   ret = qcom_scm_set_boot_addr(virt_to_phys(entry), flags);
+   cmd.addr = cpu_to_le32(virt_to_phys(entry));
+   cmd.flags = cpu_to_le32(flags);
+   ret = qcom_scm_call(QCOM_SCM_SVC_BOOT, QCOM_SCM_BOOT_ADDR,
+   , sizeof(cmd), NULL, 0);
if (!ret) {
for_each_cpu(cpu, cpus)
qcom_scm_wb[cpu].entry = entry;
-- 
1.9.1

Re: [LKP] [lkp] [net] 9317bb6982: INFO: task cat-kmsg:893 blocked for more than 300 seconds.

[Eric Dumazet]

Oh right, sorry for the delay.

On Thu, May 12, 2016 at 8:01 PM, Huang, Ying  wrote:
> "Huang, Ying"  writes:
>
>> Eric Dumazet  writes:
>>> On Mon, May 9, 2016 at 6:26 PM, Huang, Ying  
>>> wrote:
 Hi, Eric,

 kernel test robot  writes:
> FYI, we noticed the following commit:
>
> git://internal_merge_and_test_tree devel-catchup-201604281529
> commit 9317bb69824ec8d078b0b786b6971aedb0af3d4f ("net: 
> SOCKWQ_ASYNC_NOSPACE optimizations")
>
> on test machine: vm-kbuild-2G: 2 threads qemu-system-x86_64 -enable-kvm 
> -cpu Haswell,+smep,+smap with 2G memory
>
> caused below changes:
>
>
> +--+++
> |  | 210732d16d | 
> 9317bb6982 |
> +--+++
> | boot_successes   | 40 | 13  
>|
> | boot_failures| 0  | 27  
>|
> | INFO:task_blocked_for_more_than#seconds  | 0  | 27  
>|
> | RIP:native_safe_halt | 0  | 20  
>|
> | RIP:native_write_msr_safe| 0  | 27  
>|
> | Kernel_panic-not_syncing:hung_task:blocked_tasks | 0  | 27  
>|
> | backtrace:__close_fd | 0  | 27  
>|
> | backtrace:SyS_close  | 0  | 27  
>|
> | backtrace:cpu_startup_entry  | 0  | 19  
>|
> | backtrace:watchdog   | 0  | 27  
>|
> | RIP:__lock_acquire   | 0  | 2   
>|
> | backtrace:rpc_async_schedule | 0  | 2   
>|
> | backtrace:lock_acquire   | 0  | 1   
>|
> | RIP:delay_tsc| 0  | 1   
>|
> | backtrace:SYSC_epoll_wait| 0  | 1   
>|
> | backtrace:SyS_epoll_wait | 0  | 1   
>|
> | RIP:pvclock_clocksource_read | 0  | 1   
>|
> | RIP:xs_reclassify_socket | 0  | 1   
>|
> | backtrace:xs_tcp_setup_socket| 0  | 2   
>|
> | RIP:insert_work  | 0  | 1   
>|
> +--+++

 We recently found this patch cause NFS hang in 0day/LKP test system.
 The NFS export can be mounted, but after a while all read/write to NFS
 mount blocked.  This influenced the 0day/LKP testing.  Could you help us
 to fix this?

 Best Regards,
 Huang, Ying
>>>
>>>
>>> I need to officially submit this patch :
>>> http://www.spinics.net/lists/netdev/msg375777.html
>>
>> Thanks a lot!  The patch fixed our NFS hang.
>>
>> Tested-by: Huang, Ying 
>>
>> Is it possible to put the fixing patch near (preferably next) the patch
>> trigger regression?  Otherwise a bigger range of patches will not be
>> bisectable.
>
> Hi, Eric,
>
> Is it possible for this to be fixed in linux-next ASAP?  This has
> blocked us (0day functionality and performance test) from testing
> linux-next and many other git trees for near 1 week.  Because NFS is
> used in our test infrastructure to save test result data.
>
> Best Regards,
> Huang, Ying

Re: [LKP] [lkp] [net] 9317bb6982: INFO: task cat-kmsg:893 blocked for more than 300 seconds.

[Eric Dumazet]

Oh right, sorry for the delay.

On Thu, May 12, 2016 at 8:01 PM, Huang, Ying  wrote:
> "Huang, Ying"  writes:
>
>> Eric Dumazet  writes:
>>> On Mon, May 9, 2016 at 6:26 PM, Huang, Ying  
>>> wrote:
 Hi, Eric,

 kernel test robot  writes:
> FYI, we noticed the following commit:
>
> git://internal_merge_and_test_tree devel-catchup-201604281529
> commit 9317bb69824ec8d078b0b786b6971aedb0af3d4f ("net: 
> SOCKWQ_ASYNC_NOSPACE optimizations")
>
> on test machine: vm-kbuild-2G: 2 threads qemu-system-x86_64 -enable-kvm 
> -cpu Haswell,+smep,+smap with 2G memory
>
> caused below changes:
>
>
> +--+++
> |  | 210732d16d | 
> 9317bb6982 |
> +--+++
> | boot_successes   | 40 | 13  
>|
> | boot_failures| 0  | 27  
>|
> | INFO:task_blocked_for_more_than#seconds  | 0  | 27  
>|
> | RIP:native_safe_halt | 0  | 20  
>|
> | RIP:native_write_msr_safe| 0  | 27  
>|
> | Kernel_panic-not_syncing:hung_task:blocked_tasks | 0  | 27  
>|
> | backtrace:__close_fd | 0  | 27  
>|
> | backtrace:SyS_close  | 0  | 27  
>|
> | backtrace:cpu_startup_entry  | 0  | 19  
>|
> | backtrace:watchdog   | 0  | 27  
>|
> | RIP:__lock_acquire   | 0  | 2   
>|
> | backtrace:rpc_async_schedule | 0  | 2   
>|
> | backtrace:lock_acquire   | 0  | 1   
>|
> | RIP:delay_tsc| 0  | 1   
>|
> | backtrace:SYSC_epoll_wait| 0  | 1   
>|
> | backtrace:SyS_epoll_wait | 0  | 1   
>|
> | RIP:pvclock_clocksource_read | 0  | 1   
>|
> | RIP:xs_reclassify_socket | 0  | 1   
>|
> | backtrace:xs_tcp_setup_socket| 0  | 2   
>|
> | RIP:insert_work  | 0  | 1   
>|
> +--+++

 We recently found this patch cause NFS hang in 0day/LKP test system.
 The NFS export can be mounted, but after a while all read/write to NFS
 mount blocked.  This influenced the 0day/LKP testing.  Could you help us
 to fix this?

 Best Regards,
 Huang, Ying
>>>
>>>
>>> I need to officially submit this patch :
>>> http://www.spinics.net/lists/netdev/msg375777.html
>>
>> Thanks a lot!  The patch fixed our NFS hang.
>>
>> Tested-by: Huang, Ying 
>>
>> Is it possible to put the fixing patch near (preferably next) the patch
>> trigger regression?  Otherwise a bigger range of patches will not be
>> bisectable.
>
> Hi, Eric,
>
> Is it possible for this to be fixed in linux-next ASAP?  This has
> blocked us (0day functionality and performance test) from testing
> linux-next and many other git trees for near 1 week.  Because NFS is
> used in our test infrastructure to save test result data.
>
> Best Regards,
> Huang, Ying

Re: [tip:sched/core] sched/fair: Clean up scale confusion

[Yuyang Du]

On Thu, May 12, 2016 at 03:31:27AM -0700, tip-bot for Peter Zijlstra wrote:
> Commit-ID:  1be0eb2a97d756fb7dd8c9baf372d81fa9699c09
> Gitweb: http://git.kernel.org/tip/1be0eb2a97d756fb7dd8c9baf372d81fa9699c09
> Author: Peter Zijlstra 
> AuthorDate: Fri, 6 May 2016 12:21:23 +0200
> Committer:  Ingo Molnar 
> CommitDate: Thu, 12 May 2016 09:55:33 +0200
> 
> sched/fair: Clean up scale confusion
> 
> Wanpeng noted that the scale_load_down() in calculate_imbalance() was
> weird. I agree, it should be SCHED_CAPACITY_SCALE, since we're going
> to compare against busiest->group_capacity, which is in [capacity]
> units.
>
> Reported-by: Wanpeng Li 
> Signed-off-by: Peter Zijlstra (Intel) 
> Cc: Linus Torvalds 
> Cc: Mike Galbraith 
> Cc: Morten Rasmussen 
> Cc: Peter Zijlstra 
> Cc: Thomas Gleixner 
> Cc: Yuyang Du 
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Ingo Molnar 

It is good that this issue is addressed and patch merged, however, for the
record, Vincent has already had a solution for this, and we had a patch,
including other cleanups (the latest version is: 
https://lkml.org/lkml/2016/5/3/925).
And I think Ben first pointed this out (and we then attempted to address it)
as far as I can tell.

Re: [tip:sched/core] sched/fair: Clean up scale confusion

[Yuyang Du]

On Thu, May 12, 2016 at 03:31:27AM -0700, tip-bot for Peter Zijlstra wrote:
> Commit-ID:  1be0eb2a97d756fb7dd8c9baf372d81fa9699c09
> Gitweb: http://git.kernel.org/tip/1be0eb2a97d756fb7dd8c9baf372d81fa9699c09
> Author: Peter Zijlstra 
> AuthorDate: Fri, 6 May 2016 12:21:23 +0200
> Committer:  Ingo Molnar 
> CommitDate: Thu, 12 May 2016 09:55:33 +0200
> 
> sched/fair: Clean up scale confusion
> 
> Wanpeng noted that the scale_load_down() in calculate_imbalance() was
> weird. I agree, it should be SCHED_CAPACITY_SCALE, since we're going
> to compare against busiest->group_capacity, which is in [capacity]
> units.
>
> Reported-by: Wanpeng Li 
> Signed-off-by: Peter Zijlstra (Intel) 
> Cc: Linus Torvalds 
> Cc: Mike Galbraith 
> Cc: Morten Rasmussen 
> Cc: Peter Zijlstra 
> Cc: Thomas Gleixner 
> Cc: Yuyang Du 
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Ingo Molnar 

It is good that this issue is addressed and patch merged, however, for the
record, Vincent has already had a solution for this, and we had a patch,
including other cleanups (the latest version is: 
https://lkml.org/lkml/2016/5/3/925).
And I think Ben first pointed this out (and we then attempted to address it)
as far as I can tell.

Re: [PATCH] cfg80211/nl80211: add wifi tx power mode switching support

[Wei-Ning Huang]

On Fri, May 13, 2016 at 6:02 AM, Arend van Spriel
 wrote:
> On 12-05-16 11:34, Wei-Ning Huang wrote:
>> On Thu, May 12, 2016 at 2:33 AM, Dan Williams  wrote:
>>> On Wed, 2016-05-11 at 13:03 +0800, Wei-Ning Huang wrote:
 On Fri, May 6, 2016 at 4:19 PM, Wei-Ning Huang 
 wrote:
>
> On Fri, May 6, 2016 at 12:07 AM, Dan Williams 
> wrote:
>>
>>
>> On Thu, 2016-05-05 at 14:44 +0800, Wei-Ning Huang wrote:
>>>
>>> Recent new hardware has the ability to switch between tablet
>>> mode and
>>> clamshell mode. To optimize WiFi performance, we want to be
>>> able to
>>> use
>>> different power table between modes. This patch adds a new
>>> netlink
>>> message type and cfg80211_ops function to allow userspace to
>>> trigger
>>> a
>>> power mode switch for a given wireless interface.
>>>
>>> Signed-off-by: Wei-Ning Huang 
>>> ---
>>>  include/net/cfg80211.h   | 11 +++
>>>  include/uapi/linux/nl80211.h | 21 +
>>>  net/wireless/nl80211.c   | 16 
>>>  net/wireless/rdev-ops.h  | 22 ++
>>>  net/wireless/trace.h | 20 
>>>  5 files changed, 90 insertions(+)
>>>
>>> diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
>>> index 9e1b24c..aa77fa0 100644
>>> --- a/include/net/cfg80211.h
>>> +++ b/include/net/cfg80211.h
>>> @@ -2370,6 +2370,12 @@ struct cfg80211_qos_map {
>>>   * @get_tx_power: store the current TX power into the dbm
>>> variable;
>>>   *   return 0 if successful
>>>   *
>>> + * @set_tx_power_mode: set the transmit power mode. Some
>>> device have
>>> the ability
>>> + *   to transform between different mode such as clamshell and
>>> tablet mode.
>>> + *   set_tx_power_mode allows setting of different TX power
>>> mode at runtime.
>>> + * @get_tx_power_mode: store the current TX power mode into
>>> the mode
>>> variable;
>>> + *   return 0 if successful
>>> + *
>>>   * @set_wds_peer: set the WDS peer for a WDS interface
>>>   *
>>>   * @rfkill_poll: polls the hw rfkill line, use cfg80211
>>> reporting
>>> @@ -2631,6 +2637,11 @@ struct cfg80211_ops {
>>>   int (*get_tx_power)(struct wiphy *wiphy, struct
>>> wireless_dev *wdev,
>>>   int *dbm);
>>>
>>> + int (*set_tx_power_mode)(struct wiphy *wiphy,
>>> +  enum nl80211_tx_power_mode
>>> mode);
>>> + int (*get_tx_power_mode)(struct wiphy *wiphy,
>>> +  enum nl80211_tx_power_mode
>>> *mode);
>>> +
>>>   int (*set_wds_peer)(struct wiphy *wiphy, struct
>>> net_device *dev,
>>>   const u8 *addr);
>>>
>>> diff --git a/include/uapi/linux/nl80211.h
>>> b/include/uapi/linux/nl80211.h
>>> index 5a30a75..9b1888a 100644
>>> --- a/include/uapi/linux/nl80211.h
>>> +++ b/include/uapi/linux/nl80211.h
>>> @@ -1796,6 +1796,9 @@ enum nl80211_commands {
>>>   *   connecting to a PCP, and in %NL80211_CMD_START_AP to
>>> start
>>>   *   a PCP instead of AP. Relevant for DMG networks only.
>>>   *
>>> + * @NL80211_ATTR_WIPHY_TX_POWER_MODE: Transmit power mode. See
>>> + *   nl80211_tx_power_mode for possible values.
>>> + *
>>>   * @NUM_NL80211_ATTR: total number of nl80211_attrs available
>>>   * @NL80211_ATTR_MAX: highest attribute number currently
>>> defined
>>>   * @__NL80211_ATTR_AFTER_LAST: internal use
>>> @@ -2172,6 +2175,8 @@ enum nl80211_attrs {
>>>
>>>   NL80211_ATTR_PBSS,
>>>
>>> + NL80211_ATTR_WIPHY_TX_POWER_MODE,
>>> +
>>>   /* add attributes here, update the policy in nl80211.c */
>>>
>>>   __NL80211_ATTR_AFTER_LAST,
>>> @@ -3703,6 +3708,22 @@ enum nl80211_tx_power_setting {
>>>  };
>>>
>>>  /**
>>> + * enum nl80211_tx_power_mode - TX power mode setting
>>> + * @NL80211_TX_POWER_LOW: general low TX power mode
>>> + * @NL80211_TX_POWER_MEDIUM: general medium TX power mode
>>> + * @NL80211_TX_POWER_HIGH: general high TX power mode
>>> + * @NL80211_TX_POWER_CLAMSHELL: clamshell mode TX power mode
>>> + * @NL80211_TX_POWER_TABLET: tablet mode TX power mode
>>> + */
>>> +enum nl80211_tx_power_mode {
>>> + NL80211_TX_POWER_LOW,
>>> + NL80211_TX_POWER_MEDIUM,
>>> + NL80211_TX_POWER_HIGH,
>>> + NL80211_TX_POWER_CLAMSHELL,
>>> + NL80211_TX_POWER_TABLET,
>>
>> "clamshell" and "tablet" probably mean many different things to
>> many
>> different people with respect to whether or not they should do
>> anything
>> 

Re: [PATCH] cfg80211/nl80211: add wifi tx power mode switching support

[Wei-Ning Huang]

On Fri, May 13, 2016 at 6:02 AM, Arend van Spriel
 wrote:
> On 12-05-16 11:34, Wei-Ning Huang wrote:
>> On Thu, May 12, 2016 at 2:33 AM, Dan Williams  wrote:
>>> On Wed, 2016-05-11 at 13:03 +0800, Wei-Ning Huang wrote:
 On Fri, May 6, 2016 at 4:19 PM, Wei-Ning Huang 
 wrote:
>
> On Fri, May 6, 2016 at 12:07 AM, Dan Williams 
> wrote:
>>
>>
>> On Thu, 2016-05-05 at 14:44 +0800, Wei-Ning Huang wrote:
>>>
>>> Recent new hardware has the ability to switch between tablet
>>> mode and
>>> clamshell mode. To optimize WiFi performance, we want to be
>>> able to
>>> use
>>> different power table between modes. This patch adds a new
>>> netlink
>>> message type and cfg80211_ops function to allow userspace to
>>> trigger
>>> a
>>> power mode switch for a given wireless interface.
>>>
>>> Signed-off-by: Wei-Ning Huang 
>>> ---
>>>  include/net/cfg80211.h   | 11 +++
>>>  include/uapi/linux/nl80211.h | 21 +
>>>  net/wireless/nl80211.c   | 16 
>>>  net/wireless/rdev-ops.h  | 22 ++
>>>  net/wireless/trace.h | 20 
>>>  5 files changed, 90 insertions(+)
>>>
>>> diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
>>> index 9e1b24c..aa77fa0 100644
>>> --- a/include/net/cfg80211.h
>>> +++ b/include/net/cfg80211.h
>>> @@ -2370,6 +2370,12 @@ struct cfg80211_qos_map {
>>>   * @get_tx_power: store the current TX power into the dbm
>>> variable;
>>>   *   return 0 if successful
>>>   *
>>> + * @set_tx_power_mode: set the transmit power mode. Some
>>> device have
>>> the ability
>>> + *   to transform between different mode such as clamshell and
>>> tablet mode.
>>> + *   set_tx_power_mode allows setting of different TX power
>>> mode at runtime.
>>> + * @get_tx_power_mode: store the current TX power mode into
>>> the mode
>>> variable;
>>> + *   return 0 if successful
>>> + *
>>>   * @set_wds_peer: set the WDS peer for a WDS interface
>>>   *
>>>   * @rfkill_poll: polls the hw rfkill line, use cfg80211
>>> reporting
>>> @@ -2631,6 +2637,11 @@ struct cfg80211_ops {
>>>   int (*get_tx_power)(struct wiphy *wiphy, struct
>>> wireless_dev *wdev,
>>>   int *dbm);
>>>
>>> + int (*set_tx_power_mode)(struct wiphy *wiphy,
>>> +  enum nl80211_tx_power_mode
>>> mode);
>>> + int (*get_tx_power_mode)(struct wiphy *wiphy,
>>> +  enum nl80211_tx_power_mode
>>> *mode);
>>> +
>>>   int (*set_wds_peer)(struct wiphy *wiphy, struct
>>> net_device *dev,
>>>   const u8 *addr);
>>>
>>> diff --git a/include/uapi/linux/nl80211.h
>>> b/include/uapi/linux/nl80211.h
>>> index 5a30a75..9b1888a 100644
>>> --- a/include/uapi/linux/nl80211.h
>>> +++ b/include/uapi/linux/nl80211.h
>>> @@ -1796,6 +1796,9 @@ enum nl80211_commands {
>>>   *   connecting to a PCP, and in %NL80211_CMD_START_AP to
>>> start
>>>   *   a PCP instead of AP. Relevant for DMG networks only.
>>>   *
>>> + * @NL80211_ATTR_WIPHY_TX_POWER_MODE: Transmit power mode. See
>>> + *   nl80211_tx_power_mode for possible values.
>>> + *
>>>   * @NUM_NL80211_ATTR: total number of nl80211_attrs available
>>>   * @NL80211_ATTR_MAX: highest attribute number currently
>>> defined
>>>   * @__NL80211_ATTR_AFTER_LAST: internal use
>>> @@ -2172,6 +2175,8 @@ enum nl80211_attrs {
>>>
>>>   NL80211_ATTR_PBSS,
>>>
>>> + NL80211_ATTR_WIPHY_TX_POWER_MODE,
>>> +
>>>   /* add attributes here, update the policy in nl80211.c */
>>>
>>>   __NL80211_ATTR_AFTER_LAST,
>>> @@ -3703,6 +3708,22 @@ enum nl80211_tx_power_setting {
>>>  };
>>>
>>>  /**
>>> + * enum nl80211_tx_power_mode - TX power mode setting
>>> + * @NL80211_TX_POWER_LOW: general low TX power mode
>>> + * @NL80211_TX_POWER_MEDIUM: general medium TX power mode
>>> + * @NL80211_TX_POWER_HIGH: general high TX power mode
>>> + * @NL80211_TX_POWER_CLAMSHELL: clamshell mode TX power mode
>>> + * @NL80211_TX_POWER_TABLET: tablet mode TX power mode
>>> + */
>>> +enum nl80211_tx_power_mode {
>>> + NL80211_TX_POWER_LOW,
>>> + NL80211_TX_POWER_MEDIUM,
>>> + NL80211_TX_POWER_HIGH,
>>> + NL80211_TX_POWER_CLAMSHELL,
>>> + NL80211_TX_POWER_TABLET,
>>
>> "clamshell" and "tablet" probably mean many different things to
>> many
>> different people with respect to whether or not they should do
>> anything
>> with power saving or wifi.  I feel like a more generic interface
>> is
>> needed here.
> We 

Re: [PATCH 3/6] dt-bindings: mtu3: add devicetree bindings

[chunfeng yun]

On Thu, 2016-05-12 at 22:09 -0500, Rob Herring wrote:
> On Thu, May 12, 2016 at 9:00 PM, chunfeng yun  
> wrote:
> > Hi,
> >
> > On Thu, 2016-05-12 at 19:02 -0400, Alan Cooper wrote:
> >> On Thu, May 12, 2016 at 3:24 AM, chunfeng yun  
> >> wrote:
> >> >> > + - mediatek,enable-manual-drd : supports manual dual-role switch by 
> >> >> > sysfs
> >> >> > +   interface; only used when receptacle is TYPE-A and also wants to 
> >> >> > support
> >> >> > +   dual-role mode.
> >> >>
> >> >> sysfs is a Linux detail that doesn't apply to the binding. Does the
> >> >> property mean "the IP block supports or doesn't support switching"  or
> >> >> "I want to enable switching feature". Only the former belongs in DT.
> >> >>
> >> > It is the former case, and has little relation with sysfs interface.
> >> > I will modify it later, sorry for my unclear description.
> >>
> >> Could the property name be just "enable-manual-drd" instead of
> >> "mediatek,enable-manual-drd"? I expect to have to add this
> >> functionality to our USB driver in the near future.
> >
> > Do you mean provide some APIs to in common USB driver?
> 
> Probably, but first just put the property in a common binding doc.
> 
Ok, I modify it later

Thanks.

> Rob

Re: [PATCH 3/6] dt-bindings: mtu3: add devicetree bindings

[chunfeng yun]

On Thu, 2016-05-12 at 22:09 -0500, Rob Herring wrote:
> On Thu, May 12, 2016 at 9:00 PM, chunfeng yun  
> wrote:
> > Hi,
> >
> > On Thu, 2016-05-12 at 19:02 -0400, Alan Cooper wrote:
> >> On Thu, May 12, 2016 at 3:24 AM, chunfeng yun  
> >> wrote:
> >> >> > + - mediatek,enable-manual-drd : supports manual dual-role switch by 
> >> >> > sysfs
> >> >> > +   interface; only used when receptacle is TYPE-A and also wants to 
> >> >> > support
> >> >> > +   dual-role mode.
> >> >>
> >> >> sysfs is a Linux detail that doesn't apply to the binding. Does the
> >> >> property mean "the IP block supports or doesn't support switching"  or
> >> >> "I want to enable switching feature". Only the former belongs in DT.
> >> >>
> >> > It is the former case, and has little relation with sysfs interface.
> >> > I will modify it later, sorry for my unclear description.
> >>
> >> Could the property name be just "enable-manual-drd" instead of
> >> "mediatek,enable-manual-drd"? I expect to have to add this
> >> functionality to our USB driver in the near future.
> >
> > Do you mean provide some APIs to in common USB driver?
> 
> Probably, but first just put the property in a common binding doc.
> 
Ok, I modify it later

Thanks.

> Rob

linux-next: build failure after merge of the staging tree

[Stephen Rothwell]

Hi Greg,

After merging the staging tree, today's linux-next build (x86_64
allmodconfig) failed like this:

drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c:1706:9: 
error: too few arguments to function 'ib_map_mr_sg'
 n = ib_map_mr_sg(mr, tx->tx_frags,
 ^
In file included from /home/sfr/next/next/include/rdma/ib_addr.h:47:0,
 from /home/sfr/next/next/include/rdma/rdma_cm.h:39,
 from 
/home/sfr/next/next/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.h:63,
 from 
/home/sfr/next/next/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c:43:
/home/sfr/next/next/include/rdma/ib_verbs.h:3147:5: note: declared here
 int ib_map_mr_sg(struct ib_mr *mr, struct scatterlist *sg, int sg_nents,
 ^

Caused by commit

  80e05b34f882 ("staging: lustre: o2iblnd: Add Fast Reg memory registration 
support")

interacting with commits

  aa42d65b5e20 ("IB/core: allow passing mapping an offset into the SG in 
ib_map_mr_sg")
  f0cf99be3251 ("IB/core: Enhance ib_map_mr_sg()")

from the rdma-leon-test tree.

I added the following merge fix patch for today:

From: Stephen Rothwell 
Date: Fri, 13 May 2016 13:10:47 +1000
Subject: [PATCH] staging: lustre: o2iblnd: fix for ib_map_mr_sg() API changes

Signed-off-by: Stephen Rothwell 
---
 drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c 
b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
index d99b4fac0c39..6c59f2ff2220 100644
--- a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
+++ b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
@@ -1704,7 +1704,7 @@ int kiblnd_fmr_pool_map(kib_fmr_poolset_t *fps, kib_tx_t 
*tx,
}
 
n = ib_map_mr_sg(mr, tx->tx_frags,
-tx->tx_nfrags, PAGE_SIZE);
+tx->tx_nfrags, NULL, 
PAGE_SIZE);
if (unlikely(n != tx->tx_nfrags)) {
CERROR("Failed to map mr %d/%d 
elements\n",
   n, tx->tx_nfrags);
-- 
2.7.0

-- 
Cheers,
Stephen Rothwell

linux-next: build failure after merge of the staging tree

[Stephen Rothwell]

Hi Greg,

After merging the staging tree, today's linux-next build (x86_64
allmodconfig) failed like this:

drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c:1706:9: 
error: too few arguments to function 'ib_map_mr_sg'
 n = ib_map_mr_sg(mr, tx->tx_frags,
 ^
In file included from /home/sfr/next/next/include/rdma/ib_addr.h:47:0,
 from /home/sfr/next/next/include/rdma/rdma_cm.h:39,
 from 
/home/sfr/next/next/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.h:63,
 from 
/home/sfr/next/next/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c:43:
/home/sfr/next/next/include/rdma/ib_verbs.h:3147:5: note: declared here
 int ib_map_mr_sg(struct ib_mr *mr, struct scatterlist *sg, int sg_nents,
 ^

Caused by commit

  80e05b34f882 ("staging: lustre: o2iblnd: Add Fast Reg memory registration 
support")

interacting with commits

  aa42d65b5e20 ("IB/core: allow passing mapping an offset into the SG in 
ib_map_mr_sg")
  f0cf99be3251 ("IB/core: Enhance ib_map_mr_sg()")

from the rdma-leon-test tree.

I added the following merge fix patch for today:

From: Stephen Rothwell 
Date: Fri, 13 May 2016 13:10:47 +1000
Subject: [PATCH] staging: lustre: o2iblnd: fix for ib_map_mr_sg() API changes

Signed-off-by: Stephen Rothwell 
---
 drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c 
b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
index d99b4fac0c39..6c59f2ff2220 100644
--- a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
+++ b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
@@ -1704,7 +1704,7 @@ int kiblnd_fmr_pool_map(kib_fmr_poolset_t *fps, kib_tx_t 
*tx,
}
 
n = ib_map_mr_sg(mr, tx->tx_frags,
-tx->tx_nfrags, PAGE_SIZE);
+tx->tx_nfrags, NULL, 
PAGE_SIZE);
if (unlikely(n != tx->tx_nfrags)) {
CERROR("Failed to map mr %d/%d 
elements\n",
   n, tx->tx_nfrags);
-- 
2.7.0

-- 
Cheers,
Stephen Rothwell

Re: [PATCH 2/2] cpufreq: governor: CPUFREQ_GOV_STOP never fails

[Viresh Kumar]

On 12-05-16, 15:14, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki 
> 
> None of the cpufreq governors currently in the tree will ever fail
> an invocation of the ->governor() callback with the event argument
> equal to CPUFREQ_GOV_STOP (unless invoked with incorrect arguments
> which doesn't matter anyway) and it is rather difficult to imagine
> a valid reason for such a failure.
> 
> Accordingly, rearrange the code in the core to make it clear that
> this call never fails.
> 
> Signed-off-by: Rafael J. Wysocki 
> ---
>  drivers/cpufreq/cpufreq.c |   40 +++-
>  1 file changed, 11 insertions(+), 29 deletions(-)

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH 1/2] cpufreq: governor: CPUFREQ_GOV_POLICY_EXIT never fails

[Viresh Kumar]

On 12-05-16, 15:13, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki 
> 
> None of the cpufreq governors currently in the tree will ever fail
> an invocation of the ->governor() callback with the event argument
> equal to CPUFREQ_GOV_POLICY_EXIT (unless invoked with incorrect
> arguments which doesn't matter anyway) and it wouldn't really
> make sense to fail it, because the caller won't be able to handle
> that failure in a meaningful way.
> 
> Accordingly, rearrange the code in the core to make it clear that
> this call never fails.
> 
> Signed-off-by: Rafael J. Wysocki 
> ---
>  drivers/cpufreq/cpufreq.c |   35 ---
>  1 file changed, 12 insertions(+), 23 deletions(-)

Acked-by: Viresh Kumar 

-- 
viresh