Re: [RFC PATCH v2 02/20] x86: Set the write-protect cache mode for full PAT support

[Borislav Petkov]

On Mon, Aug 22, 2016 at 05:35:50PM -0500, Tom Lendacky wrote:
> For processors that support PAT, set the write-protect cache mode
> (_PAGE_CACHE_MODE_WP) entry to the actual write-protect value (x05).
> 
> Signed-off-by: Tom Lendacky 
> ---
>  arch/x86/mm/pat.c |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Acked-by: Borislav Petkov 

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--

Re: [RFC PATCH v2 02/20] x86: Set the write-protect cache mode for full PAT support

[Borislav Petkov]

On Mon, Aug 22, 2016 at 05:35:50PM -0500, Tom Lendacky wrote:
> For processors that support PAT, set the write-protect cache mode
> (_PAGE_CACHE_MODE_WP) entry to the actual write-protect value (x05).
> 
> Signed-off-by: Tom Lendacky 
> ---
>  arch/x86/mm/pat.c |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Acked-by: Borislav Petkov 

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--

[PATCH] [IA64] MCA: Use kmalloc_array() in init_record_index_pools()

[SF Markus Elfring]

From: Markus Elfring 
Date: Thu, 25 Aug 2016 07:37:46 +0200

* A multiplication for the size determination of a memory allocation
  indicated that an array data structure should be processed.
  Thus reuse the corresponding function "kmalloc_array".

  This issue was detected by using the Coccinelle software.

* Replace the specification of a data structure by a pointer dereference
  to make the corresponding size determination a bit safer according to
  the Linux coding style convention.

Signed-off-by: Markus Elfring 
---
 arch/ia64/kernel/mca_drv.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/ia64/kernel/mca_drv.c b/arch/ia64/kernel/mca_drv.c
index 94f8bf7..e4ce128 100644
--- a/arch/ia64/kernel/mca_drv.c
+++ b/arch/ia64/kernel/mca_drv.c
@@ -349,9 +349,9 @@ init_record_index_pools(void)
 
/* - 3 - */
slidx_pool.max_idx = (rec_max_size/sect_min_size) * 2 + 1;
-   slidx_pool.buffer =
-   kmalloc(slidx_pool.max_idx * sizeof(slidx_list_t), GFP_KERNEL);
-
+   slidx_pool.buffer = kmalloc_array(slidx_pool.max_idx,
+ sizeof(*slidx_pool.buffer),
+ GFP_KERNEL);
return slidx_pool.buffer ? 0 : -ENOMEM;
 }
 
-- 
2.9.3

Re: [patch 1/2] i2c: add master driver for mellanox systems

[kbuild test robot]

Hi Vadim,

[auto build test ERROR on wsa/i2c/for-next]
[also build test ERROR on v4.8-rc3 next-20160824]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]
[Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for 
convenience) to record what (public, well-known) commit your patch series was 
built on]
[Check https://git-scm.com/docs/git-format-patch for more information]

url:
https://github.com/0day-ci/linux/commits/vadimp-mellanox-com/i2c-add-master-driver-for-mellanox-systems/20160824-200057
base:   https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git 
i2c/for-next
config: x86_64-randconfig-s1-08242121 (attached as .config)
compiler: gcc-4.4 (Debian 4.4.7-8) 4.4.7
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/i2c/busses/i2c-mlxcpld.c: In function 'mlxcpld_i2c_lpc_write_buf':
>> drivers/i2c/busses/i2c-mlxcpld.c:148: error: implicit declaration of 
>> function 'outl'
>> drivers/i2c/busses/i2c-mlxcpld.c:153: error: implicit declaration of 
>> function 'outb'
   drivers/i2c/busses/i2c-mlxcpld.c: In function 'mlxcpld_i2c_lpc_read_buf':
>> drivers/i2c/busses/i2c-mlxcpld.c:163: error: implicit declaration of 
>> function 'inl'
>> drivers/i2c/busses/i2c-mlxcpld.c:168: error: implicit declaration of 
>> function 'inb'
   drivers/i2c/busses/i2c-mlxcpld.c: In function 'mlxcpld_i2c_read_comm':
>> drivers/i2c/busses/i2c-mlxcpld.c:181: error: implicit declaration of 
>> function 'inw'
   drivers/i2c/busses/i2c-mlxcpld.c: In function 'mlxcpld_i2c_write_comm':
>> drivers/i2c/busses/i2c-mlxcpld.c:206: error: implicit declaration of 
>> function 'outw'

vim +/outl +148 drivers/i2c/busses/i2c-mlxcpld.c

   142  {
   143  int i, nbyte, ndword;
   144  
   145  nbyte = len % 4;
   146  ndword = len / 4;
   147  for (i = 0; i < ndword; i++)
 > 148  outl(*((u32 *)data + i), addr + i * 4);
   149  ndword *= 4;
   150  addr += ndword;
   151  data += ndword;
   152  for (i = 0; i < nbyte; i++)
 > 153  outb(*(data + i), addr + i);
   154  }
   155  
   156  static void mlxcpld_i2c_lpc_read_buf(u8 *data, u8 len, u32 addr)
   157  {
   158  int i, nbyte, ndword;
   159  
   160  nbyte = len % 4;
   161  ndword = len / 4;
   162  for (i = 0; i < ndword; i++)
 > 163  *((u32 *)data + i) = inl(addr + i * 4);
   164  ndword *= 4;
   165  addr += ndword;
   166  data += ndword;
   167  for (i = 0; i < nbyte; i++)
 > 168  *(data + i) = inb(addr + i);
   169  }
   170  
   171  static void mlxcpld_i2c_read_comm(struct mlxcpld_i2c_priv *priv, u8 
offs,
   172u8 *data, u8 datalen)
   173  {
   174  u32 addr = priv->base_addr + offs;
   175  
   176  switch (datalen) {
   177  case 1:
   178  *(data) = inb(addr);
   179  break;
   180  case 2:
 > 181  *((u16 *)data) = inw(addr);
   182  break;
   183  case 3:
   184  *((u16 *)data) = inw(addr);
   185  *(data + 2) = inb(addr + 2);
   186  break;
   187  case 4:
   188  *((u32 *)data) = inl(addr);
   189  break;
   190  default:
   191  mlxcpld_i2c_lpc_read_buf(data, datalen, addr);
   192  break;
   193  }
   194  }
   195  
   196  static void mlxcpld_i2c_write_comm(struct mlxcpld_i2c_priv *priv, u8 
offs,
   197 u8 *data, u8 datalen)
   198  {
   199  u32 addr = priv->base_addr + offs;
   200  
   201  switch (datalen) {
   202  case 1:
   203  outb(*(data), addr);
   204  break;
   205  case 2:
 > 206  outw(*((u16 *)data), addr);
   207  break;
   208  case 3:
   209  outw(*((u16 *)data), addr);

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

[PATCH] [IA64] MCA: Use kmalloc_array() in init_record_index_pools()

[SF Markus Elfring]

From: Markus Elfring 
Date: Thu, 25 Aug 2016 07:37:46 +0200

* A multiplication for the size determination of a memory allocation
  indicated that an array data structure should be processed.
  Thus reuse the corresponding function "kmalloc_array".

  This issue was detected by using the Coccinelle software.

* Replace the specification of a data structure by a pointer dereference
  to make the corresponding size determination a bit safer according to
  the Linux coding style convention.

Signed-off-by: Markus Elfring 
---
 arch/ia64/kernel/mca_drv.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/ia64/kernel/mca_drv.c b/arch/ia64/kernel/mca_drv.c
index 94f8bf7..e4ce128 100644
--- a/arch/ia64/kernel/mca_drv.c
+++ b/arch/ia64/kernel/mca_drv.c
@@ -349,9 +349,9 @@ init_record_index_pools(void)
 
/* - 3 - */
slidx_pool.max_idx = (rec_max_size/sect_min_size) * 2 + 1;
-   slidx_pool.buffer =
-   kmalloc(slidx_pool.max_idx * sizeof(slidx_list_t), GFP_KERNEL);
-
+   slidx_pool.buffer = kmalloc_array(slidx_pool.max_idx,
+ sizeof(*slidx_pool.buffer),
+ GFP_KERNEL);
return slidx_pool.buffer ? 0 : -ENOMEM;
 }
 
-- 
2.9.3

Re: [patch 1/2] i2c: add master driver for mellanox systems

[kbuild test robot]

Hi Vadim,

[auto build test ERROR on wsa/i2c/for-next]
[also build test ERROR on v4.8-rc3 next-20160824]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]
[Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for 
convenience) to record what (public, well-known) commit your patch series was 
built on]
[Check https://git-scm.com/docs/git-format-patch for more information]

url:
https://github.com/0day-ci/linux/commits/vadimp-mellanox-com/i2c-add-master-driver-for-mellanox-systems/20160824-200057
base:   https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git 
i2c/for-next
config: x86_64-randconfig-s1-08242121 (attached as .config)
compiler: gcc-4.4 (Debian 4.4.7-8) 4.4.7
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/i2c/busses/i2c-mlxcpld.c: In function 'mlxcpld_i2c_lpc_write_buf':
>> drivers/i2c/busses/i2c-mlxcpld.c:148: error: implicit declaration of 
>> function 'outl'
>> drivers/i2c/busses/i2c-mlxcpld.c:153: error: implicit declaration of 
>> function 'outb'
   drivers/i2c/busses/i2c-mlxcpld.c: In function 'mlxcpld_i2c_lpc_read_buf':
>> drivers/i2c/busses/i2c-mlxcpld.c:163: error: implicit declaration of 
>> function 'inl'
>> drivers/i2c/busses/i2c-mlxcpld.c:168: error: implicit declaration of 
>> function 'inb'
   drivers/i2c/busses/i2c-mlxcpld.c: In function 'mlxcpld_i2c_read_comm':
>> drivers/i2c/busses/i2c-mlxcpld.c:181: error: implicit declaration of 
>> function 'inw'
   drivers/i2c/busses/i2c-mlxcpld.c: In function 'mlxcpld_i2c_write_comm':
>> drivers/i2c/busses/i2c-mlxcpld.c:206: error: implicit declaration of 
>> function 'outw'

vim +/outl +148 drivers/i2c/busses/i2c-mlxcpld.c

   142  {
   143  int i, nbyte, ndword;
   144  
   145  nbyte = len % 4;
   146  ndword = len / 4;
   147  for (i = 0; i < ndword; i++)
 > 148  outl(*((u32 *)data + i), addr + i * 4);
   149  ndword *= 4;
   150  addr += ndword;
   151  data += ndword;
   152  for (i = 0; i < nbyte; i++)
 > 153  outb(*(data + i), addr + i);
   154  }
   155  
   156  static void mlxcpld_i2c_lpc_read_buf(u8 *data, u8 len, u32 addr)
   157  {
   158  int i, nbyte, ndword;
   159  
   160  nbyte = len % 4;
   161  ndword = len / 4;
   162  for (i = 0; i < ndword; i++)
 > 163  *((u32 *)data + i) = inl(addr + i * 4);
   164  ndword *= 4;
   165  addr += ndword;
   166  data += ndword;
   167  for (i = 0; i < nbyte; i++)
 > 168  *(data + i) = inb(addr + i);
   169  }
   170  
   171  static void mlxcpld_i2c_read_comm(struct mlxcpld_i2c_priv *priv, u8 
offs,
   172u8 *data, u8 datalen)
   173  {
   174  u32 addr = priv->base_addr + offs;
   175  
   176  switch (datalen) {
   177  case 1:
   178  *(data) = inb(addr);
   179  break;
   180  case 2:
 > 181  *((u16 *)data) = inw(addr);
   182  break;
   183  case 3:
   184  *((u16 *)data) = inw(addr);
   185  *(data + 2) = inb(addr + 2);
   186  break;
   187  case 4:
   188  *((u32 *)data) = inl(addr);
   189  break;
   190  default:
   191  mlxcpld_i2c_lpc_read_buf(data, datalen, addr);
   192  break;
   193  }
   194  }
   195  
   196  static void mlxcpld_i2c_write_comm(struct mlxcpld_i2c_priv *priv, u8 
offs,
   197 u8 *data, u8 datalen)
   198  {
   199  u32 addr = priv->base_addr + offs;
   200  
   201  switch (datalen) {
   202  case 1:
   203  outb(*(data), addr);
   204  break;
   205  case 2:
 > 206  outw(*((u16 *)data), addr);
   207  break;
   208  case 3:
   209  outw(*((u16 *)data), addr);

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

Re: [PATCH v2] PCI: altera: Retrain link in rootport mode only

[Ley Foon Tan]

On Thu, Aug 25, 2016 at 1:54 AM, Bjorn Helgaas  wrote:
> [+cc Ray, Scott, Jon, bcm-kernel-feedback-list]
>
> On Wed, Aug 24, 2016 at 03:07:52PM +0800, Ley Foon Tan wrote:
>> On Mon, Aug 22, 2016 at 11:47 PM, Bjorn Helgaas  wrote:
>> > On Fri, Aug 19, 2016 at 04:24:38PM +0800, Ley Foon Tan wrote:
>> >> Altera PCIe IP can be configured as rootport or device and they might have
>> >> same vendor ID. It will cause the system hang issue if Altera PCIe is in
>> >> endpoint mode and work with other PCIe rootport that from other vendors.
>> >> So, add the rootport mode checking in link retrain fixup function.
>> >>
>> >> Signed-off-by: Ley Foon Tan 
>> >> ---
>> >> v2: change to check PCIe type is PCI_EXP_TYPE_ROOT_PORT
>> >> ---
>> >>  drivers/pci/host/pcie-altera.c | 3 +++
>> >>  1 file changed, 3 insertions(+)
>> >>
>> >> diff --git a/drivers/pci/host/pcie-altera.c 
>> >> b/drivers/pci/host/pcie-altera.c
>> >> index 58eef99..33b6968 100644
>> >> --- a/drivers/pci/host/pcie-altera.c
>> >> +++ b/drivers/pci/host/pcie-altera.c
>> >> @@ -139,6 +139,9 @@ static void altera_pcie_retrain(struct pci_dev *dev)
>> >>   u16 linkcap, linkstat;
>> >>   struct altera_pcie *pcie = dev->bus->sysdata;
>> >>
>> >> + if (pci_pcie_type(dev) != PCI_EXP_TYPE_ROOT_PORT)
>> >> + return;
>> >> +
>> >>   if (!altera_pcie_link_is_up(pcie))
>> >>   return;
>> >
>> > Instead of making this a PCI fixup, can you make an
>> > altera_pcie_host_init() function, call it from altera_pcie_probe(),
>> > and do the link retrain there?  Then you wouldn't need to worry about
>> > whether this is a Root Port or an Endpoint, plus it would make the
>> > altera driver structure more like the other drivers.
>> >
>> > You would call altera_pcie_host_init() before pci_scan_root_bus(), so
>> > you wouldn't have a pci_dev yet, so you wouldn't be able to use
>> > pcie_capability_set_word() to set the PCI_EXP_LNKCTL_RL bit.  But I
>> > assume there's some device-dependent way to access it using
>> > cra_writel()?
>> We can't use cra_write() to set PCI_EXP_LNKCTL_RL bit.
>
> Why not?  I don't mean it has to be cra_write(), but isn't there some
> way you can write that bit before we scan the root bus?  It doesn't
> make sense that we have to scan the bus before we can train the link.
>
> We want to be able to tell the PCI core "all the device-specific root
> complex initialization has been done, here are the config accessors
> you need, please scan for devices."  I want to keep device-specific
> things like this quirk directly in the driver and out of the
> enumeration process.
We don't have internal register bit to trigger link retrain, but need to set
PCI_EXP_LNKCTL_RL bit in Link Control register of PCIe Capabilities Structure.
So, this requires the altera_pcie_cfg_read() and altera_pcie_cfg_write().
I can restructure the altera_pcie_cfg_read() and
altera_pcie_cfg_write() and have
new _altera_pcie_cfg_read() and _altera_pcie_cfg_write() that avoid
the dependency of struct pci_bus. By doing this, we can retrain the link before
pci_scan_root_bus and remove _FIXUP()

Will send new v3 patch, please take a look.

>
>> We can use
>> pci_bus_find_capability() and pci_bus_read_config_word() with struct
>> pci_bus instead.
>> But this only can be called after pci_scan_root_bus().
>
>> Found
>> iproc_pcie_check_link() have similar implementation.
>
> You're right, and I don't like iproc_pcie_check_link() either, for the
> same reasons.
>
> The iproc_pcie_check_link() is a little better because it's called
> before enumeration:
>
>   pci_create_root_bus()
>   iproc_pcie_check_link()
>   pci_scan_child_bus()
>
> But it would be a lot better if iproc_pcie_check_link() were done
> first, before pci_create_root_bus().  Then it would be more like the
> structure of other drivers, and we could use pci_scan_root_bus()
> instead.
>
> Comments, iproc folks?
>
> Bjorn
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] PCI: altera: Retrain link in rootport mode only

[Ley Foon Tan]

On Thu, Aug 25, 2016 at 1:54 AM, Bjorn Helgaas  wrote:
> [+cc Ray, Scott, Jon, bcm-kernel-feedback-list]
>
> On Wed, Aug 24, 2016 at 03:07:52PM +0800, Ley Foon Tan wrote:
>> On Mon, Aug 22, 2016 at 11:47 PM, Bjorn Helgaas  wrote:
>> > On Fri, Aug 19, 2016 at 04:24:38PM +0800, Ley Foon Tan wrote:
>> >> Altera PCIe IP can be configured as rootport or device and they might have
>> >> same vendor ID. It will cause the system hang issue if Altera PCIe is in
>> >> endpoint mode and work with other PCIe rootport that from other vendors.
>> >> So, add the rootport mode checking in link retrain fixup function.
>> >>
>> >> Signed-off-by: Ley Foon Tan 
>> >> ---
>> >> v2: change to check PCIe type is PCI_EXP_TYPE_ROOT_PORT
>> >> ---
>> >>  drivers/pci/host/pcie-altera.c | 3 +++
>> >>  1 file changed, 3 insertions(+)
>> >>
>> >> diff --git a/drivers/pci/host/pcie-altera.c 
>> >> b/drivers/pci/host/pcie-altera.c
>> >> index 58eef99..33b6968 100644
>> >> --- a/drivers/pci/host/pcie-altera.c
>> >> +++ b/drivers/pci/host/pcie-altera.c
>> >> @@ -139,6 +139,9 @@ static void altera_pcie_retrain(struct pci_dev *dev)
>> >>   u16 linkcap, linkstat;
>> >>   struct altera_pcie *pcie = dev->bus->sysdata;
>> >>
>> >> + if (pci_pcie_type(dev) != PCI_EXP_TYPE_ROOT_PORT)
>> >> + return;
>> >> +
>> >>   if (!altera_pcie_link_is_up(pcie))
>> >>   return;
>> >
>> > Instead of making this a PCI fixup, can you make an
>> > altera_pcie_host_init() function, call it from altera_pcie_probe(),
>> > and do the link retrain there?  Then you wouldn't need to worry about
>> > whether this is a Root Port or an Endpoint, plus it would make the
>> > altera driver structure more like the other drivers.
>> >
>> > You would call altera_pcie_host_init() before pci_scan_root_bus(), so
>> > you wouldn't have a pci_dev yet, so you wouldn't be able to use
>> > pcie_capability_set_word() to set the PCI_EXP_LNKCTL_RL bit.  But I
>> > assume there's some device-dependent way to access it using
>> > cra_writel()?
>> We can't use cra_write() to set PCI_EXP_LNKCTL_RL bit.
>
> Why not?  I don't mean it has to be cra_write(), but isn't there some
> way you can write that bit before we scan the root bus?  It doesn't
> make sense that we have to scan the bus before we can train the link.
>
> We want to be able to tell the PCI core "all the device-specific root
> complex initialization has been done, here are the config accessors
> you need, please scan for devices."  I want to keep device-specific
> things like this quirk directly in the driver and out of the
> enumeration process.
We don't have internal register bit to trigger link retrain, but need to set
PCI_EXP_LNKCTL_RL bit in Link Control register of PCIe Capabilities Structure.
So, this requires the altera_pcie_cfg_read() and altera_pcie_cfg_write().
I can restructure the altera_pcie_cfg_read() and
altera_pcie_cfg_write() and have
new _altera_pcie_cfg_read() and _altera_pcie_cfg_write() that avoid
the dependency of struct pci_bus. By doing this, we can retrain the link before
pci_scan_root_bus and remove _FIXUP()

Will send new v3 patch, please take a look.

>
>> We can use
>> pci_bus_find_capability() and pci_bus_read_config_word() with struct
>> pci_bus instead.
>> But this only can be called after pci_scan_root_bus().
>
>> Found
>> iproc_pcie_check_link() have similar implementation.
>
> You're right, and I don't like iproc_pcie_check_link() either, for the
> same reasons.
>
> The iproc_pcie_check_link() is a little better because it's called
> before enumeration:
>
>   pci_create_root_bus()
>   iproc_pcie_check_link()
>   pci_scan_child_bus()
>
> But it would be a lot better if iproc_pcie_check_link() were done
> first, before pci_create_root_bus().  Then it would be more like the
> structure of other drivers, and we could use pci_scan_root_bus()
> instead.
>
> Comments, iproc folks?
>
> Bjorn
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 21/34] clk: nspire: Migrate to clk_hw based OF and registration APIs

[Stephen Boyd]

On 06/01, Stephen Boyd wrote:
> Now that we have clk_hw based provider APIs to register clks, we
> can get rid of struct clk pointers while registering clks in
> these drivers, allowing us to move closer to a clear split of
> consumer and provider clk APIs.
> 
> Cc: Daniel Tang 
> Signed-off-by: Stephen Boyd 
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 21/34] clk: nspire: Migrate to clk_hw based OF and registration APIs

[Stephen Boyd]

On 06/01, Stephen Boyd wrote:
> Now that we have clk_hw based provider APIs to register clks, we
> can get rid of struct clk pointers while registering clks in
> these drivers, allowing us to move closer to a clear split of
> consumer and provider clk APIs.
> 
> Cc: Daniel Tang 
> Signed-off-by: Stephen Boyd 
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 06/34] clk: bcm: kona: Migrate to clk_hw based registration and OF APIs

[Stephen Boyd]

On 06/01, Stephen Boyd wrote:
> Now that we can use clk_hw pointers we don't need to have two
> duplicate arrays holding the same mapping of clk index to clk_hw
> pointer. Implement a custom clk_hw provider function to map the
> OF specifier to the clk_hw instance for it.
> 
> Cc: Alex Elder 
> Signed-off-by: Stephen Boyd 
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 2/3] docs: split up the driver book

[Mauro Carvalho Chehab]

Em Wed, 24 Aug 2016 16:46:22 -0600
Jonathan Corbet  escreveu:

> On Tue, 23 Aug 2016 11:30:16 -0300
> Mauro Carvalho Chehab  wrote:
> 
> > On the output text, you'll see two places with "@:c:func:threadfn()".
> > 
> > The problem here is that threadfn() is a function argument. While this
> > used to work with DocBooks, now with Sphinx this is not handled well.
> > 
> > I got some other similar cases on media. There, I opted to just remove
> > the () on some places, or to replace it by \(\) to avoid kernel-doc
> > to do the wrong thing.   
> 
> I have a different idea: why not just add another regexp to the
> kernel-doc house of cards? :) 

Yeah, we can do that, but still we need to check if the references
are being properly solved (e. g. if the parser is doing the right
thing).

Ideally, the regex should also check for the next symbols, as
things like: @foo->bar should be translated to:
:c:type:`foo`\ ->bar

As Sphinx doesn't handle well non-space chars[1] before :c: or after the
grave accent ("`").

[1] Actually, it seems to work fine with a few symbols, like commas
and dots.

> The following seems to make these issues
> go away pretty nicely, and didn't cause any change at all to the
> media/gpu output...
> 
> Stacking up ordering-dependent regexps is not a path to long-term joy; at
> some point, we will likely want a smarter parser for kerneldoc comments.
> But this seems to improve things for the moment.

Good!

> 
> jon
> 
> From 5dccd4fb9f3c0b6468f38efab8c1d6232d3e701b Mon Sep 17 00:00:00 2001
> From: Jonathan Corbet 
> Date: Wed, 24 Aug 2016 16:31:15 -0600
> Subject: [PATCH] docs: Special-case function-pointer parameters in kernel-doc
> 
> Add yet another regex to kernel-doc to trap @param() references separately
> and not produce corrupt RST markup.
> 
> Signed-off-by: Jonathan Corbet 
> ---
>  scripts/kernel-doc | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/scripts/kernel-doc b/scripts/kernel-doc
> index 4f2e9049e8fa..c681e8f0ecc2 100755
> --- a/scripts/kernel-doc
> +++ b/scripts/kernel-doc
> @@ -212,6 +212,7 @@ my $anon_struct_union = 0;
>  my $type_constant = '\%([-_\w]+)';
>  my $type_func = '(\w+)\(\)';
>  my $type_param = '\@(\w+)';
> +my $type_fp_param = '\@(\w+)\(\)';  # Special RST handling for func ptr 
> params
>  my $type_struct = '\&((struct\s*)*[_\w]+)';
>  my $type_struct_xml = '\\((struct\s*)*[_\w]+)';
>  my $type_env = '(\$\w+)';
> @@ -292,6 +293,7 @@ my @highlights_rst = (
> # Note: need to escape () to avoid func matching later
> [$type_member_func, "\\:c\\:type\\:`\$1\$2() 
> <\$1>`"],
> [$type_member, "\\:c\\:type\\:`\$1\$2 <\$1>`"],
> +[$type_fp_param, "**\$1()**"],

Hmm... shoudn't it be a reference to the struct (or to the struct member),
instead of bold?

> [$type_func, "\\:c\\:func\\:`\$1()`"],
> [$type_struct_full, "\\:c\\:type\\:`\$1 \$2 <\$2>`"],
> [$type_enum_full, "\\:c\\:type\\:`\$1 \$2 <\$2>`"],



Thanks,
Mauro

Re: [PATCH 06/34] clk: bcm: kona: Migrate to clk_hw based registration and OF APIs

[Stephen Boyd]

On 06/01, Stephen Boyd wrote:
> Now that we can use clk_hw pointers we don't need to have two
> duplicate arrays holding the same mapping of clk index to clk_hw
> pointer. Implement a custom clk_hw provider function to map the
> OF specifier to the clk_hw instance for it.
> 
> Cc: Alex Elder 
> Signed-off-by: Stephen Boyd 
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 2/3] docs: split up the driver book

[Mauro Carvalho Chehab]

Em Wed, 24 Aug 2016 16:46:22 -0600
Jonathan Corbet  escreveu:

> On Tue, 23 Aug 2016 11:30:16 -0300
> Mauro Carvalho Chehab  wrote:
> 
> > On the output text, you'll see two places with "@:c:func:threadfn()".
> > 
> > The problem here is that threadfn() is a function argument. While this
> > used to work with DocBooks, now with Sphinx this is not handled well.
> > 
> > I got some other similar cases on media. There, I opted to just remove
> > the () on some places, or to replace it by \(\) to avoid kernel-doc
> > to do the wrong thing.   
> 
> I have a different idea: why not just add another regexp to the
> kernel-doc house of cards? :) 

Yeah, we can do that, but still we need to check if the references
are being properly solved (e. g. if the parser is doing the right
thing).

Ideally, the regex should also check for the next symbols, as
things like: @foo->bar should be translated to:
:c:type:`foo`\ ->bar

As Sphinx doesn't handle well non-space chars[1] before :c: or after the
grave accent ("`").

[1] Actually, it seems to work fine with a few symbols, like commas
and dots.

> The following seems to make these issues
> go away pretty nicely, and didn't cause any change at all to the
> media/gpu output...
> 
> Stacking up ordering-dependent regexps is not a path to long-term joy; at
> some point, we will likely want a smarter parser for kerneldoc comments.
> But this seems to improve things for the moment.

Good!

> 
> jon
> 
> From 5dccd4fb9f3c0b6468f38efab8c1d6232d3e701b Mon Sep 17 00:00:00 2001
> From: Jonathan Corbet 
> Date: Wed, 24 Aug 2016 16:31:15 -0600
> Subject: [PATCH] docs: Special-case function-pointer parameters in kernel-doc
> 
> Add yet another regex to kernel-doc to trap @param() references separately
> and not produce corrupt RST markup.
> 
> Signed-off-by: Jonathan Corbet 
> ---
>  scripts/kernel-doc | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/scripts/kernel-doc b/scripts/kernel-doc
> index 4f2e9049e8fa..c681e8f0ecc2 100755
> --- a/scripts/kernel-doc
> +++ b/scripts/kernel-doc
> @@ -212,6 +212,7 @@ my $anon_struct_union = 0;
>  my $type_constant = '\%([-_\w]+)';
>  my $type_func = '(\w+)\(\)';
>  my $type_param = '\@(\w+)';
> +my $type_fp_param = '\@(\w+)\(\)';  # Special RST handling for func ptr 
> params
>  my $type_struct = '\&((struct\s*)*[_\w]+)';
>  my $type_struct_xml = '\\((struct\s*)*[_\w]+)';
>  my $type_env = '(\$\w+)';
> @@ -292,6 +293,7 @@ my @highlights_rst = (
> # Note: need to escape () to avoid func matching later
> [$type_member_func, "\\:c\\:type\\:`\$1\$2() 
> <\$1>`"],
> [$type_member, "\\:c\\:type\\:`\$1\$2 <\$1>`"],
> +[$type_fp_param, "**\$1()**"],

Hmm... shoudn't it be a reference to the struct (or to the struct member),
instead of bold?

> [$type_func, "\\:c\\:func\\:`\$1()`"],
> [$type_struct_full, "\\:c\\:type\\:`\$1 \$2 <\$2>`"],
> [$type_enum_full, "\\:c\\:type\\:`\$1 \$2 <\$2>`"],



Thanks,
Mauro

Re: [PATCH v2] clk: qcom: Migrate to clk_hw based registration and OF APIs

[Stephen Boyd]

On 08/16, Stephen Boyd wrote:
> Now that we have clk_hw based provider APIs to register clks, we
> can get rid of struct clk pointers in this driver, allowing us to
> move closer to a clear split of consumer and provider clk APIs.
> 
> Signed-off-by: Stephen Boyd 
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v2] clk: qcom: Migrate to clk_hw based registration and OF APIs

[Stephen Boyd]

On 08/16, Stephen Boyd wrote:
> Now that we have clk_hw based provider APIs to register clks, we
> can get rid of struct clk pointers in this driver, allowing us to
> move closer to a clear split of consumer and provider clk APIs.
> 
> Signed-off-by: Stephen Boyd 
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: linux-next: Tree for Aug 25

[Stephen Rothwell]

Hi all,

On Thu, 25 Aug 2016 14:54:59 +1000 Stephen Rothwell <s...@canb.auug.org.au> 
wrote:
>
> Changes since 20160824:

Just a reminder that I will not doing a linux-next release until
next-20160905 (i.e. Monday week my time).

-- 
Cheers,
Stephen Rothwell

Re: linux-next: Tree for Aug 25

[Stephen Rothwell]

Hi all,

On Thu, 25 Aug 2016 14:54:59 +1000 Stephen Rothwell  
wrote:
>
> Changes since 20160824:

Just a reminder that I will not doing a linux-next release until
next-20160905 (i.e. Monday week my time).

-- 
Cheers,
Stephen Rothwell

Re: [PATCH v2 0/3] *** Latency histograms - IRQSOFF,PREEMPTOFF ***

[Daniel Wagner]

Hi Binoy,

On 08/24/2016 01:17 PM, Binoy Jayan wrote:

Histogram output:
cat /sys/kernel/debug/tracing/events/latency/latency_irqs/hist
cat /sys/kernel/debug/tracing/events/latency/latency_preempt/hist
cat /sys/kernel/debug/tracing/events/latency/latency_critical_timings/hist
cat /sys/kernel/debug/tracing/events/latency/latency_hrtimer_interrupt/hist


[...]


Changes from v1 as per comments from Steven/Daniel
  - Use single tracepoint for irq/preempt/critical timings by introducing
a trace type field to differentiate trace type in the same tracepoint.


Did you send out the right patches? This version still looks like the 
previous one in this regard. And wouldn't be the 'Histogram output' have 
only one file? Maybe I just understood something wrong here.


cheers,
daniel

Re: [PATCH v2 0/3] *** Latency histograms - IRQSOFF,PREEMPTOFF ***

[Daniel Wagner]

Hi Binoy,

On 08/24/2016 01:17 PM, Binoy Jayan wrote:

Histogram output:
cat /sys/kernel/debug/tracing/events/latency/latency_irqs/hist
cat /sys/kernel/debug/tracing/events/latency/latency_preempt/hist
cat /sys/kernel/debug/tracing/events/latency/latency_critical_timings/hist
cat /sys/kernel/debug/tracing/events/latency/latency_hrtimer_interrupt/hist


[...]


Changes from v1 as per comments from Steven/Daniel
  - Use single tracepoint for irq/preempt/critical timings by introducing
a trace type field to differentiate trace type in the same tracepoint.


Did you send out the right patches? This version still looks like the 
previous one in this regard. And wouldn't be the 'Histogram output' have 
only one file? Maybe I just understood something wrong here.


cheers,
daniel

Re: [RESEND PATCH v2 02/13] drivers: clk: st: Simplify clock binding of STiH4xx platforms

[Michael Turquette]

Quoting Gabriel Fernandez (2016-08-22 09:06:20)
> Hi Mike,
> 
> you forgot me ?
> 
> Best Regards
> 
> Gabriel
> 
> 
> On 07/11/2016 08:58 AM, Gabriel Fernandez wrote:
> >
> >
> > On 07/08/2016 06:08 PM, Michael Turquette wrote:
> >> Quoting Gabriel Fernandez (2016-07-08 02:12:35)
> >>> Hi Mike,
> >>>
> >>> On 07/08/2016 03:43 AM, Michael Turquette wrote:
>  Quoting Rob Herring (2016-06-19 08:04:58)
> > On Thu, Jun 16, 2016 at 11:20:22AM +0200, Gabriel Fernandez wrote:
> >> This patch reworks the clock binding to avoid too much detail in DT.
> >> Now we have only compatible string per type of clock
> >> (remark from Rob https://lkml.org/lkml/2016/5/25/492)
> >>
> > I have no idea what the clock trees and clock controller in these 
> > chips
> > look like, so it's hard to say if the changes here are good. It still
> > looks like things are somewhat fine grained clocks in DT. I'll leave
> > it up to the platform maintainers to decide...
>  Is this series breaking ABI? If yes, why not do what Maxime did for 
>  the
>  Allwinner/sunxi clocks and just fully convert over to a
>  one-node-per-clock-controller binding? This one-node-per-clock 
>  stuff is
>  pretty unfortunate, and if we're deprecating platforms (patch #1) then
>  now might be a good time to re-evaluate the whole thing.
> >>> The goal of my patchset was to be aligned with DRM / KMS development 
> >>> and
> >>> to offer
> >>> the possibility to make a correct video playback on STiH407/STiH410
> >>> platform.
> >>> Our milestone is the 4.8 for that.
> >>>
> >>> Currently people need these patches to work.
> >>> I'm not sure it's a good time to re-evaluate the whole thing.
> >>>
> >>> Is it possible to re-evaluate later ?
> >> Are you OK to break ABI later? Or at a minimum, deprecate the current
> >> binding (maintain it forever for legacy platforms) and create a new
> >> clock controller binding description that supersedes the legacy binding
> >> for all new platforms?
> >>
> >> If the answer to either question is "yes", then I'm OK to put it aside
> >> for now. But if the answer to both is "no", and this patch series is
> >> breaking ABI, then we really should fix it now.
> >
> > Hi Mike,
> > i m ok to break ABI later.

Hi Gabriel,

This change never received any other reviews, and no pings before v4.7
was released. Sorry that it fell through the cracks, but always feel
free to re-ping leading up to the merge window.

Can you rebase this against -rc1? Also, do you have a plan to rework the
binding to move away from the one-node-per-clock style?

Regards,
Mike

> >
> > Many Thanks !
> >
> > Best Regards
> >
> > Gabriel.
> >
> >> Regards,
> >> Mike
> >>
> >>> Best regards,
> >>> Gabriel
> >>>
>  Regards,
>  Mike
> 
> >> Signed-off-by: Gabriel Fernandez 
> >> ---
> >>.../devicetree/bindings/clock/st/st,clkgen-mux.txt | 2 +-
> >>.../devicetree/bindings/clock/st/st,clkgen-pll.txt | 11 ++--
> >>.../devicetree/bindings/clock/st/st,clkgen.txt | 2 +-
> >>.../devicetree/bindings/clock/st/st,quadfs.txt | 6 +--
> >>drivers/clk/st/clkgen-fsyn.c   | 41 
> >> ++
> >>drivers/clk/st/clkgen-mux.c| 28 
> >> --
> >>drivers/clk/st/clkgen-pll.c| 62 
> >> ++
> >>7 files changed, 65 insertions(+), 87 deletions(-)
> >>
> >> diff --git 
> >> a/Documentation/devicetree/bindings/clock/st/st,clkgen-mux.txt 
> >> b/Documentation/devicetree/bindings/clock/st/st,clkgen-mux.txt
> >> index 4d277d6..9a46cb1d7 100644
> >> --- a/Documentation/devicetree/bindings/clock/st/st,clkgen-mux.txt
> >> +++ b/Documentation/devicetree/bindings/clock/st/st,clkgen-mux.txt
> >> @@ -10,7 +10,7 @@ This binding uses the common clock binding[1].
> >>Required properties:
> >>   - compatible : shall be:
> >> - "st,stih407-clkgen-a9-mux", "st,clkgen-mux"
> >> + "st,stih407-clkgen-a9-mux"
> >>   - #clock-cells : from common clock binding; shall be set to 0.
> >>diff --git 
> >> a/Documentation/devicetree/bindings/clock/st/st,clkgen-pll.txt 
> >> b/Documentation/devicetree/bindings/clock/st/st,clkgen-pll.txt
> >> index c9fd674..be0b043 100644
> >> --- a/Documentation/devicetree/bindings/clock/st/st,clkgen-pll.txt
> >> +++ b/Documentation/devicetree/bindings/clock/st/st,clkgen-pll.txt
> >> @@ -9,11 +9,10 @@ Base address is located to the parent node. See 
> >> clock binding[2]
> >>Required properties:
> >>   - compatible : shall be:
> >> - "st,stih407-plls-c32-a0", "st,clkgen-plls-c32"
> >> - "st,stih407-plls-c32-a9", "st,clkgen-plls-c32"
> >> - "sst,plls-c32-cx_0", "st,clkgen-plls-c32"
> >> - "sst,plls-c32-cx_1", "st,clkgen-plls-c32"
> 

Re: [RESEND PATCH v2 02/13] drivers: clk: st: Simplify clock binding of STiH4xx platforms

[Michael Turquette]

Quoting Gabriel Fernandez (2016-08-22 09:06:20)
> Hi Mike,
> 
> you forgot me ?
> 
> Best Regards
> 
> Gabriel
> 
> 
> On 07/11/2016 08:58 AM, Gabriel Fernandez wrote:
> >
> >
> > On 07/08/2016 06:08 PM, Michael Turquette wrote:
> >> Quoting Gabriel Fernandez (2016-07-08 02:12:35)
> >>> Hi Mike,
> >>>
> >>> On 07/08/2016 03:43 AM, Michael Turquette wrote:
>  Quoting Rob Herring (2016-06-19 08:04:58)
> > On Thu, Jun 16, 2016 at 11:20:22AM +0200, Gabriel Fernandez wrote:
> >> This patch reworks the clock binding to avoid too much detail in DT.
> >> Now we have only compatible string per type of clock
> >> (remark from Rob https://lkml.org/lkml/2016/5/25/492)
> >>
> > I have no idea what the clock trees and clock controller in these 
> > chips
> > look like, so it's hard to say if the changes here are good. It still
> > looks like things are somewhat fine grained clocks in DT. I'll leave
> > it up to the platform maintainers to decide...
>  Is this series breaking ABI? If yes, why not do what Maxime did for 
>  the
>  Allwinner/sunxi clocks and just fully convert over to a
>  one-node-per-clock-controller binding? This one-node-per-clock 
>  stuff is
>  pretty unfortunate, and if we're deprecating platforms (patch #1) then
>  now might be a good time to re-evaluate the whole thing.
> >>> The goal of my patchset was to be aligned with DRM / KMS development 
> >>> and
> >>> to offer
> >>> the possibility to make a correct video playback on STiH407/STiH410
> >>> platform.
> >>> Our milestone is the 4.8 for that.
> >>>
> >>> Currently people need these patches to work.
> >>> I'm not sure it's a good time to re-evaluate the whole thing.
> >>>
> >>> Is it possible to re-evaluate later ?
> >> Are you OK to break ABI later? Or at a minimum, deprecate the current
> >> binding (maintain it forever for legacy platforms) and create a new
> >> clock controller binding description that supersedes the legacy binding
> >> for all new platforms?
> >>
> >> If the answer to either question is "yes", then I'm OK to put it aside
> >> for now. But if the answer to both is "no", and this patch series is
> >> breaking ABI, then we really should fix it now.
> >
> > Hi Mike,
> > i m ok to break ABI later.

Hi Gabriel,

This change never received any other reviews, and no pings before v4.7
was released. Sorry that it fell through the cracks, but always feel
free to re-ping leading up to the merge window.

Can you rebase this against -rc1? Also, do you have a plan to rework the
binding to move away from the one-node-per-clock style?

Regards,
Mike

> >
> > Many Thanks !
> >
> > Best Regards
> >
> > Gabriel.
> >
> >> Regards,
> >> Mike
> >>
> >>> Best regards,
> >>> Gabriel
> >>>
>  Regards,
>  Mike
> 
> >> Signed-off-by: Gabriel Fernandez 
> >> ---
> >>.../devicetree/bindings/clock/st/st,clkgen-mux.txt | 2 +-
> >>.../devicetree/bindings/clock/st/st,clkgen-pll.txt | 11 ++--
> >>.../devicetree/bindings/clock/st/st,clkgen.txt | 2 +-
> >>.../devicetree/bindings/clock/st/st,quadfs.txt | 6 +--
> >>drivers/clk/st/clkgen-fsyn.c   | 41 
> >> ++
> >>drivers/clk/st/clkgen-mux.c| 28 
> >> --
> >>drivers/clk/st/clkgen-pll.c| 62 
> >> ++
> >>7 files changed, 65 insertions(+), 87 deletions(-)
> >>
> >> diff --git 
> >> a/Documentation/devicetree/bindings/clock/st/st,clkgen-mux.txt 
> >> b/Documentation/devicetree/bindings/clock/st/st,clkgen-mux.txt
> >> index 4d277d6..9a46cb1d7 100644
> >> --- a/Documentation/devicetree/bindings/clock/st/st,clkgen-mux.txt
> >> +++ b/Documentation/devicetree/bindings/clock/st/st,clkgen-mux.txt
> >> @@ -10,7 +10,7 @@ This binding uses the common clock binding[1].
> >>Required properties:
> >>   - compatible : shall be:
> >> - "st,stih407-clkgen-a9-mux", "st,clkgen-mux"
> >> + "st,stih407-clkgen-a9-mux"
> >>   - #clock-cells : from common clock binding; shall be set to 0.
> >>diff --git 
> >> a/Documentation/devicetree/bindings/clock/st/st,clkgen-pll.txt 
> >> b/Documentation/devicetree/bindings/clock/st/st,clkgen-pll.txt
> >> index c9fd674..be0b043 100644
> >> --- a/Documentation/devicetree/bindings/clock/st/st,clkgen-pll.txt
> >> +++ b/Documentation/devicetree/bindings/clock/st/st,clkgen-pll.txt
> >> @@ -9,11 +9,10 @@ Base address is located to the parent node. See 
> >> clock binding[2]
> >>Required properties:
> >>   - compatible : shall be:
> >> - "st,stih407-plls-c32-a0", "st,clkgen-plls-c32"
> >> - "st,stih407-plls-c32-a9", "st,clkgen-plls-c32"
> >> - "sst,plls-c32-cx_0", "st,clkgen-plls-c32"
> >> - "sst,plls-c32-cx_1", "st,clkgen-plls-c32"
> >> - 

Re: [PATCH 33/34] clk: vt8500: Migrate to clk_hw based registration APIs

[Stephen Boyd]

On 06/01, Stephen Boyd wrote:
> Now that we have clk_hw based provider APIs to register clks, we
> can get rid of struct clk pointers while registering clks in
> these drivers, allowing us to move closer to a clear split of
> consumer and provider clk APIs.
> 
> Cc: Sebastian Hesselbarth 
> Cc: Tony Prisk 
> Signed-off-by: Stephen Boyd 
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 34/34] clk: wm831x: Migrate to clk_hw based registration APIs

[Stephen Boyd]

On 06/01, Stephen Boyd wrote:
> Now that we have clk_hw based provider APIs to register clks, we
> can get rid of struct clk pointers while registering clks in
> these drivers, allowing us to move closer to a clear split of
> consumer and provider clk APIs.
> 
> Cc: Mark Brown 
> Signed-off-by: Stephen Boyd 
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 33/34] clk: vt8500: Migrate to clk_hw based registration APIs

[Stephen Boyd]

On 06/01, Stephen Boyd wrote:
> Now that we have clk_hw based provider APIs to register clks, we
> can get rid of struct clk pointers while registering clks in
> these drivers, allowing us to move closer to a clear split of
> consumer and provider clk APIs.
> 
> Cc: Sebastian Hesselbarth 
> Cc: Tony Prisk 
> Signed-off-by: Stephen Boyd 
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 34/34] clk: wm831x: Migrate to clk_hw based registration APIs

[Stephen Boyd]

On 06/01, Stephen Boyd wrote:
> Now that we have clk_hw based provider APIs to register clks, we
> can get rid of struct clk pointers while registering clks in
> these drivers, allowing us to move closer to a clear split of
> consumer and provider clk APIs.
> 
> Cc: Mark Brown 
> Signed-off-by: Stephen Boyd 
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH] PCI: Export pci_enable_ptm

[Yong, Jonathan]

Export symbol so device drivers outside of the core pci subsystem
can use it.

Signed-off-by: Yong, Jonathan 
---
 drivers/pci/pcie/ptm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/pci/pcie/ptm.c b/drivers/pci/pcie/ptm.c
index 3b83024..bab8ac6 100644
--- a/drivers/pci/pcie/ptm.c
+++ b/drivers/pci/pcie/ptm.c
@@ -139,3 +139,4 @@ int pci_enable_ptm(struct pci_dev *dev, u8 *granularity)
*granularity = dev->ptm_granularity;
return 0;
 }
+EXPORT_SYMBOL(pci_enable_ptm);
-- 
2.7.3

[PATCH] Allow pci_enable_ptm to be called outside of the pci subsystem

[Yong, Jonathan]

Allow external drivers to enable PTM bits on their respective devices.
Please CC me when replying, thanks.

Yong, Jonathan (1):
  PCI: Export pci_enable_ptm

 drivers/pci/pcie/ptm.c | 1 +
 1 file changed, 1 insertion(+)

-- 
2.7.3

[PATCH] PCI: Export pci_enable_ptm

[Yong, Jonathan]

Export symbol so device drivers outside of the core pci subsystem
can use it.

Signed-off-by: Yong, Jonathan 
---
 drivers/pci/pcie/ptm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/pci/pcie/ptm.c b/drivers/pci/pcie/ptm.c
index 3b83024..bab8ac6 100644
--- a/drivers/pci/pcie/ptm.c
+++ b/drivers/pci/pcie/ptm.c
@@ -139,3 +139,4 @@ int pci_enable_ptm(struct pci_dev *dev, u8 *granularity)
*granularity = dev->ptm_granularity;
return 0;
 }
+EXPORT_SYMBOL(pci_enable_ptm);
-- 
2.7.3

[PATCH] Allow pci_enable_ptm to be called outside of the pci subsystem

[Yong, Jonathan]

Allow external drivers to enable PTM bits on their respective devices.
Please CC me when replying, thanks.

Yong, Jonathan (1):
  PCI: Export pci_enable_ptm

 drivers/pci/pcie/ptm.c | 1 +
 1 file changed, 1 insertion(+)

-- 
2.7.3

Re: [PATCH 29/34] clk: si570: Migrate to clk_hw based OF and registration APIs

[Stephen Boyd]

On 06/01, Stephen Boyd wrote:
> Now that we have clk_hw based provider APIs to register clks, we
> can get rid of struct clk pointers while registering clks in
> these drivers, allowing us to move closer to a clear split of
> consumer and provider clk APIs.
> 
> Cc: Guenter Roeck 
> Cc: Sören Brinkmann 
> Signed-off-by: Stephen Boyd 
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH V3] leds: trigger: Introduce an USB port trigger

[Rafał Miłecki]

On 24 August 2016 at 23:04, Greg KH  wrote:
> On Wed, Aug 24, 2016 at 11:29:51AM +0200, Rafał Miłecki wrote:
>> On 24 August 2016 at 11:22, Greg KH  wrote:
>> > On Wed, Aug 24, 2016 at 12:03:29AM +0200, Rafał Miłecki wrote:
>> >> +static ssize_t ports_show(struct device *dev, struct device_attribute 
>> >> *attr,
>> >> +   char *buf)
>> >> +{
>> >> + struct led_classdev *led_cdev = dev_get_drvdata(dev);
>> >> + struct usbport_trig_data *usbport_data = led_cdev->trigger_data;
>> >> + struct usbport_trig_port *port;
>> >> + ssize_t ret = 0;
>> >> + int len;
>> >> +
>> >> + list_for_each_entry(port, _data->ports, list) {
>> >> + len = sprintf(buf + ret, "%s\n", port->name);
>> >> + if (len >= 0)
>> >> + ret += len;
>> >> + }
>> >> +
>> >> + return ret;
>> >> +}
>> >
>> > sysfs is "one value per file", here you are listing a bunch of things in
>> > one sysfs file.  Please don't do that.
>>
>> OK. What do you think about creating "ports" subdirectory and creating
>> file-per-port in it? Then I'd need to bring back something like
>> "new_port" and "remove_port". Does it sound OK?
>
> Maybe, I don't know.  Why is "USB" somehow unique here?  Why isn't this
> the same for PCI slots/ports?  pccard?  sdcard?  thunderbolt?

Good question. I would like to extend this USB port trigger in the
future by reacting to USB activity. This involves playing with URBs
and I believe that at that point it'd be getting too much USB specific
to /rule them all/.

-- 
Rafał

Re: [PATCH 27/34] clk: si514: Migrate to clk_hw based OF and registration APIs

[Stephen Boyd]

On 06/01, Stephen Boyd wrote:
> Now that we have clk_hw based provider APIs to register clks, we
> can get rid of struct clk pointers while registering clks in
> these drivers, allowing us to move closer to a clear split of
> consumer and provider clk APIs.
> 
> Cc: Sebastian Hesselbarth 
> Cc: Guenter Roeck 
> Cc: Sören Brinkmann 
> Cc: Mike Looijmans 
> Signed-off-by: Stephen Boyd 
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 26/34] clk: scpi: Migrate to clk_hw based OF and registration APIs

[Stephen Boyd]

On 06/01, Stephen Boyd wrote:
> Now that we have clk_hw based provider APIs to register clks, we
> can get rid of struct clk pointers while registering clks in
> these drivers, allowing us to move closer to a clear split of
> consumer and provider clk APIs.
> 
> Cc: Sudeep Holla 
> Signed-off-by: Stephen Boyd 
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 29/34] clk: si570: Migrate to clk_hw based OF and registration APIs

[Stephen Boyd]

On 06/01, Stephen Boyd wrote:
> Now that we have clk_hw based provider APIs to register clks, we
> can get rid of struct clk pointers while registering clks in
> these drivers, allowing us to move closer to a clear split of
> consumer and provider clk APIs.
> 
> Cc: Guenter Roeck 
> Cc: Sören Brinkmann 
> Signed-off-by: Stephen Boyd 
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH V3] leds: trigger: Introduce an USB port trigger

[Rafał Miłecki]

On 24 August 2016 at 23:04, Greg KH  wrote:
> On Wed, Aug 24, 2016 at 11:29:51AM +0200, Rafał Miłecki wrote:
>> On 24 August 2016 at 11:22, Greg KH  wrote:
>> > On Wed, Aug 24, 2016 at 12:03:29AM +0200, Rafał Miłecki wrote:
>> >> +static ssize_t ports_show(struct device *dev, struct device_attribute 
>> >> *attr,
>> >> +   char *buf)
>> >> +{
>> >> + struct led_classdev *led_cdev = dev_get_drvdata(dev);
>> >> + struct usbport_trig_data *usbport_data = led_cdev->trigger_data;
>> >> + struct usbport_trig_port *port;
>> >> + ssize_t ret = 0;
>> >> + int len;
>> >> +
>> >> + list_for_each_entry(port, _data->ports, list) {
>> >> + len = sprintf(buf + ret, "%s\n", port->name);
>> >> + if (len >= 0)
>> >> + ret += len;
>> >> + }
>> >> +
>> >> + return ret;
>> >> +}
>> >
>> > sysfs is "one value per file", here you are listing a bunch of things in
>> > one sysfs file.  Please don't do that.
>>
>> OK. What do you think about creating "ports" subdirectory and creating
>> file-per-port in it? Then I'd need to bring back something like
>> "new_port" and "remove_port". Does it sound OK?
>
> Maybe, I don't know.  Why is "USB" somehow unique here?  Why isn't this
> the same for PCI slots/ports?  pccard?  sdcard?  thunderbolt?

Good question. I would like to extend this USB port trigger in the
future by reacting to USB activity. This involves playing with URBs
and I believe that at that point it'd be getting too much USB specific
to /rule them all/.

-- 
Rafał

Re: [PATCH 27/34] clk: si514: Migrate to clk_hw based OF and registration APIs

[Stephen Boyd]

On 06/01, Stephen Boyd wrote:
> Now that we have clk_hw based provider APIs to register clks, we
> can get rid of struct clk pointers while registering clks in
> these drivers, allowing us to move closer to a clear split of
> consumer and provider clk APIs.
> 
> Cc: Sebastian Hesselbarth 
> Cc: Guenter Roeck 
> Cc: Sören Brinkmann 
> Cc: Mike Looijmans 
> Signed-off-by: Stephen Boyd 
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 26/34] clk: scpi: Migrate to clk_hw based OF and registration APIs

[Stephen Boyd]

On 06/01, Stephen Boyd wrote:
> Now that we have clk_hw based provider APIs to register clks, we
> can get rid of struct clk pointers while registering clks in
> these drivers, allowing us to move closer to a clear split of
> consumer and provider clk APIs.
> 
> Cc: Sudeep Holla 
> Signed-off-by: Stephen Boyd 
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 24/34] clk: rk808: Migrate to clk_hw based OF and registration APIs

[Stephen Boyd]

On 06/01, Stephen Boyd wrote:
> Now that we have clk_hw based provider APIs to register clks, we
> can get rid of struct clk pointers while registering clks in
> these drivers, allowing us to move closer to a clear split of
> consumer and provider clk APIs.
> 
> Cc: Chris Zhong 
> Signed-off-by: Stephen Boyd 
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 24/34] clk: rk808: Migrate to clk_hw based OF and registration APIs

[Stephen Boyd]

On 06/01, Stephen Boyd wrote:
> Now that we have clk_hw based provider APIs to register clks, we
> can get rid of struct clk pointers while registering clks in
> these drivers, allowing us to move closer to a clear split of
> consumer and provider clk APIs.
> 
> Cc: Chris Zhong 
> Signed-off-by: Stephen Boyd 
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 28/34] clk: si5351: Migrate to clk_hw based OF and registration APIs

[Stephen Boyd]

On 06/01, Stephen Boyd wrote:
> Now that we have clk_hw based provider APIs to register clks, we
> can get rid of struct clk pointers while registering clks in
> these drivers, allowing us to move closer to a clear split of
> consumer and provider clk APIs.
> 
> Cc: Sebastian Hesselbarth 
> Cc: Guenter Roeck 
> Cc: Sören Brinkmann 
> Cc: Mike Looijmans 
> Signed-off-by: Stephen Boyd 
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

linux-next: build warning after merge of the crypto tree

[Stephen Rothwell]

Hi Herbert,

After merging the crypto tree, today's linux-next build (powerpc
ppc64_defconfig) produced this warning:

crypto/xor.c: In function 'calibrate_xor_blocks':
crypto/xor.c:156:1: warning: label 'out' defined but not used [-Wunused-label]
 out:
 ^

Introduced by commit

  39457acda913 ("crypto: xor - skip speed test if the xor function is selected 
automatically")

This build does not have XOR_SELECT_TEMPLATE set.

-- 
Cheers,
Stephen Rothwell

Re: [PATCH] kexec: Fix double-free when failing to relocate the purgatory.

[Baoquan He]

It's reasonable. Ack.

Acked-by: Baoquan He 

On 08/24/16 at 09:05pm, Thiago Jung Bauermann wrote:
> If kexec_apply_relocations fails, kexec_load_purgatory frees pi->sechdrs
> and pi->purgatory_buf. This is redundant, because in case of error
> kimage_file_prepare_segments calls kimage_file_post_load_cleanup,
> which will also free those buffers.
> 
> This causes two warnings like the following, one for pi->sechdrs and the
> other for pi->purgatory_buf:
> 
> [   18.112843] kexec-bzImage64: Loading purgatory failed
> [   18.113257] [ cut here ]
> [   18.113263] WARNING: CPU: 1 PID: 2119 at mm/vmalloc.c:1490 
> __vunmap+0xc1/0xd0
> [   18.113264] Trying to vfree() nonexistent vm area (c9e91000)
> [   18.113367] Modules linked in:
> [   18.113371] CPU: 1 PID: 2119 Comm: kexec Not tainted 4.8.0-rc3+ #5
> [   18.113372] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
> Bochs 01/01/2011
> [   18.113373]   88003bbb7dc8 8132eca8 
> 88003bbb7e18
> [   18.113376]   88003bbb7e08 8105f1bb 
> 05d281175bf8
> [   18.113377]  c9e91000  0001 
> 88003e5f8c00
> [   18.113379] Call Trace:
> [   18.113384]  [] dump_stack+0x4d/0x65
> [   18.113386]  [] __warn+0xcb/0xf0
> [   18.113388]  [] warn_slowpath_fmt+0x4f/0x60
> [   18.113390]  [] ? find_vmap_area+0x19/0x70
> [   18.113393]  [] ? kimage_file_post_load_cleanup+0x47/0xb0
> [   18.113394]  [] __vunmap+0xc1/0xd0
> [   18.113396]  [] vfree+0x2e/0x70
> [   18.113397]  [] kimage_file_post_load_cleanup+0x5e/0xb0
> [   18.113398]  [] SyS_kexec_file_load+0x448/0x680
> [   18.113401]  [] ? putname+0x54/0x60
> [   18.113403]  [] ? do_sys_open+0x190/0x1f0
> [   18.113407]  [] entry_SYSCALL_64_fastpath+0x13/0x8f
> [   18.113408] ---[ end trace 158bb74f5950ca2b ]---
> 
> Fix by setting pi->sechdrs an pi->purgatory_buf to NULL, since vfree
> won't try to free a NULL pointer.
> 
> Signed-off-by: Thiago Jung Bauermann 
> ---
>  kernel/kexec_file.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
> index 503bc2d348e5..037c321c5618 100644
> --- a/kernel/kexec_file.c
> +++ b/kernel/kexec_file.c
> @@ -887,7 +887,10 @@ int kexec_load_purgatory(struct kimage *image, unsigned 
> long min,
>   return 0;
>  out:
>   vfree(pi->sechdrs);
> + pi->sechdrs = NULL;
> +
>   vfree(pi->purgatory_buf);
> + pi->purgatory_buf = NULL;
>   return ret;
>  }
>  
> -- 
> 1.9.1
> 
> 
> ___
> kexec mailing list
> ke...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH 28/34] clk: si5351: Migrate to clk_hw based OF and registration APIs

[Stephen Boyd]

On 06/01, Stephen Boyd wrote:
> Now that we have clk_hw based provider APIs to register clks, we
> can get rid of struct clk pointers while registering clks in
> these drivers, allowing us to move closer to a clear split of
> consumer and provider clk APIs.
> 
> Cc: Sebastian Hesselbarth 
> Cc: Guenter Roeck 
> Cc: Sören Brinkmann 
> Cc: Mike Looijmans 
> Signed-off-by: Stephen Boyd 
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

linux-next: build warning after merge of the crypto tree

[Stephen Rothwell]

Hi Herbert,

After merging the crypto tree, today's linux-next build (powerpc
ppc64_defconfig) produced this warning:

crypto/xor.c: In function 'calibrate_xor_blocks':
crypto/xor.c:156:1: warning: label 'out' defined but not used [-Wunused-label]
 out:
 ^

Introduced by commit

  39457acda913 ("crypto: xor - skip speed test if the xor function is selected 
automatically")

This build does not have XOR_SELECT_TEMPLATE set.

-- 
Cheers,
Stephen Rothwell

Re: [PATCH] kexec: Fix double-free when failing to relocate the purgatory.

[Baoquan He]

It's reasonable. Ack.

Acked-by: Baoquan He 

On 08/24/16 at 09:05pm, Thiago Jung Bauermann wrote:
> If kexec_apply_relocations fails, kexec_load_purgatory frees pi->sechdrs
> and pi->purgatory_buf. This is redundant, because in case of error
> kimage_file_prepare_segments calls kimage_file_post_load_cleanup,
> which will also free those buffers.
> 
> This causes two warnings like the following, one for pi->sechdrs and the
> other for pi->purgatory_buf:
> 
> [   18.112843] kexec-bzImage64: Loading purgatory failed
> [   18.113257] [ cut here ]
> [   18.113263] WARNING: CPU: 1 PID: 2119 at mm/vmalloc.c:1490 
> __vunmap+0xc1/0xd0
> [   18.113264] Trying to vfree() nonexistent vm area (c9e91000)
> [   18.113367] Modules linked in:
> [   18.113371] CPU: 1 PID: 2119 Comm: kexec Not tainted 4.8.0-rc3+ #5
> [   18.113372] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
> Bochs 01/01/2011
> [   18.113373]   88003bbb7dc8 8132eca8 
> 88003bbb7e18
> [   18.113376]   88003bbb7e08 8105f1bb 
> 05d281175bf8
> [   18.113377]  c9e91000  0001 
> 88003e5f8c00
> [   18.113379] Call Trace:
> [   18.113384]  [] dump_stack+0x4d/0x65
> [   18.113386]  [] __warn+0xcb/0xf0
> [   18.113388]  [] warn_slowpath_fmt+0x4f/0x60
> [   18.113390]  [] ? find_vmap_area+0x19/0x70
> [   18.113393]  [] ? kimage_file_post_load_cleanup+0x47/0xb0
> [   18.113394]  [] __vunmap+0xc1/0xd0
> [   18.113396]  [] vfree+0x2e/0x70
> [   18.113397]  [] kimage_file_post_load_cleanup+0x5e/0xb0
> [   18.113398]  [] SyS_kexec_file_load+0x448/0x680
> [   18.113401]  [] ? putname+0x54/0x60
> [   18.113403]  [] ? do_sys_open+0x190/0x1f0
> [   18.113407]  [] entry_SYSCALL_64_fastpath+0x13/0x8f
> [   18.113408] ---[ end trace 158bb74f5950ca2b ]---
> 
> Fix by setting pi->sechdrs an pi->purgatory_buf to NULL, since vfree
> won't try to free a NULL pointer.
> 
> Signed-off-by: Thiago Jung Bauermann 
> ---
>  kernel/kexec_file.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
> index 503bc2d348e5..037c321c5618 100644
> --- a/kernel/kexec_file.c
> +++ b/kernel/kexec_file.c
> @@ -887,7 +887,10 @@ int kexec_load_purgatory(struct kimage *image, unsigned 
> long min,
>   return 0;
>  out:
>   vfree(pi->sechdrs);
> + pi->sechdrs = NULL;
> +
>   vfree(pi->purgatory_buf);
> + pi->purgatory_buf = NULL;
>   return ret;
>  }
>  
> -- 
> 1.9.1
> 
> 
> ___
> kexec mailing list
> ke...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH 3/4] dt-binding: remoteproc: venus rproc dt binding document

[Bjorn Andersson]

On Wed 24 Aug 08:36 PDT 2016, Stanimir Varbanov wrote:

> Hi Rob,
> 
> On 08/23/2016 08:32 PM, Rob Herring wrote:
> > On Fri, Aug 19, 2016 at 06:53:19PM +0300, Stanimir Varbanov wrote:
> >> Add devicetree binding document for Venus remote processor.
> >>
> >> Signed-off-by: Stanimir Varbanov 
> >> ---
> >>  .../devicetree/bindings/remoteproc/qcom,venus.txt  | 33 
> >> ++
> >>  1 file changed, 33 insertions(+)
> >>  create mode 100644 
> >> Documentation/devicetree/bindings/remoteproc/qcom,venus.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,venus.txt 
> >> b/Documentation/devicetree/bindings/remoteproc/qcom,venus.txt
> >> new file mode 100644
> >> index ..06a2db60fa38
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/remoteproc/qcom,venus.txt
> >> @@ -0,0 +1,33 @@
> >> +Qualcomm Venus Peripheral Image Loader
> >> +
> >> +This document defines the binding for a component that loads and boots 
> >> firmware
> >> +on the Qualcomm Venus remote processor core.
> > 
> > This does not make sense to me. Venus is the video encoder/decoder h/w, 
> > right? Why is the firmware loader separate from the codec block? Why 
> > rproc is used? Are there multiple clients? Naming it rproc_venus implies 
> > there aren't. And why does the firmware loading need 8MB of memory at a 
> > fixed address?
> > 
> 
> The firmware for Venus case is 5MB. And here is 8MB because of
> dma_alloc_from_coherent size restriction.
> 

Then you should specify it 5MB large and we'll have to deal with this
implementation issue in the code. I've created a JIRA ticket for
the dma_alloc_from_coherent() behavior.

> The address is not really fixed, cause the firmware could support
> relocation. In this example I just picked up the next free memory region
> in memory-reserved from msm8916.dtsi.
> 

In 8974 we do have a physical region where it's expected to be loaded.

So in line with upcoming remoteproc work we should support referencing a
reserved-memory node with either reg or size.

In the case of spotting a "reg" we're currently better off using
ioremap. We're looking at getting the remoteproc core to deal with this
mess.


So, on 8916 I think you should use the form:

venus_mem: venus {
size = <0x50>;
};

And I don't think you should use the shared-dma-pool compatible, because
this is not a region for multiple devices to allocate dma memory out of.


Regards,
Bjorn

Re: [PATCH 3/4] dt-binding: remoteproc: venus rproc dt binding document

[Bjorn Andersson]

On Wed 24 Aug 08:36 PDT 2016, Stanimir Varbanov wrote:

> Hi Rob,
> 
> On 08/23/2016 08:32 PM, Rob Herring wrote:
> > On Fri, Aug 19, 2016 at 06:53:19PM +0300, Stanimir Varbanov wrote:
> >> Add devicetree binding document for Venus remote processor.
> >>
> >> Signed-off-by: Stanimir Varbanov 
> >> ---
> >>  .../devicetree/bindings/remoteproc/qcom,venus.txt  | 33 
> >> ++
> >>  1 file changed, 33 insertions(+)
> >>  create mode 100644 
> >> Documentation/devicetree/bindings/remoteproc/qcom,venus.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,venus.txt 
> >> b/Documentation/devicetree/bindings/remoteproc/qcom,venus.txt
> >> new file mode 100644
> >> index ..06a2db60fa38
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/remoteproc/qcom,venus.txt
> >> @@ -0,0 +1,33 @@
> >> +Qualcomm Venus Peripheral Image Loader
> >> +
> >> +This document defines the binding for a component that loads and boots 
> >> firmware
> >> +on the Qualcomm Venus remote processor core.
> > 
> > This does not make sense to me. Venus is the video encoder/decoder h/w, 
> > right? Why is the firmware loader separate from the codec block? Why 
> > rproc is used? Are there multiple clients? Naming it rproc_venus implies 
> > there aren't. And why does the firmware loading need 8MB of memory at a 
> > fixed address?
> > 
> 
> The firmware for Venus case is 5MB. And here is 8MB because of
> dma_alloc_from_coherent size restriction.
> 

Then you should specify it 5MB large and we'll have to deal with this
implementation issue in the code. I've created a JIRA ticket for
the dma_alloc_from_coherent() behavior.

> The address is not really fixed, cause the firmware could support
> relocation. In this example I just picked up the next free memory region
> in memory-reserved from msm8916.dtsi.
> 

In 8974 we do have a physical region where it's expected to be loaded.

So in line with upcoming remoteproc work we should support referencing a
reserved-memory node with either reg or size.

In the case of spotting a "reg" we're currently better off using
ioremap. We're looking at getting the remoteproc core to deal with this
mess.


So, on 8916 I think you should use the form:

venus_mem: venus {
size = <0x50>;
};

And I don't think you should use the shared-dma-pool compatible, because
this is not a region for multiple devices to allocate dma memory out of.


Regards,
Bjorn

Re: [PATCH v3 0/5] dts patches for qcom tsens support

[Andy Gross]

On 24 August 2016 at 22:13, Bjorn Andersson  wrote:
> On Wed 24 Aug 03:22 PDT 2016, Paolo Pisati wrote:
>
>> On Wed, Aug 17, 2016 at 02:33:40PM -0500, Andy Gross wrote:
>> > On Wed, Aug 17, 2016 at 10:48:43AM +0530, Rajendra Nayak wrote:
>> > > Hey Andy,
>> > >
>> > > This is a respin of v2 with some minor fixes pointed out by Rob.
>> > > Please pull these in for 4.9
>> > >
>> > > Thanks,
>> > > Rajendra
>> >
>> > I pulled these in.
>>
>> Did you try to read the content of the qfprom from userspace?
>>
>> $ uname -a
>> Linux dragon410c 4.8.0-rc1+ #6 SMP PREEMPT Wed Aug 24 11:11:02 CEST 2016 
>> aarch64
>> aarch64 aarch64 GNU/Linux
>> $ lsmod
>> Module  Size  Used by
>> nvmem_qfprom   16384  0
>> nvmem_core 24576  1 nvmem_qfprom
>> $ ls -la /sys/bus/nvmem/devices/
>> total 0
>> drwxr-xr-x 2 root root 0 Aug 24 10:17 .
>> drwxr-xr-x 4 root root 0 Aug 24 10:15 ..
>> lrwxrwxrwx 1 root root 0 Aug 24 10:17 qfprom0 ->
>> ../../../devices/platform/soc/5c000.qfprom/qfprom0
>> $ cat /sys/bus/nvmem/devices/qfprom0/nvmem
>>
>> [spontaneous reboot]
>>
>> This using agross's for-next tree as of today ("54ba896 Merge branch
>> 'arm64-defconfig-for-4.9' into all-for-4.8") and defconfig.
>
> This was reported in some other forum as well, after some investigation
> we concluded that it looks like one of the entries are locked down -
> probably from some security reason.
>
> I'm not aware of any way to query this configuration. But the main use
> case for the qfprom is in-kernel access to certain elements and that we
> do get from the driver as is...

Yeah this appears to be the case.  So I guess the response is 'don't
do that'.  At least don't cat or od the file.  You need to seek and
read.

Andy

Re: [PATCH v3 0/5] dts patches for qcom tsens support

[Andy Gross]

On 24 August 2016 at 22:13, Bjorn Andersson  wrote:
> On Wed 24 Aug 03:22 PDT 2016, Paolo Pisati wrote:
>
>> On Wed, Aug 17, 2016 at 02:33:40PM -0500, Andy Gross wrote:
>> > On Wed, Aug 17, 2016 at 10:48:43AM +0530, Rajendra Nayak wrote:
>> > > Hey Andy,
>> > >
>> > > This is a respin of v2 with some minor fixes pointed out by Rob.
>> > > Please pull these in for 4.9
>> > >
>> > > Thanks,
>> > > Rajendra
>> >
>> > I pulled these in.
>>
>> Did you try to read the content of the qfprom from userspace?
>>
>> $ uname -a
>> Linux dragon410c 4.8.0-rc1+ #6 SMP PREEMPT Wed Aug 24 11:11:02 CEST 2016 
>> aarch64
>> aarch64 aarch64 GNU/Linux
>> $ lsmod
>> Module  Size  Used by
>> nvmem_qfprom   16384  0
>> nvmem_core 24576  1 nvmem_qfprom
>> $ ls -la /sys/bus/nvmem/devices/
>> total 0
>> drwxr-xr-x 2 root root 0 Aug 24 10:17 .
>> drwxr-xr-x 4 root root 0 Aug 24 10:15 ..
>> lrwxrwxrwx 1 root root 0 Aug 24 10:17 qfprom0 ->
>> ../../../devices/platform/soc/5c000.qfprom/qfprom0
>> $ cat /sys/bus/nvmem/devices/qfprom0/nvmem
>>
>> [spontaneous reboot]
>>
>> This using agross's for-next tree as of today ("54ba896 Merge branch
>> 'arm64-defconfig-for-4.9' into all-for-4.8") and defconfig.
>
> This was reported in some other forum as well, after some investigation
> we concluded that it looks like one of the entries are locked down -
> probably from some security reason.
>
> I'm not aware of any way to query this configuration. But the main use
> case for the qfprom is in-kernel access to certain elements and that we
> do get from the driver as is...

Yeah this appears to be the case.  So I guess the response is 'don't
do that'.  At least don't cat or od the file.  You need to seek and
read.

Andy

Re: [PATCH 15/34] clk: efm32gg: Migrate to clk_hw based OF and registration APIs

[Stephen Boyd]

On 06/01, Stephen Boyd wrote:
> Now that we have clk_hw based provider APIs to register clks, we
> can get rid of struct clk pointers while registering clks in
> these drivers, allowing us to move closer to a clear split of
> consumer and provider clk APIs.
> 
> Cc: Uwe Kleine-König 
> Signed-off-by: Stephen Boyd 
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 1/2] clk: mvebu: set flags in CP110 gate clock

[Stephen Boyd]

On 08/23, Marcin Wojtas wrote:
> Armada CP110 system controller comprise its own routine responsble
> for registering gate clocks. Among others 'flags' field in
> struct clk_init_data was not set, using a random values, which
> may cause an unpredicted behavior.
> 
> This patch fixes the problem by setting CLK_IS_BASIC flag for
> all gated clocks of Armada 7k/8k SoCs family.
> 
> Fixes: d3da3eaef7f4 ("clk: mvebu: new driver for Armada CP110 system ...")
> 
> Signed-off-by: Marcin Wojtas 
> ---
>  drivers/clk/mvebu/cp110-system-controller.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/clk/mvebu/cp110-system-controller.c 
> b/drivers/clk/mvebu/cp110-system-controller.c
> index 7fa42d6..0835e1d 100644
> --- a/drivers/clk/mvebu/cp110-system-controller.c
> +++ b/drivers/clk/mvebu/cp110-system-controller.c
> @@ -144,6 +144,7 @@ static struct clk *cp110_register_gate(const char *name,
>  
>   init.name = name;
>   init.ops = _gate_ops;
> + init.flags = CLK_IS_BASIC;

Please don't use CLK_IS_BASIC unless you need it (so far only TI
clks seem to want it?). Just set it to 0 if possible.

>   init.parent_names = _name;
>   init.num_parents = 1;
>  

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 14/34] clk: cs2000: Migrate to clk_hw based OF and registration APIs

[Stephen Boyd]

On 06/01, Stephen Boyd wrote:
> Now that we have clk_hw based provider APIs to register clks, we
> can get rid of struct clk pointers while registering clks in
> these drivers, allowing us to move closer to a clear split of
> consumer and provider clk APIs.
> 
> Cc: Kuninori Morimoto 
> Signed-off-by: Stephen Boyd 
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 15/34] clk: efm32gg: Migrate to clk_hw based OF and registration APIs

[Stephen Boyd]

On 06/01, Stephen Boyd wrote:
> Now that we have clk_hw based provider APIs to register clks, we
> can get rid of struct clk pointers while registering clks in
> these drivers, allowing us to move closer to a clear split of
> consumer and provider clk APIs.
> 
> Cc: Uwe Kleine-König 
> Signed-off-by: Stephen Boyd 
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 1/2] clk: mvebu: set flags in CP110 gate clock

[Stephen Boyd]

On 08/23, Marcin Wojtas wrote:
> Armada CP110 system controller comprise its own routine responsble
> for registering gate clocks. Among others 'flags' field in
> struct clk_init_data was not set, using a random values, which
> may cause an unpredicted behavior.
> 
> This patch fixes the problem by setting CLK_IS_BASIC flag for
> all gated clocks of Armada 7k/8k SoCs family.
> 
> Fixes: d3da3eaef7f4 ("clk: mvebu: new driver for Armada CP110 system ...")
> 
> Signed-off-by: Marcin Wojtas 
> ---
>  drivers/clk/mvebu/cp110-system-controller.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/clk/mvebu/cp110-system-controller.c 
> b/drivers/clk/mvebu/cp110-system-controller.c
> index 7fa42d6..0835e1d 100644
> --- a/drivers/clk/mvebu/cp110-system-controller.c
> +++ b/drivers/clk/mvebu/cp110-system-controller.c
> @@ -144,6 +144,7 @@ static struct clk *cp110_register_gate(const char *name,
>  
>   init.name = name;
>   init.ops = _gate_ops;
> + init.flags = CLK_IS_BASIC;

Please don't use CLK_IS_BASIC unless you need it (so far only TI
clks seem to want it?). Just set it to 0 if possible.

>   init.parent_names = _name;
>   init.num_parents = 1;
>  

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 14/34] clk: cs2000: Migrate to clk_hw based OF and registration APIs

[Stephen Boyd]

On 06/01, Stephen Boyd wrote:
> Now that we have clk_hw based provider APIs to register clks, we
> can get rid of struct clk pointers while registering clks in
> these drivers, allowing us to move closer to a clear split of
> consumer and provider clk APIs.
> 
> Cc: Kuninori Morimoto 
> Signed-off-by: Stephen Boyd 
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v3 0/5] dts patches for qcom tsens support

[Bjorn Andersson]

On Wed 24 Aug 03:22 PDT 2016, Paolo Pisati wrote:

> On Wed, Aug 17, 2016 at 02:33:40PM -0500, Andy Gross wrote:
> > On Wed, Aug 17, 2016 at 10:48:43AM +0530, Rajendra Nayak wrote:
> > > Hey Andy,
> > > 
> > > This is a respin of v2 with some minor fixes pointed out by Rob.
> > > Please pull these in for 4.9
> > > 
> > > Thanks,
> > > Rajendra
> > 
> > I pulled these in.
> 
> Did you try to read the content of the qfprom from userspace?
> 
> $ uname -a
> Linux dragon410c 4.8.0-rc1+ #6 SMP PREEMPT Wed Aug 24 11:11:02 CEST 2016 
> aarch64
> aarch64 aarch64 GNU/Linux
> $ lsmod 
> Module  Size  Used by
> nvmem_qfprom   16384  0
> nvmem_core 24576  1 nvmem_qfprom
> $ ls -la /sys/bus/nvmem/devices/  
>
> total 0
> drwxr-xr-x 2 root root 0 Aug 24 10:17 .
> drwxr-xr-x 4 root root 0 Aug 24 10:15 ..
> lrwxrwxrwx 1 root root 0 Aug 24 10:17 qfprom0 ->
> ../../../devices/platform/soc/5c000.qfprom/qfprom0
> $ cat /sys/bus/nvmem/devices/qfprom0/nvmem 
> 
> [spontaneous reboot]
> 
> This using agross's for-next tree as of today ("54ba896 Merge branch
> 'arm64-defconfig-for-4.9' into all-for-4.8") and defconfig.

This was reported in some other forum as well, after some investigation
we concluded that it looks like one of the entries are locked down -
probably from some security reason.

I'm not aware of any way to query this configuration. But the main use
case for the qfprom is in-kernel access to certain elements and that we
do get from the driver as is...

Regards,
Bjorn

Re: [PATCH v2] clk: fixed-factor: add optional dt-binding clock-flags

[Stephen Boyd]

On 07/04, Jongsung Kim wrote:
> On 2016년 07월 02일 09:20, Stephen Boyd wrote:
> > Do you actually have an IC on the board that is doing some fixed
> > factor calculation? Or is this a clk driver design where we are
> > listing out each piece of an SoC's clk controller in DT?
> >
> The SoC has several PLLs of identical design, and one of them is divided
> to half and used for CPUs. The fixed-factor-clock represents the divider.
> 

Ok, so it sounds like we can have the driver that registers the
CPU PLL also register the fixed factor clk? I fail to see why we
need this from DT in that case.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v2] clk: fixed-factor: add optional dt-binding clock-flags

[Stephen Boyd]

On 07/04, Jongsung Kim wrote:
> On 2016년 07월 02일 09:20, Stephen Boyd wrote:
> > Do you actually have an IC on the board that is doing some fixed
> > factor calculation? Or is this a clk driver design where we are
> > listing out each piece of an SoC's clk controller in DT?
> >
> The SoC has several PLLs of identical design, and one of them is divided
> to half and used for CPUs. The fixed-factor-clock represents the divider.
> 

Ok, so it sounds like we can have the driver that registers the
CPU PLL also register the fixed factor clk? I fail to see why we
need this from DT in that case.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v3 0/5] dts patches for qcom tsens support

[Bjorn Andersson]

On Wed 24 Aug 03:22 PDT 2016, Paolo Pisati wrote:

> On Wed, Aug 17, 2016 at 02:33:40PM -0500, Andy Gross wrote:
> > On Wed, Aug 17, 2016 at 10:48:43AM +0530, Rajendra Nayak wrote:
> > > Hey Andy,
> > > 
> > > This is a respin of v2 with some minor fixes pointed out by Rob.
> > > Please pull these in for 4.9
> > > 
> > > Thanks,
> > > Rajendra
> > 
> > I pulled these in.
> 
> Did you try to read the content of the qfprom from userspace?
> 
> $ uname -a
> Linux dragon410c 4.8.0-rc1+ #6 SMP PREEMPT Wed Aug 24 11:11:02 CEST 2016 
> aarch64
> aarch64 aarch64 GNU/Linux
> $ lsmod 
> Module  Size  Used by
> nvmem_qfprom   16384  0
> nvmem_core 24576  1 nvmem_qfprom
> $ ls -la /sys/bus/nvmem/devices/  
>
> total 0
> drwxr-xr-x 2 root root 0 Aug 24 10:17 .
> drwxr-xr-x 4 root root 0 Aug 24 10:15 ..
> lrwxrwxrwx 1 root root 0 Aug 24 10:17 qfprom0 ->
> ../../../devices/platform/soc/5c000.qfprom/qfprom0
> $ cat /sys/bus/nvmem/devices/qfprom0/nvmem 
> 
> [spontaneous reboot]
> 
> This using agross's for-next tree as of today ("54ba896 Merge branch
> 'arm64-defconfig-for-4.9' into all-for-4.8") and defconfig.

This was reported in some other forum as well, after some investigation
we concluded that it looks like one of the entries are locked down -
probably from some security reason.

I'm not aware of any way to query this configuration. But the main use
case for the qfprom is in-kernel access to certain elements and that we
do get from the driver as is...

Regards,
Bjorn

Re: [PATCH 13/34] clk: clps711x: Migrate to clk_hw based OF and registration APIs

[Stephen Boyd]

On 06/01, Stephen Boyd wrote:
> Now that we have clk_hw based provider APIs to register clks, we
> can get rid of struct clk pointers while registering clks in
> these drivers, allowing us to move closer to a clear split of
> consumer and provider clk APIs.
> 
> Cc: Alexander Shiyan 
> Signed-off-by: Stephen Boyd 
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

linux-next: Tree for Aug 25

[Stephen Rothwell]

Hi all,

Changes since 20160824:

The kbuild tree still had its build warnings for PowerPC, for which I
reverted a commit.

Non-merge commits (relative to Linus' tree): 3682
 3689 files changed, 170524 insertions(+), 63738 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 240 trees (counting Linus' and 34 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 (4935e04ef431 Merge branch 'for-linus-4.8-rc4' of 
git://git.kernel.org/pub/scm/linux/kernel/git/rw/uml)
Merging fixes/master (d3396e1e4ec4 Merge tag 'fixes-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc)
Merging kbuild-current/rc-fixes (d3e2773c4ede builddeb: Skip gcc-plugins when 
not configured)
Merging arc-current/for-curr (c57653dc94d0 ARC: export __udivdi3 for modules)
Merging arm-current/fixes (87eed3c74d7c ARM: fix address limit restoration for 
undefined instructions)
Merging m68k-current/for-linus (6bd80f372371 m68k/defconfig: Update defconfigs 
for v4.7-rc2)
Merging metag-fixes/fixes (97b1d23f7bcb metag: Drop show_mem() from mem_init())
Merging powerpc-fixes/fixes (ca49e64f0cb1 selftests/powerpc: Specify we expect 
to build with std=gnu99)
Merging sparc/master (4620a06e4b3c shmem: Fix link error if huge pages support 
is disabled)
Merging net/master (51af96b53469 mlxsw: router: Enable neighbors to be created 
on stacked devices)
Merging ipsec/master (11d7a0bb95ea xfrm: Only add l3mdev oif to dst lookups)
Merging netfilter/master (b75911b66ad5 netfilter: cttimeout: fix use after free 
error when delete netns)
Merging ipvs/master (ea43f860d984 Merge branch 'ethoc-fixes')
Merging wireless-drivers/master (b64abcb7dae6 brcmfmac: Change vif_event_lock 
to spinlock)
Merging mac80211/master (4d0bd46a4d55 Revert "wext: Fix 32 bit iwpriv 
compatibility issue with 64 bit Kernel")
Merging sound-current/for-linus (abaa2274811d ALSA: hda/realtek - fix headset 
mic detection for MSI MS-B120)
Merging pci-current/for-linus (21c80c9fefc3 x86/PCI: VMD: Fix infinite loop 
executing irq's)
Merging driver-core.current/driver-core-linus (694d0d0bb203 Linux 4.8-rc2)
Merging tty.current/tty-linus (87a713c8ffca 8250/fintek: rename IRQ_MODE macro)
Merging usb.current/usb-linus (53e5f36fbd24 USB: avoid left shift by -1)
Merging usb-gadget-fixes/fixes (a0ad85ae866f usb: dwc3: gadget: stop processing 
on HWO set)
Merging usb-serial-fixes/usb-linus (40d9c32525cb USB: serial: option: add 
WeTelecom 0x6802 and 0x6803 products)
Merging usb-chipidea-fixes/ci-for-usb-stable (c4e94174983a usb: chipidea: udc: 
don't touch DP when controller is in host mode)
Merging staging.current/staging-linus (eafe5cfe7189 Merge tag 
'iio-fixes-for-4.8a' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio 
into work-linus)
Merging char-misc.current/char-misc-linus (51c70261b257 Revert "android: 
binder: fix dangling pointer comparison")
Merging input-current/for-linus (e3a888a4bff0 Input: ads7846 - remove redundant 
regulator_disable call)
Merging crypto-current/master (901d3d4fee83 crypto: vmx - fix null dereference 
in p8_aes_xts_crypt)
Merging ide/master (797cee982eef Merge branch 'stable-4.8' of 
git://git.infradead.org/users/pcmoore/audit)
Merging rr-fixes/fixes (8244062ef1e5 modules: fix longstanding /proc/kallsyms 
vs module insertion race.)
Merging vfio-fixes/for-linus (c8952a707556 vfio/pci: F

Re: [PATCH 13/34] clk: clps711x: Migrate to clk_hw based OF and registration APIs

[Stephen Boyd]

On 06/01, Stephen Boyd wrote:
> Now that we have clk_hw based provider APIs to register clks, we
> can get rid of struct clk pointers while registering clks in
> these drivers, allowing us to move closer to a clear split of
> consumer and provider clk APIs.
> 
> Cc: Alexander Shiyan 
> Signed-off-by: Stephen Boyd 
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

linux-next: Tree for Aug 25

[Stephen Rothwell]

Hi all,

Changes since 20160824:

The kbuild tree still had its build warnings for PowerPC, for which I
reverted a commit.

Non-merge commits (relative to Linus' tree): 3682
 3689 files changed, 170524 insertions(+), 63738 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 240 trees (counting Linus' and 34 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 (4935e04ef431 Merge branch 'for-linus-4.8-rc4' of 
git://git.kernel.org/pub/scm/linux/kernel/git/rw/uml)
Merging fixes/master (d3396e1e4ec4 Merge tag 'fixes-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc)
Merging kbuild-current/rc-fixes (d3e2773c4ede builddeb: Skip gcc-plugins when 
not configured)
Merging arc-current/for-curr (c57653dc94d0 ARC: export __udivdi3 for modules)
Merging arm-current/fixes (87eed3c74d7c ARM: fix address limit restoration for 
undefined instructions)
Merging m68k-current/for-linus (6bd80f372371 m68k/defconfig: Update defconfigs 
for v4.7-rc2)
Merging metag-fixes/fixes (97b1d23f7bcb metag: Drop show_mem() from mem_init())
Merging powerpc-fixes/fixes (ca49e64f0cb1 selftests/powerpc: Specify we expect 
to build with std=gnu99)
Merging sparc/master (4620a06e4b3c shmem: Fix link error if huge pages support 
is disabled)
Merging net/master (51af96b53469 mlxsw: router: Enable neighbors to be created 
on stacked devices)
Merging ipsec/master (11d7a0bb95ea xfrm: Only add l3mdev oif to dst lookups)
Merging netfilter/master (b75911b66ad5 netfilter: cttimeout: fix use after free 
error when delete netns)
Merging ipvs/master (ea43f860d984 Merge branch 'ethoc-fixes')
Merging wireless-drivers/master (b64abcb7dae6 brcmfmac: Change vif_event_lock 
to spinlock)
Merging mac80211/master (4d0bd46a4d55 Revert "wext: Fix 32 bit iwpriv 
compatibility issue with 64 bit Kernel")
Merging sound-current/for-linus (abaa2274811d ALSA: hda/realtek - fix headset 
mic detection for MSI MS-B120)
Merging pci-current/for-linus (21c80c9fefc3 x86/PCI: VMD: Fix infinite loop 
executing irq's)
Merging driver-core.current/driver-core-linus (694d0d0bb203 Linux 4.8-rc2)
Merging tty.current/tty-linus (87a713c8ffca 8250/fintek: rename IRQ_MODE macro)
Merging usb.current/usb-linus (53e5f36fbd24 USB: avoid left shift by -1)
Merging usb-gadget-fixes/fixes (a0ad85ae866f usb: dwc3: gadget: stop processing 
on HWO set)
Merging usb-serial-fixes/usb-linus (40d9c32525cb USB: serial: option: add 
WeTelecom 0x6802 and 0x6803 products)
Merging usb-chipidea-fixes/ci-for-usb-stable (c4e94174983a usb: chipidea: udc: 
don't touch DP when controller is in host mode)
Merging staging.current/staging-linus (eafe5cfe7189 Merge tag 
'iio-fixes-for-4.8a' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio 
into work-linus)
Merging char-misc.current/char-misc-linus (51c70261b257 Revert "android: 
binder: fix dangling pointer comparison")
Merging input-current/for-linus (e3a888a4bff0 Input: ads7846 - remove redundant 
regulator_disable call)
Merging crypto-current/master (901d3d4fee83 crypto: vmx - fix null dereference 
in p8_aes_xts_crypt)
Merging ide/master (797cee982eef Merge branch 'stable-4.8' of 
git://git.infradead.org/users/pcmoore/audit)
Merging rr-fixes/fixes (8244062ef1e5 modules: fix longstanding /proc/kallsyms 
vs module insertion race.)
Merging vfio-fixes/for-linus (c8952a707556 vfio/pci: F

MAINTAINERS without commits in the last 3 years

[Joe Perches]

Many email addresses in MAINTAINERS no longer work so many
sections in
MAINTAINERS could likely be considered either
obsolete or unmaintained.

Marking these sections appropriately or simply removing the
sections would make MAINTAINERS and get_maintainer.pl more
useful.

These M: entries in MAINTAINERS haven't authored or had any
-by: signature entries in git log for the last 3 years.

Some of these, like sta...@kernel.org and triv...@kernel.org, are
obviously addresses that should not be deleted from MAINTAINERS,
but most of them are candidates for removal or update.

The email addresses below are also bcc'd here to see what bounces.
The list of the bounces will be collected.

Thoughts?

aacr...@adaptec.com
aacr...@microsemi.com
achim_leub...@adaptec.com
adap...@gmail.com
adilger.ker...@dilger.ca
a...@cwi.nl
ag...@suse.com
a...@comnets.uni-bremen.de
a...@alarsen.net
ali...@web.de
alist...@devzero.co.uk
aloisio.alme...@openbossa.org
andrew.d.henr...@intel.com
andrew.hen...@gmail.com
andre...@usa.net
anil.s.keshavamur...@intel.com
arhu...@freaks-unidos.net
arvin...@gmail.com
ath9k-de...@qca.qualcomm.com
ballabio_da...@emc.com
bcm-kernel-feedback-l...@broadcom.com
ber...@plugable.com
bi...@melbpc.org.au
brij...@gmail.com
brk...@us.ibm.com
brucech...@via.com.tw
castet.matth...@free.fr
ccaul...@redhat.com
cezary.jackiew...@gmail.com
chaoming...@realsil.com.cn
char...@alacritech.com
chess...@tux.org
chr...@sous-sol.org
c...@cs.cmu.edu
co...@colino.net
courmi...@gmail.com
dept-gelinuxnic...@qlogic.com
dept-hsglinuxnic...@qlogic.com
dev...@lanana.org
dh.herrm...@googlemail.com
d...@opfer-online.de
dm-de...@redhat.com
dmitry.tarnya...@lockless.no
d...@syst.com.br
d...@dotat.at
douglas_warze...@dell.com
dougthomp...@xmission.com
drw...@gmail.com
dsax...@plexity.net
d...@gentoo.org
duncan.sa...@free.fr
e...@pasemi.com
eib...@gdsys.de
epa...@parisplace.org
erik.and...@gmail.com
everest-linux...@qlogic.com
fa...@cs.unc.edu
f...@drama.obuda.kando.hu
fisc...@norbit.de
fiz...@tin.it
florian.c.schilha...@googlemail.com
florianschandi...@gmx.de
for...@alittletooquiet.net
fr...@f-seidel.de
fujita.tomon...@lab.ntt.co.jp
fun...@jurai.org
gilles.mul...@lip6.fr
go...@debian.or.jp
guillaume.lign...@gmail.com
gust...@padovan.org
hal.rosenst...@gmail.com
haraldwe...@viatech.com
henk.vergo...@gmail.com
her...@canonical.com
hlhun...@gmail.com
hskinnem...@gmail.com
hswon...@gmail.com
hubert.feurst...@contec.at
ibm-a...@hmh.eng.br
inaky.perez-gonza...@intel.com
infinip...@intel.com
i...@jurassic.park.msu.ru
intel-linux-...@intel.com
io...@badula.org
jansimon.moel...@gmx.de
jarkko.lavi...@nokia.com
ja...@wilsonet.com
jayakumar.a...@gmail.com
jay...@intworks.biz
jclib...@gmail.com
jd...@addtoit.com
j.du...@option.com
j...@parisc-linux.org
jens.tapro...@taprogge.org
jer...@goop.org
j...@trained-monkey.org
ji...@cam.ac.uk
jirisl...@gmail.com
jjcia...@raiz.uncu.edu.ar
joc...@scram.de
jo...@lazybastard.org
johan.hedb...@gmail.com
j...@johnmccutchan.com
jonat...@buzzard.org.uk
jon.nettle...@gmail.com
josh.h.mor...@us.ibm.com
j...@f6fbb.org
jreu...@yaina.de
j...@vanzandt.mv.com
jtp.p...@samsung.com
jue...@gmail.com
juhle...@akamai.com
k...@fi.muni.cz
ker...@savoirfairelinux.com
kevin.cur...@farsite.co.uk
k...@gmx.de
k...@reisers.ca
klass...@mathematik.tu-chemnitz.de
kou.ishiz...@toshiba.co.jp
k...@deine-taler.de
kuz...@ms2.inr.ac.ru
lafo...@gnumonks.org
lafo...@openezx.org
lauro.venan...@openbossa.org
lcostant...@gmail.com
l...@flatcap.org
l...@kernel.org
lene...@twibble.org
linasveps...@gmail.com
linux-dri...@qlogic.com
linuxdriv...@attotech.com
linux-graphics-maintai...@vmware.com
linux-ker...@hansmi.ch
linux-net-driv...@solarflare.com
linuxr...@lsi.com
li...@simtec.co.uk
linuxw...@intel.com
linux-wi...@intel.com
lio...@gmail.com
liqin.li...@gmail.com
m...@melware.de
maintain...@bluecherrydvr.com
mal...@foss.arm.com
manohar.va...@gmail.com
mark.brown...@gmail.com
matt...@wil.cx
m...@qti.qualcomm.com
mbroe...@plusserver.de
mcg...@gmail.com
mche...@kernel.org
mdharm-...@one-eyed-alien.net
m...@sgi.com
m.huls...@tudelft.nl
miguel.ojeda.sando...@gmail.com
m...@compulab.co.il
miq...@df.uba.ar
mi...@sfgoth.com
m...@volny.cz
m...@ucw.cz
mkpe...@internode.on.net
mostr...@earthlink.net
m...@selenic.com
mpor...@kernel.crashing.org
mr.swami.re...@ti.com
neepa...@cisco.com
nic_s...@realtek.com
ning@intel.com
n...@holomorphy.com
oa...@yahoo.com
o...@artecdesign.ee
o.lo...@laposte.net
o...@riede.org
pantelis.anton...@gmail.com
pau...@au.ibm.com
p...@vandrovec.name
p...@sgi.com
pgaik...@nvidia.com
ph...@gnu.org
p...@gelato.unsw.edu.au
p...@eslack.org
pv-driv...@vmware.com
qla2xxx-upstr...@qlogic.com
qlogic-storage-upstr...@qlogic.com
r...@jetztechnologies.com
riverful@samsung.com
ri...@nvidia.com
rl...@rlove.org
rminn...@sandia.gov
r...@tech9.net
ron.mer...@qlogic.com
roy...@zerezo.com
rub...@unipv.it
saff...@us.ibm.com
sako...@gmail.com
sam...@sortiz.org
sant...@chelsio.com
sc...@spiteful.org
secur...@kernel.org
sfre...@samba.org

Re: MAINTAINERS without commits in the last 3 years

[Alexander Graf]

> Am 24.08.2016 um 19:33 schrieb Joe Perches :
> 
> Many email addresses in MAINTAINERS no longer work so many
> sections in
> MAINTAINERS could likely be considered either
> obsolete or unmaintained.
> 
> Marking these sections appropriately or simply removing the
> sections would make MAINTAINERS and get_maintainer.pl more
> useful.
> 
> These M: entries in MAINTAINERS haven't authored or had any
> -by: signature entries in git log for the last 3 years.
> 
> Some of these, like sta...@kernel.org and triv...@kernel.org, are
> obviously addresses that should not be deleted from MAINTAINERS,
> but most of them are candidates for removal or update.
> 
> The email addresses below are also bcc'd here to see what bounces.
> The list of the bounces will be collected.
> 
> Thoughts?
> 
> aacr...@adaptec.com
> aacr...@microsemi.com
> achim_leub...@adaptec.com
> adap...@gmail.com
> adilger.ker...@dilger.ca
> a...@cwi.nl
> ag...@suse.com

This is an alias for suse.de, so I guess it's safe to remove from the list ;).

Alex

MAINTAINERS without commits in the last 3 years

[Joe Perches]

Many email addresses in MAINTAINERS no longer work so many
sections in
MAINTAINERS could likely be considered either
obsolete or unmaintained.

Marking these sections appropriately or simply removing the
sections would make MAINTAINERS and get_maintainer.pl more
useful.

These M: entries in MAINTAINERS haven't authored or had any
-by: signature entries in git log for the last 3 years.

Some of these, like sta...@kernel.org and triv...@kernel.org, are
obviously addresses that should not be deleted from MAINTAINERS,
but most of them are candidates for removal or update.

The email addresses below are also bcc'd here to see what bounces.
The list of the bounces will be collected.

Thoughts?

aacr...@adaptec.com
aacr...@microsemi.com
achim_leub...@adaptec.com
adap...@gmail.com
adilger.ker...@dilger.ca
a...@cwi.nl
ag...@suse.com
a...@comnets.uni-bremen.de
a...@alarsen.net
ali...@web.de
alist...@devzero.co.uk
aloisio.alme...@openbossa.org
andrew.d.henr...@intel.com
andrew.hen...@gmail.com
andre...@usa.net
anil.s.keshavamur...@intel.com
arhu...@freaks-unidos.net
arvin...@gmail.com
ath9k-de...@qca.qualcomm.com
ballabio_da...@emc.com
bcm-kernel-feedback-l...@broadcom.com
ber...@plugable.com
bi...@melbpc.org.au
brij...@gmail.com
brk...@us.ibm.com
brucech...@via.com.tw
castet.matth...@free.fr
ccaul...@redhat.com
cezary.jackiew...@gmail.com
chaoming...@realsil.com.cn
char...@alacritech.com
chess...@tux.org
chr...@sous-sol.org
c...@cs.cmu.edu
co...@colino.net
courmi...@gmail.com
dept-gelinuxnic...@qlogic.com
dept-hsglinuxnic...@qlogic.com
dev...@lanana.org
dh.herrm...@googlemail.com
d...@opfer-online.de
dm-de...@redhat.com
dmitry.tarnya...@lockless.no
d...@syst.com.br
d...@dotat.at
douglas_warze...@dell.com
dougthomp...@xmission.com
drw...@gmail.com
dsax...@plexity.net
d...@gentoo.org
duncan.sa...@free.fr
e...@pasemi.com
eib...@gdsys.de
epa...@parisplace.org
erik.and...@gmail.com
everest-linux...@qlogic.com
fa...@cs.unc.edu
f...@drama.obuda.kando.hu
fisc...@norbit.de
fiz...@tin.it
florian.c.schilha...@googlemail.com
florianschandi...@gmx.de
for...@alittletooquiet.net
fr...@f-seidel.de
fujita.tomon...@lab.ntt.co.jp
fun...@jurai.org
gilles.mul...@lip6.fr
go...@debian.or.jp
guillaume.lign...@gmail.com
gust...@padovan.org
hal.rosenst...@gmail.com
haraldwe...@viatech.com
henk.vergo...@gmail.com
her...@canonical.com
hlhun...@gmail.com
hskinnem...@gmail.com
hswon...@gmail.com
hubert.feurst...@contec.at
ibm-a...@hmh.eng.br
inaky.perez-gonza...@intel.com
infinip...@intel.com
i...@jurassic.park.msu.ru
intel-linux-...@intel.com
io...@badula.org
jansimon.moel...@gmx.de
jarkko.lavi...@nokia.com
ja...@wilsonet.com
jayakumar.a...@gmail.com
jay...@intworks.biz
jclib...@gmail.com
jd...@addtoit.com
j.du...@option.com
j...@parisc-linux.org
jens.tapro...@taprogge.org
jer...@goop.org
j...@trained-monkey.org
ji...@cam.ac.uk
jirisl...@gmail.com
jjcia...@raiz.uncu.edu.ar
joc...@scram.de
jo...@lazybastard.org
johan.hedb...@gmail.com
j...@johnmccutchan.com
jonat...@buzzard.org.uk
jon.nettle...@gmail.com
josh.h.mor...@us.ibm.com
j...@f6fbb.org
jreu...@yaina.de
j...@vanzandt.mv.com
jtp.p...@samsung.com
jue...@gmail.com
juhle...@akamai.com
k...@fi.muni.cz
ker...@savoirfairelinux.com
kevin.cur...@farsite.co.uk
k...@gmx.de
k...@reisers.ca
klass...@mathematik.tu-chemnitz.de
kou.ishiz...@toshiba.co.jp
k...@deine-taler.de
kuz...@ms2.inr.ac.ru
lafo...@gnumonks.org
lafo...@openezx.org
lauro.venan...@openbossa.org
lcostant...@gmail.com
l...@flatcap.org
l...@kernel.org
lene...@twibble.org
linasveps...@gmail.com
linux-dri...@qlogic.com
linuxdriv...@attotech.com
linux-graphics-maintai...@vmware.com
linux-ker...@hansmi.ch
linux-net-driv...@solarflare.com
linuxr...@lsi.com
li...@simtec.co.uk
linuxw...@intel.com
linux-wi...@intel.com
lio...@gmail.com
liqin.li...@gmail.com
m...@melware.de
maintain...@bluecherrydvr.com
mal...@foss.arm.com
manohar.va...@gmail.com
mark.brown...@gmail.com
matt...@wil.cx
m...@qti.qualcomm.com
mbroe...@plusserver.de
mcg...@gmail.com
mche...@kernel.org
mdharm-...@one-eyed-alien.net
m...@sgi.com
m.huls...@tudelft.nl
miguel.ojeda.sando...@gmail.com
m...@compulab.co.il
miq...@df.uba.ar
mi...@sfgoth.com
m...@volny.cz
m...@ucw.cz
mkpe...@internode.on.net
mostr...@earthlink.net
m...@selenic.com
mpor...@kernel.crashing.org
mr.swami.re...@ti.com
neepa...@cisco.com
nic_s...@realtek.com
ning@intel.com
n...@holomorphy.com
oa...@yahoo.com
o...@artecdesign.ee
o.lo...@laposte.net
o...@riede.org
pantelis.anton...@gmail.com
pau...@au.ibm.com
p...@vandrovec.name
p...@sgi.com
pgaik...@nvidia.com
ph...@gnu.org
p...@gelato.unsw.edu.au
p...@eslack.org
pv-driv...@vmware.com
qla2xxx-upstr...@qlogic.com
qlogic-storage-upstr...@qlogic.com
r...@jetztechnologies.com
riverful@samsung.com
ri...@nvidia.com
rl...@rlove.org
rminn...@sandia.gov
r...@tech9.net
ron.mer...@qlogic.com
roy...@zerezo.com
rub...@unipv.it
saff...@us.ibm.com
sako...@gmail.com
sam...@sortiz.org
sant...@chelsio.com
sc...@spiteful.org
secur...@kernel.org
sfre...@samba.org

Re: MAINTAINERS without commits in the last 3 years

[Alexander Graf]

> Am 24.08.2016 um 19:33 schrieb Joe Perches :
> 
> Many email addresses in MAINTAINERS no longer work so many
> sections in
> MAINTAINERS could likely be considered either
> obsolete or unmaintained.
> 
> Marking these sections appropriately or simply removing the
> sections would make MAINTAINERS and get_maintainer.pl more
> useful.
> 
> These M: entries in MAINTAINERS haven't authored or had any
> -by: signature entries in git log for the last 3 years.
> 
> Some of these, like sta...@kernel.org and triv...@kernel.org, are
> obviously addresses that should not be deleted from MAINTAINERS,
> but most of them are candidates for removal or update.
> 
> The email addresses below are also bcc'd here to see what bounces.
> The list of the bounces will be collected.
> 
> Thoughts?
> 
> aacr...@adaptec.com
> aacr...@microsemi.com
> achim_leub...@adaptec.com
> adap...@gmail.com
> adilger.ker...@dilger.ca
> a...@cwi.nl
> ag...@suse.com

This is an alias for suse.de, so I guess it's safe to remove from the list ;).

Alex

Re: [PATCH] arm64: dts: hikey: extend default cma size to 128MB

[Guodong Xu]

On 24 August 2016 at 23:10, Rob Herring  wrote:
> On Wed, Aug 24, 2016 at 8:35 AM, Guodong Xu  wrote:
>> To support display in Debian on HiKey, cma heap is used to allocate
>> graphic buffers. The default size of CMA is 16 MB which is not enought.
>
> s/enought/enough/
>
>>
>> Increase the default CMA size to 128 MB.
>>
>> cc: Rob Herring 
>> cc: Fathi Boudra 
>> cc: John Stultz 
>> cc: Xinliang Liu 
>> Signed-off-by: Guodong Xu 
>> ---
>>  arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 14 ++
>>  1 file changed, 14 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts 
>> b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
>> index 4a51058..abb3434 100644
>> --- a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
>> +++ b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
>> @@ -45,6 +45,20 @@
>>   <0x 0x2200 0x 0x1c00>;
>> };
>>
>> +   reserved-memory {
>> +   #address-cells = <2>;
>> +   #size-cells = <2>;
>> +   ranges;
>> +
>> +   /* global autoconfigured region for contiguous allocations */
>> +   linux,cma {
>> +   compatible = "shared-dma-pool";
>> +   reusable;
>> +   size = <0x 0x0800>;
>> +   linux,cma-default;
>> +   };
>> +   };
>> +
>> pstore: pstore@0x21f0 {
>
> So what is upstream (as of 4.8) for ramoops also uses reserved-memory,
> so you should separately fix this.
>

Got it. I will fix and resend.

> Acked-by: Rob Herring 
>

Thanks.
-Guodong


> Rob

Re: [PATCH 2/2] clk: mvebu: dynamically allocate resources in Armada CP110 system controller

[Stephen Boyd]

On 08/23, Marcin Wojtas wrote:
> Original commit, which added support for Armada CP110 system controller
> used global variables for storing all clock information. It worked
> fine for Armada 7k SoC, with single CP110 block. After dual-CP110 Armada 8k
> was introduced, the data got overwritten and corrupted.
> 
> This patch fixes the issue by allocating resources dynamically in the
> driver probe and storing it as platform drvdata.
> 
> Fixes: d3da3eaef7f4 ("clk: mvebu: new driver for Armada CP110 system ...")
> 

Please drop the space between fixes tag and the signoff.

> Signed-off-by: Marcin Wojtas 
> ---
>  drivers/clk/mvebu/cp110-system-controller.c | 29 
> -
>  1 file changed, 20 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/clk/mvebu/cp110-system-controller.c 
> b/drivers/clk/mvebu/cp110-system-controller.c
> index 0835e1d..2bd87d2 100644
> --- a/drivers/clk/mvebu/cp110-system-controller.c
> +++ b/drivers/clk/mvebu/cp110-system-controller.c
> @@ -81,13 +81,6 @@ enum {
>  #define CP110_GATE_EIP15025
>  #define CP110_GATE_EIP19726
>  
> -static struct clk *cp110_clks[CP110_CLK_NUM];
> -
> -static struct clk_onecell_data cp110_clk_data = {
> - .clks = cp110_clks,
> - .clk_num = CP110_CLK_NUM,
> -};
> -
>  struct cp110_gate_clk {
>   struct clk_hw hw;
>   struct regmap *regmap;
> @@ -195,7 +188,8 @@ static int cp110_syscon_clk_probe(struct platform_device 
> *pdev)
>   struct regmap *regmap;
>   struct device_node *np = pdev->dev.of_node;
>   const char *ppv2_name, *apll_name, *core_name, *eip_name, *nand_name;
> - struct clk *clk;
> + struct clk_onecell_data *cp110_clk_data;
> + struct clk *clk, **cp110_clks;
>   u32 nand_clk_ctrl;
>   int i, ret;
>  
> @@ -208,6 +202,20 @@ static int cp110_syscon_clk_probe(struct platform_device 
> *pdev)
>   if (ret)
>   return ret;
>  
> + cp110_clks = devm_kcalloc(>dev, sizeof(struct clk *),
> +   CP110_CLK_NUM, GFP_KERNEL);
> + if (IS_ERR(cp110_clks))

Doesn't that return NULL on error?

> + return PTR_ERR(cp110_clks);
> +
> + cp110_clk_data = devm_kzalloc(>dev,
> +   sizeof(struct clk_onecell_data),

sizeof(*cp110_clk_data) please

> +   GFP_KERNEL);
> + if (IS_ERR(cp110_clk_data))

Doesn't that return NULL on error?

> + return PTR_ERR(cp110_clk_data);
> +
> + cp110_clk_data->clks = cp110_clks;
> + cp110_clk_data->clk_num = CP110_CLK_NUM;
> +
>   /* Register the APLL which is the root of the clk tree */
>   of_property_read_string_index(np, "core-clock-output-names",
> CP110_CORE_APLL, _name);
> @@ -335,10 +343,12 @@ static int cp110_syscon_clk_probe(struct 
> platform_device *pdev)
>   cp110_clks[CP110_MAX_CORE_CLOCKS + i] = clk;
>   }
>  
> - ret = of_clk_add_provider(np, cp110_of_clk_get, _clk_data);
> + ret = of_clk_add_provider(np, cp110_of_clk_get, cp110_clk_data);

It would be nice if this could be converted to
of_clk_add_hw_provider().

>   if (ret)
>   goto fail_clk_add;
>  
> + platform_set_drvdata(pdev, cp110_clks);
> +
>   return 0;
>  
>  fail_clk_add:
> @@ -365,6 +375,7 @@ fail0:
>  
>  static int cp110_syscon_clk_remove(struct platform_device *pdev)
>  {
> + struct clk **cp110_clks = platform_get_drvdata(pdev);

Is this variable unused now?

>   int i;
>  
>   of_clk_del_provider(pdev->dev.of_node);
> -- 
> 1.8.3.1
> 

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: + stackdepot-fix-mempolicy-use-after-free.patch added to -mm tree

[David Rientjes]

On Fri, 19 Aug 2016, a...@linux-foundation.org wrote:

> From: Vegard Nossum 
> Subject: stackdepot: fix mempolicy use-after-free
> 
> This patch fixes the following:
> 
> BUG: KASAN: use-after-free in alloc_pages_current+0x363/0x370 at addr 
> 88010b48102c
> Read of size 2 by task trinity-c2/15425
> CPU: 0 PID: 15425 Comm: trinity-c2 Not tainted 4.8.0-rc2+ #140
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
> rel-1.9.3-0-ge2fc41e-prebuilt.qemu-proje
> ct.org 04/01/2014
>  88010b481040 88010b557650 81f08d11 88011a40d380
>  88010b481028 88010b557678 815dac7c 88010b557708
>  88010b481028 88011a40d380 88010b5576f8 815daf15
> Call Trace:
>  [] dump_stack+0x65/0x84
>  [] kasan_object_err+0x1c/0x70
>  [] kasan_report_error+0x1f5/0x4c0
>  [] __asan_report_load2_noabort+0x3e/0x40
>  [] alloc_pages_current+0x363/0x370< 
> use-after-free
>  [] depot_save_stack+0x3f4/0x490
>  [] save_stack+0xb5/0xd0
>  [] kasan_slab_free+0x71/0xb0
>  [] kmem_cache_free+0xa3/0x290
>  [] __mpol_put+0x19/0x20   < free
>  [] do_exit+0x1515/0x2b70
>  [] do_group_exit+0xf4/0x2f0
>  [] get_signal+0x53d/0x1120
>  [] do_signal+0x83/0x1e20
>  [] exit_to_usermode_loop+0xaf/0x140
>  [] syscall_return_slowpath+0x144/0x170
>  [] ret_from_fork+0x2f/0x40
> Read of size 2 by task trinity-c2/15425
> 
> The problem is that we may be calling alloc_pages() in a code path where
> current->mempolicy has already been freed.
> 
> By passing __GFP_THISNODE we will always use default_mempolicy (which
> cannot be freed).
> 
> Link: https://lkml.org/lkml/2016/7/29/277
> Link: https://github.com/google/kasan/issues/35
> Link: 
> http://lkml.kernel.org/r/1471603265-31804-1-git-send-email-vegard.nos...@oracle.com
> Signed-off-by: Vegard Nossum 
> Acked-by: Dmitry Vyukov 
> Cc: Alexander Potapenko 
> Cc: Andrey Ryabinin 
> Signed-off-by: Andrew Morton 
> ---
> 
>  lib/stackdepot.c |6 ++
>  1 file changed, 6 insertions(+)
> 
> diff -puN lib/stackdepot.c~stackdepot-fix-mempolicy-use-after-free 
> lib/stackdepot.c
> --- a/lib/stackdepot.c~stackdepot-fix-mempolicy-use-after-free
> +++ a/lib/stackdepot.c
> @@ -243,6 +243,12 @@ depot_stack_handle_t depot_save_stack(st
>   alloc_flags &= ~GFP_ZONEMASK;
>   alloc_flags &= (GFP_ATOMIC | GFP_KERNEL);
>   alloc_flags |= __GFP_NOWARN;
> + /*
> +  * Avoid using current->mempolicy which may already have
> +  * been freed -- we may be in the process of saving the
> +  * stack for exactly that __mpol_put() call.
> +  */
> + alloc_flags |= __GFP_THISNODE;
>   page = alloc_pages(alloc_flags, STACK_ALLOC_ORDER);
>   if (page)
>   prealloc = page_address(page);

This is wrong, it unnecessarily restricts the allocation to a local node 
and has a greater chance to fail.  Passing __GFP_THISNODE here is only an 
implementation detail of mempolicies to avoid reference to freed policy.  
It is easy to fix by using alloc_pages_node(NUMA_NO_NODE, alloc_flags, 
STACK_ALLOC_ORDER) instead of alloc_pages() directly.

Re: [PATCH] arm64: dts: hikey: extend default cma size to 128MB

[Guodong Xu]

On 24 August 2016 at 23:10, Rob Herring  wrote:
> On Wed, Aug 24, 2016 at 8:35 AM, Guodong Xu  wrote:
>> To support display in Debian on HiKey, cma heap is used to allocate
>> graphic buffers. The default size of CMA is 16 MB which is not enought.
>
> s/enought/enough/
>
>>
>> Increase the default CMA size to 128 MB.
>>
>> cc: Rob Herring 
>> cc: Fathi Boudra 
>> cc: John Stultz 
>> cc: Xinliang Liu 
>> Signed-off-by: Guodong Xu 
>> ---
>>  arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 14 ++
>>  1 file changed, 14 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts 
>> b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
>> index 4a51058..abb3434 100644
>> --- a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
>> +++ b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
>> @@ -45,6 +45,20 @@
>>   <0x 0x2200 0x 0x1c00>;
>> };
>>
>> +   reserved-memory {
>> +   #address-cells = <2>;
>> +   #size-cells = <2>;
>> +   ranges;
>> +
>> +   /* global autoconfigured region for contiguous allocations */
>> +   linux,cma {
>> +   compatible = "shared-dma-pool";
>> +   reusable;
>> +   size = <0x 0x0800>;
>> +   linux,cma-default;
>> +   };
>> +   };
>> +
>> pstore: pstore@0x21f0 {
>
> So what is upstream (as of 4.8) for ramoops also uses reserved-memory,
> so you should separately fix this.
>

Got it. I will fix and resend.

> Acked-by: Rob Herring 
>

Thanks.
-Guodong


> Rob

Re: [PATCH 2/2] clk: mvebu: dynamically allocate resources in Armada CP110 system controller

[Stephen Boyd]

On 08/23, Marcin Wojtas wrote:
> Original commit, which added support for Armada CP110 system controller
> used global variables for storing all clock information. It worked
> fine for Armada 7k SoC, with single CP110 block. After dual-CP110 Armada 8k
> was introduced, the data got overwritten and corrupted.
> 
> This patch fixes the issue by allocating resources dynamically in the
> driver probe and storing it as platform drvdata.
> 
> Fixes: d3da3eaef7f4 ("clk: mvebu: new driver for Armada CP110 system ...")
> 

Please drop the space between fixes tag and the signoff.

> Signed-off-by: Marcin Wojtas 
> ---
>  drivers/clk/mvebu/cp110-system-controller.c | 29 
> -
>  1 file changed, 20 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/clk/mvebu/cp110-system-controller.c 
> b/drivers/clk/mvebu/cp110-system-controller.c
> index 0835e1d..2bd87d2 100644
> --- a/drivers/clk/mvebu/cp110-system-controller.c
> +++ b/drivers/clk/mvebu/cp110-system-controller.c
> @@ -81,13 +81,6 @@ enum {
>  #define CP110_GATE_EIP15025
>  #define CP110_GATE_EIP19726
>  
> -static struct clk *cp110_clks[CP110_CLK_NUM];
> -
> -static struct clk_onecell_data cp110_clk_data = {
> - .clks = cp110_clks,
> - .clk_num = CP110_CLK_NUM,
> -};
> -
>  struct cp110_gate_clk {
>   struct clk_hw hw;
>   struct regmap *regmap;
> @@ -195,7 +188,8 @@ static int cp110_syscon_clk_probe(struct platform_device 
> *pdev)
>   struct regmap *regmap;
>   struct device_node *np = pdev->dev.of_node;
>   const char *ppv2_name, *apll_name, *core_name, *eip_name, *nand_name;
> - struct clk *clk;
> + struct clk_onecell_data *cp110_clk_data;
> + struct clk *clk, **cp110_clks;
>   u32 nand_clk_ctrl;
>   int i, ret;
>  
> @@ -208,6 +202,20 @@ static int cp110_syscon_clk_probe(struct platform_device 
> *pdev)
>   if (ret)
>   return ret;
>  
> + cp110_clks = devm_kcalloc(>dev, sizeof(struct clk *),
> +   CP110_CLK_NUM, GFP_KERNEL);
> + if (IS_ERR(cp110_clks))

Doesn't that return NULL on error?

> + return PTR_ERR(cp110_clks);
> +
> + cp110_clk_data = devm_kzalloc(>dev,
> +   sizeof(struct clk_onecell_data),

sizeof(*cp110_clk_data) please

> +   GFP_KERNEL);
> + if (IS_ERR(cp110_clk_data))

Doesn't that return NULL on error?

> + return PTR_ERR(cp110_clk_data);
> +
> + cp110_clk_data->clks = cp110_clks;
> + cp110_clk_data->clk_num = CP110_CLK_NUM;
> +
>   /* Register the APLL which is the root of the clk tree */
>   of_property_read_string_index(np, "core-clock-output-names",
> CP110_CORE_APLL, _name);
> @@ -335,10 +343,12 @@ static int cp110_syscon_clk_probe(struct 
> platform_device *pdev)
>   cp110_clks[CP110_MAX_CORE_CLOCKS + i] = clk;
>   }
>  
> - ret = of_clk_add_provider(np, cp110_of_clk_get, _clk_data);
> + ret = of_clk_add_provider(np, cp110_of_clk_get, cp110_clk_data);

It would be nice if this could be converted to
of_clk_add_hw_provider().

>   if (ret)
>   goto fail_clk_add;
>  
> + platform_set_drvdata(pdev, cp110_clks);
> +
>   return 0;
>  
>  fail_clk_add:
> @@ -365,6 +375,7 @@ fail0:
>  
>  static int cp110_syscon_clk_remove(struct platform_device *pdev)
>  {
> + struct clk **cp110_clks = platform_get_drvdata(pdev);

Is this variable unused now?

>   int i;
>  
>   of_clk_del_provider(pdev->dev.of_node);
> -- 
> 1.8.3.1
> 

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: + stackdepot-fix-mempolicy-use-after-free.patch added to -mm tree

[David Rientjes]

On Fri, 19 Aug 2016, a...@linux-foundation.org wrote:

> From: Vegard Nossum 
> Subject: stackdepot: fix mempolicy use-after-free
> 
> This patch fixes the following:
> 
> BUG: KASAN: use-after-free in alloc_pages_current+0x363/0x370 at addr 
> 88010b48102c
> Read of size 2 by task trinity-c2/15425
> CPU: 0 PID: 15425 Comm: trinity-c2 Not tainted 4.8.0-rc2+ #140
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
> rel-1.9.3-0-ge2fc41e-prebuilt.qemu-proje
> ct.org 04/01/2014
>  88010b481040 88010b557650 81f08d11 88011a40d380
>  88010b481028 88010b557678 815dac7c 88010b557708
>  88010b481028 88011a40d380 88010b5576f8 815daf15
> Call Trace:
>  [] dump_stack+0x65/0x84
>  [] kasan_object_err+0x1c/0x70
>  [] kasan_report_error+0x1f5/0x4c0
>  [] __asan_report_load2_noabort+0x3e/0x40
>  [] alloc_pages_current+0x363/0x370< 
> use-after-free
>  [] depot_save_stack+0x3f4/0x490
>  [] save_stack+0xb5/0xd0
>  [] kasan_slab_free+0x71/0xb0
>  [] kmem_cache_free+0xa3/0x290
>  [] __mpol_put+0x19/0x20   < free
>  [] do_exit+0x1515/0x2b70
>  [] do_group_exit+0xf4/0x2f0
>  [] get_signal+0x53d/0x1120
>  [] do_signal+0x83/0x1e20
>  [] exit_to_usermode_loop+0xaf/0x140
>  [] syscall_return_slowpath+0x144/0x170
>  [] ret_from_fork+0x2f/0x40
> Read of size 2 by task trinity-c2/15425
> 
> The problem is that we may be calling alloc_pages() in a code path where
> current->mempolicy has already been freed.
> 
> By passing __GFP_THISNODE we will always use default_mempolicy (which
> cannot be freed).
> 
> Link: https://lkml.org/lkml/2016/7/29/277
> Link: https://github.com/google/kasan/issues/35
> Link: 
> http://lkml.kernel.org/r/1471603265-31804-1-git-send-email-vegard.nos...@oracle.com
> Signed-off-by: Vegard Nossum 
> Acked-by: Dmitry Vyukov 
> Cc: Alexander Potapenko 
> Cc: Andrey Ryabinin 
> Signed-off-by: Andrew Morton 
> ---
> 
>  lib/stackdepot.c |6 ++
>  1 file changed, 6 insertions(+)
> 
> diff -puN lib/stackdepot.c~stackdepot-fix-mempolicy-use-after-free 
> lib/stackdepot.c
> --- a/lib/stackdepot.c~stackdepot-fix-mempolicy-use-after-free
> +++ a/lib/stackdepot.c
> @@ -243,6 +243,12 @@ depot_stack_handle_t depot_save_stack(st
>   alloc_flags &= ~GFP_ZONEMASK;
>   alloc_flags &= (GFP_ATOMIC | GFP_KERNEL);
>   alloc_flags |= __GFP_NOWARN;
> + /*
> +  * Avoid using current->mempolicy which may already have
> +  * been freed -- we may be in the process of saving the
> +  * stack for exactly that __mpol_put() call.
> +  */
> + alloc_flags |= __GFP_THISNODE;
>   page = alloc_pages(alloc_flags, STACK_ALLOC_ORDER);
>   if (page)
>   prealloc = page_address(page);

This is wrong, it unnecessarily restricts the allocation to a local node 
and has a greater chance to fail.  Passing __GFP_THISNODE here is only an 
implementation detail of mempolicies to avoid reference to freed policy.  
It is easy to fix by using alloc_pages_node(NUMA_NO_NODE, alloc_flags, 
STACK_ALLOC_ORDER) instead of alloc_pages() directly.

Re: [PATCH 3/5] hwrng: amd: Be consitent with the driver name

[Herbert Xu]

On Wed, Aug 24, 2016 at 03:51:22PM +0200, LABBE Corentin wrote:
> On Wed, Aug 24, 2016 at 06:58:11PM +0800, Herbert Xu wrote:
> > On Fri, Aug 19, 2016 at 03:42:55PM +0200, LABBE Corentin wrote:
> > > The driver name is displayed each time differently.
> > > This patch make use of the same name everywhere.
> > > 
> > > Signed-off-by: LABBE Corentin 
> > > ---
> > >  drivers/char/hw_random/amd-rng.c | 13 ++---
> > >  1 file changed, 6 insertions(+), 7 deletions(-)
> > > 
> > > diff --git a/drivers/char/hw_random/amd-rng.c 
> > > b/drivers/char/hw_random/amd-rng.c
> > > index d0042f5..d0a806a 100644
> > > --- a/drivers/char/hw_random/amd-rng.c
> > > +++ b/drivers/char/hw_random/amd-rng.c
> > > @@ -31,7 +31,7 @@
> > >  #include 
> > >  #include 
> > >  
> > > -#define PFX  KBUILD_MODNAME ": "
> > > +#define DRV_NAME "AMD768-HWRNG"
> > >  
> > >  /*
> > >   * Data for PCI driver interface
> > > @@ -98,7 +98,7 @@ static void amd_rng_cleanup(struct hwrng *rng)
> > >  }
> > >  
> > >  static struct hwrng amd_rng = {
> > > - .name   = "amd",
> > > + .name   = DRV_NAME,
> > 
> > Hmm, this changes a sysfs-exported name which has the potential
> > to break user-space.  So I think you'd need to a stronger argument
> > to do it other than just cleaning it up.
> > 
> 
> amd is really really too generic.

Well this would have been a good reason to change it before it
went into the kernel.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH 3/5] hwrng: amd: Be consitent with the driver name

[Herbert Xu]

On Wed, Aug 24, 2016 at 03:51:22PM +0200, LABBE Corentin wrote:
> On Wed, Aug 24, 2016 at 06:58:11PM +0800, Herbert Xu wrote:
> > On Fri, Aug 19, 2016 at 03:42:55PM +0200, LABBE Corentin wrote:
> > > The driver name is displayed each time differently.
> > > This patch make use of the same name everywhere.
> > > 
> > > Signed-off-by: LABBE Corentin 
> > > ---
> > >  drivers/char/hw_random/amd-rng.c | 13 ++---
> > >  1 file changed, 6 insertions(+), 7 deletions(-)
> > > 
> > > diff --git a/drivers/char/hw_random/amd-rng.c 
> > > b/drivers/char/hw_random/amd-rng.c
> > > index d0042f5..d0a806a 100644
> > > --- a/drivers/char/hw_random/amd-rng.c
> > > +++ b/drivers/char/hw_random/amd-rng.c
> > > @@ -31,7 +31,7 @@
> > >  #include 
> > >  #include 
> > >  
> > > -#define PFX  KBUILD_MODNAME ": "
> > > +#define DRV_NAME "AMD768-HWRNG"
> > >  
> > >  /*
> > >   * Data for PCI driver interface
> > > @@ -98,7 +98,7 @@ static void amd_rng_cleanup(struct hwrng *rng)
> > >  }
> > >  
> > >  static struct hwrng amd_rng = {
> > > - .name   = "amd",
> > > + .name   = DRV_NAME,
> > 
> > Hmm, this changes a sysfs-exported name which has the potential
> > to break user-space.  So I think you'd need to a stronger argument
> > to do it other than just cleaning it up.
> > 
> 
> amd is really really too generic.

Well this would have been a good reason to change it before it
went into the kernel.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

[PATCH v2 1/2] arm64: dts: hikey: extend default cma size to 128MB

[Guodong Xu]

To support display in Debian on HiKey, cma heap is used to allocate
graphic buffers. The default size of CMA is 16 MB which is not enough.

Increase the default CMA size to 128 MB.

cc: Fathi Boudra 
cc: John Stultz 
cc: Xinliang Liu 
Signed-off-by: Guodong Xu 
Acked-by: Rob Herring 
---
 arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts 
b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
index 9e4e06a..dba3c13 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
+++ b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
@@ -57,8 +57,15 @@
console-size= <0x0002>;
ftrace-size = <0x0002>;
};
-   };
 
+   /* global autoconfigured region for contiguous allocations */
+   linux,cma {
+   compatible = "shared-dma-pool";
+   reusable;
+   size = <0x 0x0800>;
+   linux,cma-default;
+   };
+   };
 
reboot-mode-syscon@5f01000 {
compatible = "syscon", "simple-mfd";
-- 
1.9.1

Re: [dm-devel] [PATCH v05 04/72] dm-log-userspace.h: use __u32, __s32 and __u64 from linux/types.h

[Bart Van Assche]

On 08/23/16 13:42, Mikko Rapeli wrote:
> On Tue, Aug 23, 2016 at 02:28:19PM +, Bart Van Assche wrote:
>> On 08/23/16 06:57, Bart Van Assche wrote:
>>> On 08/22/16 11:32, Mikko Rapeli wrote:
 - * uint32_t (*get_region_size)(struct dm_dirty_log *log);
 + * __u32 (*get_region_size)(struct dm_dirty_log *log);
>>>
>>> uint32_t is a type that is defined by ANSI C but __u32 not. So this
>>> change looks wrong to me. Would it have been sufficient to add "#include
>>> " and keep the uint32_t etc. type names?
>>
>> Answering my own question: adding "#include " wouldn't be
>> sufficient. How about adding the following code that also occurs in a
>> few other uapi header files?
>>
>> #ifndef __KERNEL__
>> #include 
>> #endif
>> #include 
>
> I have tried that before but I was instructed to use the linux/types.h
> versions. For example https://lkml.org/lkml/2015/6/1/160
>
> But lately drm and fuse and some others have questioned this approach and
> would like to use/continue using C99 stdint.h types.

Hello Mikko,

Thanks for the feedback. I have a minor comment though about your patch: 
are you aware that you have changed uint64_t into __u64 in source code 
comments but that int64_t has not been changed into __s64?

Bart.

[PATCH v2 1/2] arm64: dts: hikey: extend default cma size to 128MB

[Guodong Xu]

To support display in Debian on HiKey, cma heap is used to allocate
graphic buffers. The default size of CMA is 16 MB which is not enough.

Increase the default CMA size to 128 MB.

cc: Fathi Boudra 
cc: John Stultz 
cc: Xinliang Liu 
Signed-off-by: Guodong Xu 
Acked-by: Rob Herring 
---
 arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts 
b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
index 9e4e06a..dba3c13 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
+++ b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
@@ -57,8 +57,15 @@
console-size= <0x0002>;
ftrace-size = <0x0002>;
};
-   };
 
+   /* global autoconfigured region for contiguous allocations */
+   linux,cma {
+   compatible = "shared-dma-pool";
+   reusable;
+   size = <0x 0x0800>;
+   linux,cma-default;
+   };
+   };
 
reboot-mode-syscon@5f01000 {
compatible = "syscon", "simple-mfd";
-- 
1.9.1

Re: [dm-devel] [PATCH v05 04/72] dm-log-userspace.h: use __u32, __s32 and __u64 from linux/types.h

[Bart Van Assche]

On 08/23/16 13:42, Mikko Rapeli wrote:
> On Tue, Aug 23, 2016 at 02:28:19PM +, Bart Van Assche wrote:
>> On 08/23/16 06:57, Bart Van Assche wrote:
>>> On 08/22/16 11:32, Mikko Rapeli wrote:
 - * uint32_t (*get_region_size)(struct dm_dirty_log *log);
 + * __u32 (*get_region_size)(struct dm_dirty_log *log);
>>>
>>> uint32_t is a type that is defined by ANSI C but __u32 not. So this
>>> change looks wrong to me. Would it have been sufficient to add "#include
>>> " and keep the uint32_t etc. type names?
>>
>> Answering my own question: adding "#include " wouldn't be
>> sufficient. How about adding the following code that also occurs in a
>> few other uapi header files?
>>
>> #ifndef __KERNEL__
>> #include 
>> #endif
>> #include 
>
> I have tried that before but I was instructed to use the linux/types.h
> versions. For example https://lkml.org/lkml/2015/6/1/160
>
> But lately drm and fuse and some others have questioned this approach and
> would like to use/continue using C99 stdint.h types.

Hello Mikko,

Thanks for the feedback. I have a minor comment though about your patch: 
are you aware that you have changed uint64_t into __u64 in source code 
comments but that int64_t has not been changed into __s64?

Bart.

Re: [PATCH 1/2] clk: samsung: exynos5260: Move struct samsung_cmu_info to init section

[Stephen Boyd]

On 08/24, Chanwoo Choi wrote:
> On 2016년 08월 24일 13:43, Stephen Boyd wrote:
> > On 08/23, Sylwester Nawrocki wrote:
> >> So the saving is rather insignificant but the patch doesn't make
> >> things worse and I'd say it might be worth applying.
> >>
> > 
> > Sounds good. This sort of information should be in the commit
> > text though. Talking about const doesn't make any sense to me.
> 
> Do you mean that 'const' is initconst secion?

No. Marking it as initconst in the patch is correct.

> If possible, could you explain the anything
> why you don't make sense about 'const'?
> 

I'm just saying that the reasoning to move it from the text
section to the data section shouldn't be because of const. There
should be better reasons to do this, like size benefits.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 1/2] clk: samsung: exynos5260: Move struct samsung_cmu_info to init section

[Stephen Boyd]

On 08/24, Chanwoo Choi wrote:
> On 2016년 08월 24일 13:43, Stephen Boyd wrote:
> > On 08/23, Sylwester Nawrocki wrote:
> >> So the saving is rather insignificant but the patch doesn't make
> >> things worse and I'd say it might be worth applying.
> >>
> > 
> > Sounds good. This sort of information should be in the commit
> > text though. Talking about const doesn't make any sense to me.
> 
> Do you mean that 'const' is initconst secion?

No. Marking it as initconst in the patch is correct.

> If possible, could you explain the anything
> why you don't make sense about 'const'?
> 

I'm just saying that the reasoning to move it from the text
section to the data section shouldn't be because of const. There
should be better reasons to do this, like size benefits.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 00/13] arm64: Allwinner A64 support based on sunxi-ng

[André Przywara]

Hi Maxime,

thanks for your answer, much appreciated!

On 23/08/16 20:31, Maxime Ripard wrote:
> Hi Andre,
> 
> On Mon, Aug 01, 2016 at 02:43:06AM +0100, André Przywara wrote:
>> Hi Maxime,
>>
>> On 26/07/16 21:30, Maxime Ripard wrote:
>>> Hi,
>>>
>>> Here is the previous A64 patches made by Andre [1], reworked to use
>>> the new sunxi-ng clock framework.
>>>
>>> This uses the current H3 clock code, as both are really similar. The
>>> first patches are just meant to rework slightly the H3 code, before
>>> introducing the A64-related patches.
>>>
>>> Some WiP stuff have been removed, such as the MMC part, but this serie
>>> already has a decent amount of devices supported: uart, i2c, rsb, etc.
>>
>> Thanks very much for looking into this and compiling this series!
>>
>> In general this looks good to me - apart from the sunxi-ng clock usage.
>> I think I have some small fixes to the DT (have to compare against my
>> latest local branch), I will comment on this later.
>>
>> As I think I never officially expressed my concerns about the new sunxi
>> clock system, so I use that opportunity here ;-)
>>
>> As this became quite a long read, here a TL;DR:
>> - We consider using an SCPI based clock system for the A64, alongside
>> allwinner,simple-gates and fixed clocks. We try to avoid any Allwinner
>> specific clocks (apart from the simple-gates).
>> - ARM Trusted Firmware provides the SCPI implementation - for now, later
>> we may move this into a possible arisc firmware.
>> - We upstream some basic DT first, possibly omitting any controversial
>> clock parts at all.
>>
>> Let me know what you think!
>>
>>
>> Now the long part 
>>
>> Basically I see those issues with the new clocks:
>> - sunxi-ng requires a complicated SoC specific source file in the
>> kernel. Although that makes the DT pretty easy (and avoids breaking it
>> the future), it ultimately requires an explicit code drop for every new
>> SoC, even if they share 95% of the clocks (as H3 and A64 do, for instance).
>> - This code file does not actually contain any code, instead it's just
>> data and looks like it should really be presented in DT - which brings
>> us back to something like the old sunxi clock scheme, which is
>> apparently not considered good enough. I still wonder if we could create
>> a generic sunxi-ng user, which explains the needed clocks in the DT
>> instead of in code. I admit that looks like quite some work.
>> - It makes it quite hard for any other DT user (*BSD, U-Boot) to use the
>> clocks, since they would have to copy quite verbatim the Linux
>> implementation choice. This is admittedly also true for the old clock
>> framework, but still unfortunate.
> 
> 3 - You never get a complete clock support for any SoC, requirining
> for pretty much every driver to create from scratch a new clock
> driver.

I don't understand this. Are you referring to the old clock system? Or
to the proposed SCPI approach? Or to sunxi-ng with DT descriptions?

And why would a *driver* care about a specific clock if it's using the
common clock framework?
Confused ...

> 4 - You require for all these clocks drivers some Ack from both the DT
> and clocks maintainers, who both said they were fed up with this.

Again which new clock drivers? The old sunxi-clks?
For the SCPI version I propose we don't need any ACKs (apart from the
new .dtsi, maybe), because the clocks are already there.

> 5 - If you realise some day down the road that the parenting
> relationship is not right, or that some clock is not doing what
> you thought it was, you can't really fix it properly because of
> the DT stability you wanted us to enforce.
> 
>> So as mentioned several times before, I am looking into a more firmware
>> driven clock system using the SCPI[1] framework.
>> The idea is:
>> - The basic clocks (OSC24M, OSC32K, AHB1, APB1, APB2, PERIPH0) are
>> expressed as fixed clocks. If I am not mistaken, Allwinner recommends
>> certain frequencies for them anyway, so we just use that and set them up
>> before booting Linux, for instance in ATF.
>> - The gates clocks are expressed as before, but by defining a generic DT
>> compatible fallback name. I have no idea why every SoC enters its name
>> into the simple_gates.c source file, while just mentioning the
>> compatible string in the DT bindings and using the SoC specific name
>> together with a generic fallback like "allwinner,sunxi-simple-gates"
>> would suffice. This means that we don't need to touch simple-gates.c
>> anymore most of the time.
>> - Any clock that can (and has to) be programmed with a variable
>> frequency is expressed as an SCPI clock. This interface allows basically
>> querying and setting a frequency - not very powerful, but sufficient for
>> the clocks I checked. Firmware then takes the burden of programming the
>> respective clock register - which is not rocket science if we lock the
>> base clocks to a certain frequency.
>>
>> The advantage of this approach would be:
>> - 

Re: [PATCH 1/1] arm64/hugetlb: clear PG_dcache_clean if the page is dirty when munmap

[Leizhen (ThunderTown)]

On 2016/8/24 18:30, Catalin Marinas wrote:
> On Wed, Aug 24, 2016 at 05:00:50PM +0800, Leizhen (ThunderTown) wrote:
>>
>>
>> On 2016/8/24 1:28, Catalin Marinas wrote:
>>> On Mon, Aug 22, 2016 at 12:19:04PM +0800, Leizhen (ThunderTown) wrote:
 On 2016/7/20 17:19, Catalin Marinas wrote:
> On Wed, Jul 20, 2016 at 10:46:27AM +0800, Leizhen (ThunderTown) wrote:
>> On 2016/7/8 21:54, Catalin Marinas wrote:
>>> 8<
>>> diff --git a/arch/arm64/mm/flush.c b/arch/arm64/mm/flush.c
>>> index dbd12ea8ce68..c753fa804165 100644
>>> --- a/arch/arm64/mm/flush.c
>>> +++ b/arch/arm64/mm/flush.c
>>> @@ -75,7 +75,8 @@ void __sync_icache_dcache(pte_t pte, unsigned 
>>> long addr)
>>> if (!page_mapping(page))
>>> return;
>>>  
>>> -   if (!test_and_set_bit(PG_dcache_clean, >flags))
>>> +   if (!test_and_set_bit(PG_dcache_clean, >flags) ||
>>> +   PageDirty(page))
>>> sync_icache_aliases(page_address(page),
>>> PAGE_SIZE << compound_order(page));
>>> else if (icache_is_aivivt())
>>> 8<-
>>
>> Do you plan to send this patch? My colleagues told me that if our
>> patches are quite different, it should be Signed-off-by you.
>
> The reason I'm not sending it is that I don't fully understand how it
> solves the problem for a shared file mmap(), not just hugetlbfs. As I
> said in an earlier email: after an msync() in user space we
> should flush the pages to disk via write_cache_pages(). This function
 Hi Catalin:
I'm so sorry for my fault. The previous small pages test result I 
 actually ran on ramfs.
 Today, I ran the case on harddisk fs, it worked well without this patch.

 Summarized as follows:
 small pages on ramfs: need this patch
 small pages on harddisk fs: no need this patch
 hugetlbfs: need this patch
>>>
>>> I would add:
>>>
>>> small pages over nfs: fails with or without this patch
>>>
>>> (tested on Juno, Cortex-A57; seems to be fixed if I remove the
>>> PG_dcache_clean test altogether but, well, we end up over-flushing)
>>>
>>> I assume that when using a hard drive, it goes through the block I/O
>>> layer and we may have a flush_dcache_page() called when the kernel is
>>> about to read a page that has been mapped in user space. This would
>>> clear the PG_dcache_clean bit and subsequent __sync_icache_dcache()
>>> would perform cache maintenance.
>>>
>>> Could you try on your system the test case without the msync() call? I'm
>>
>> According to my test results: without msync, the test case may failed.
> 
> Thanks. Just to be clear, does the test generate a file on on a hard
> drive?
Yes. I checked that the intermediate file had been generated.

> 
>> 10-175-112-211:~ # ./tst_small_page_no_msync
>> Test is Failed: The result is 0x316b9, expect = 0x365a5
>> 10-175-112-211:~ # ./tst_small_page_no_msync
>> Test is Failed: The result is 0x31023, expect = 0x31efa
>> 10-175-112-211:~ # ./tst_small_page_no_msync
>> Test is Passed: The result is 0x31efa, expect = 0x31efa
>>
>> 10-175-112-211:~ # ./tst_small_page
>> Test is Passed: The result is 0x31eb7, expect = 0x31eb7
>> 10-175-112-211:~ # ./tst_small_page
>> Test is Passed: The result is 0x3111f, expect = 0x3111f
>> 10-175-112-211:~ # ./tst_small_page
>> Test is Passed: The result is 0x3111f, expect = 0x3111f
> 
> How many tests did you run for the "passed" case? With NFS it may
I ran ./tst_small_page_no_msync and ./tst_small_page 10 times for each.

> sometime take minutes before a failure (I use the "watch" command with a
> slightly modified test to return non-zero in case of value mismatch).
> 
> While we indeed see failures on multiple filesystem types, I wonder
> whether this test case is actually expected to work. If I modify the
> test to pass O_TRUNC to open(), I can no longer see failures. So any
> standard tool that copies/creates executable files (gcc, dpkg, cp, rsync
> etc.) wouldn't encounter such issues since they truncate the original
> file and old page cache pages would be removed.
> 
> Do you have a real use-case where a task mmap's an executable file,
> modifies it in place and expects another task to see the new
> instructions without user-space cache maintenance?
No, it's just a test case created by testers.

> 

Re: [PATCH 1/1] arm64/hugetlb: clear PG_dcache_clean if the page is dirty when munmap

[Leizhen (ThunderTown)]

On 2016/8/24 18:30, Catalin Marinas wrote:
> On Wed, Aug 24, 2016 at 05:00:50PM +0800, Leizhen (ThunderTown) wrote:
>>
>>
>> On 2016/8/24 1:28, Catalin Marinas wrote:
>>> On Mon, Aug 22, 2016 at 12:19:04PM +0800, Leizhen (ThunderTown) wrote:
 On 2016/7/20 17:19, Catalin Marinas wrote:
> On Wed, Jul 20, 2016 at 10:46:27AM +0800, Leizhen (ThunderTown) wrote:
>> On 2016/7/8 21:54, Catalin Marinas wrote:
>>> 8<
>>> diff --git a/arch/arm64/mm/flush.c b/arch/arm64/mm/flush.c
>>> index dbd12ea8ce68..c753fa804165 100644
>>> --- a/arch/arm64/mm/flush.c
>>> +++ b/arch/arm64/mm/flush.c
>>> @@ -75,7 +75,8 @@ void __sync_icache_dcache(pte_t pte, unsigned 
>>> long addr)
>>> if (!page_mapping(page))
>>> return;
>>>  
>>> -   if (!test_and_set_bit(PG_dcache_clean, >flags))
>>> +   if (!test_and_set_bit(PG_dcache_clean, >flags) ||
>>> +   PageDirty(page))
>>> sync_icache_aliases(page_address(page),
>>> PAGE_SIZE << compound_order(page));
>>> else if (icache_is_aivivt())
>>> 8<-
>>
>> Do you plan to send this patch? My colleagues told me that if our
>> patches are quite different, it should be Signed-off-by you.
>
> The reason I'm not sending it is that I don't fully understand how it
> solves the problem for a shared file mmap(), not just hugetlbfs. As I
> said in an earlier email: after an msync() in user space we
> should flush the pages to disk via write_cache_pages(). This function
 Hi Catalin:
I'm so sorry for my fault. The previous small pages test result I 
 actually ran on ramfs.
 Today, I ran the case on harddisk fs, it worked well without this patch.

 Summarized as follows:
 small pages on ramfs: need this patch
 small pages on harddisk fs: no need this patch
 hugetlbfs: need this patch
>>>
>>> I would add:
>>>
>>> small pages over nfs: fails with or without this patch
>>>
>>> (tested on Juno, Cortex-A57; seems to be fixed if I remove the
>>> PG_dcache_clean test altogether but, well, we end up over-flushing)
>>>
>>> I assume that when using a hard drive, it goes through the block I/O
>>> layer and we may have a flush_dcache_page() called when the kernel is
>>> about to read a page that has been mapped in user space. This would
>>> clear the PG_dcache_clean bit and subsequent __sync_icache_dcache()
>>> would perform cache maintenance.
>>>
>>> Could you try on your system the test case without the msync() call? I'm
>>
>> According to my test results: without msync, the test case may failed.
> 
> Thanks. Just to be clear, does the test generate a file on on a hard
> drive?
Yes. I checked that the intermediate file had been generated.

> 
>> 10-175-112-211:~ # ./tst_small_page_no_msync
>> Test is Failed: The result is 0x316b9, expect = 0x365a5
>> 10-175-112-211:~ # ./tst_small_page_no_msync
>> Test is Failed: The result is 0x31023, expect = 0x31efa
>> 10-175-112-211:~ # ./tst_small_page_no_msync
>> Test is Passed: The result is 0x31efa, expect = 0x31efa
>>
>> 10-175-112-211:~ # ./tst_small_page
>> Test is Passed: The result is 0x31eb7, expect = 0x31eb7
>> 10-175-112-211:~ # ./tst_small_page
>> Test is Passed: The result is 0x3111f, expect = 0x3111f
>> 10-175-112-211:~ # ./tst_small_page
>> Test is Passed: The result is 0x3111f, expect = 0x3111f
> 
> How many tests did you run for the "passed" case? With NFS it may
I ran ./tst_small_page_no_msync and ./tst_small_page 10 times for each.

> sometime take minutes before a failure (I use the "watch" command with a
> slightly modified test to return non-zero in case of value mismatch).
> 
> While we indeed see failures on multiple filesystem types, I wonder
> whether this test case is actually expected to work. If I modify the
> test to pass O_TRUNC to open(), I can no longer see failures. So any
> standard tool that copies/creates executable files (gcc, dpkg, cp, rsync
> etc.) wouldn't encounter such issues since they truncate the original
> file and old page cache pages would be removed.
> 
> Do you have a real use-case where a task mmap's an executable file,
> modifies it in place and expects another task to see the new
> instructions without user-space cache maintenance?
No, it's just a test case created by testers.

> 

Re: [PATCH 00/13] arm64: Allwinner A64 support based on sunxi-ng

[André Przywara]

Hi Maxime,

thanks for your answer, much appreciated!

On 23/08/16 20:31, Maxime Ripard wrote:
> Hi Andre,
> 
> On Mon, Aug 01, 2016 at 02:43:06AM +0100, André Przywara wrote:
>> Hi Maxime,
>>
>> On 26/07/16 21:30, Maxime Ripard wrote:
>>> Hi,
>>>
>>> Here is the previous A64 patches made by Andre [1], reworked to use
>>> the new sunxi-ng clock framework.
>>>
>>> This uses the current H3 clock code, as both are really similar. The
>>> first patches are just meant to rework slightly the H3 code, before
>>> introducing the A64-related patches.
>>>
>>> Some WiP stuff have been removed, such as the MMC part, but this serie
>>> already has a decent amount of devices supported: uart, i2c, rsb, etc.
>>
>> Thanks very much for looking into this and compiling this series!
>>
>> In general this looks good to me - apart from the sunxi-ng clock usage.
>> I think I have some small fixes to the DT (have to compare against my
>> latest local branch), I will comment on this later.
>>
>> As I think I never officially expressed my concerns about the new sunxi
>> clock system, so I use that opportunity here ;-)
>>
>> As this became quite a long read, here a TL;DR:
>> - We consider using an SCPI based clock system for the A64, alongside
>> allwinner,simple-gates and fixed clocks. We try to avoid any Allwinner
>> specific clocks (apart from the simple-gates).
>> - ARM Trusted Firmware provides the SCPI implementation - for now, later
>> we may move this into a possible arisc firmware.
>> - We upstream some basic DT first, possibly omitting any controversial
>> clock parts at all.
>>
>> Let me know what you think!
>>
>>
>> Now the long part 
>>
>> Basically I see those issues with the new clocks:
>> - sunxi-ng requires a complicated SoC specific source file in the
>> kernel. Although that makes the DT pretty easy (and avoids breaking it
>> the future), it ultimately requires an explicit code drop for every new
>> SoC, even if they share 95% of the clocks (as H3 and A64 do, for instance).
>> - This code file does not actually contain any code, instead it's just
>> data and looks like it should really be presented in DT - which brings
>> us back to something like the old sunxi clock scheme, which is
>> apparently not considered good enough. I still wonder if we could create
>> a generic sunxi-ng user, which explains the needed clocks in the DT
>> instead of in code. I admit that looks like quite some work.
>> - It makes it quite hard for any other DT user (*BSD, U-Boot) to use the
>> clocks, since they would have to copy quite verbatim the Linux
>> implementation choice. This is admittedly also true for the old clock
>> framework, but still unfortunate.
> 
> 3 - You never get a complete clock support for any SoC, requirining
> for pretty much every driver to create from scratch a new clock
> driver.

I don't understand this. Are you referring to the old clock system? Or
to the proposed SCPI approach? Or to sunxi-ng with DT descriptions?

And why would a *driver* care about a specific clock if it's using the
common clock framework?
Confused ...

> 4 - You require for all these clocks drivers some Ack from both the DT
> and clocks maintainers, who both said they were fed up with this.

Again which new clock drivers? The old sunxi-clks?
For the SCPI version I propose we don't need any ACKs (apart from the
new .dtsi, maybe), because the clocks are already there.

> 5 - If you realise some day down the road that the parenting
> relationship is not right, or that some clock is not doing what
> you thought it was, you can't really fix it properly because of
> the DT stability you wanted us to enforce.
> 
>> So as mentioned several times before, I am looking into a more firmware
>> driven clock system using the SCPI[1] framework.
>> The idea is:
>> - The basic clocks (OSC24M, OSC32K, AHB1, APB1, APB2, PERIPH0) are
>> expressed as fixed clocks. If I am not mistaken, Allwinner recommends
>> certain frequencies for them anyway, so we just use that and set them up
>> before booting Linux, for instance in ATF.
>> - The gates clocks are expressed as before, but by defining a generic DT
>> compatible fallback name. I have no idea why every SoC enters its name
>> into the simple_gates.c source file, while just mentioning the
>> compatible string in the DT bindings and using the SoC specific name
>> together with a generic fallback like "allwinner,sunxi-simple-gates"
>> would suffice. This means that we don't need to touch simple-gates.c
>> anymore most of the time.
>> - Any clock that can (and has to) be programmed with a variable
>> frequency is expressed as an SCPI clock. This interface allows basically
>> querying and setting a frequency - not very powerful, but sufficient for
>> the clocks I checked. Firmware then takes the burden of programming the
>> respective clock register - which is not rocket science if we lock the
>> base clocks to a certain frequency.
>>
>> The advantage of this approach would be:
>> - 

[PATCH v2 2/2] arm64: dts: hi6220: add resets property into dwmmc nodes

[Guodong Xu]

Add resets property into dwmmc_0, dwmmc_1 and dwmmc_2 for hi6220

Code and documentation to this property were confirmed by maintainers.
See:
[1] https://patchwork.kernel.org/patch/9276607/
[2] https://patchwork.kernel.org/patch/8487151/
[3] https://lkml.org/lkml/2016/8/12/91

cc: Jaehoon Chung 
cc: Rob Herring 
Signed-off-by: Guodong Xu 
---
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi 
b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index d0b887a..63608e9 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -771,6 +771,7 @@
interrupts = <0x0 0x48 0x4>;
clocks = <_ctrl 2>, <_ctrl 1>;
clock-names = "ciu", "biu";
+   resets = <_ctrl PERIPH_RSTDIS0_MMC0>;
bus-width = <0x8>;
vmmc-supply = <>;
pinctrl-names = "default";
@@ -790,6 +791,7 @@
#size-cells = <0x0>;
clocks = <_ctrl 4>, <_ctrl 3>;
clock-names = "ciu", "biu";
+   resets = <_ctrl PERIPH_RSTDIS0_MMC1>;
vqmmc-supply = <>;
vmmc-supply = <>;
bus-width = <0x4>;
@@ -807,6 +809,7 @@
interrupts = <0x0 0x4a 0x4>;
clocks = <_ctrl HI6220_MMC2_CIUCLK>, <_ctrl 
HI6220_MMC2_CLK>;
clock-names = "ciu", "biu";
+   resets = <_ctrl PERIPH_RSTDIS0_MMC2>;
bus-width = <0x4>;
broken-cd;
pinctrl-names = "default", "idle";
-- 
1.9.1

Re: [PATCH] tty: serial: msm: Add runtime PM and system sleep support

[Pramod Gurav]

Hi,

On 17 June 2016 at 15:46, Pramod Gurav  wrote:
> Add runtime pm and suspend/resume callback support to serial msm
> driver so that clock resources are managed runtime to save power.
>

Any comments on this patch?

> Signed-off-by: Pramod Gurav 
> ---
>  drivers/tty/serial/msm_serial.c | 183 
> 
>  1 file changed, 168 insertions(+), 15 deletions(-)
>

>

[PATCH v2 2/2] arm64: dts: hi6220: add resets property into dwmmc nodes

[Guodong Xu]

Add resets property into dwmmc_0, dwmmc_1 and dwmmc_2 for hi6220

Code and documentation to this property were confirmed by maintainers.
See:
[1] https://patchwork.kernel.org/patch/9276607/
[2] https://patchwork.kernel.org/patch/8487151/
[3] https://lkml.org/lkml/2016/8/12/91

cc: Jaehoon Chung 
cc: Rob Herring 
Signed-off-by: Guodong Xu 
---
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi 
b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index d0b887a..63608e9 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -771,6 +771,7 @@
interrupts = <0x0 0x48 0x4>;
clocks = <_ctrl 2>, <_ctrl 1>;
clock-names = "ciu", "biu";
+   resets = <_ctrl PERIPH_RSTDIS0_MMC0>;
bus-width = <0x8>;
vmmc-supply = <>;
pinctrl-names = "default";
@@ -790,6 +791,7 @@
#size-cells = <0x0>;
clocks = <_ctrl 4>, <_ctrl 3>;
clock-names = "ciu", "biu";
+   resets = <_ctrl PERIPH_RSTDIS0_MMC1>;
vqmmc-supply = <>;
vmmc-supply = <>;
bus-width = <0x4>;
@@ -807,6 +809,7 @@
interrupts = <0x0 0x4a 0x4>;
clocks = <_ctrl HI6220_MMC2_CIUCLK>, <_ctrl 
HI6220_MMC2_CLK>;
clock-names = "ciu", "biu";
+   resets = <_ctrl PERIPH_RSTDIS0_MMC2>;
bus-width = <0x4>;
broken-cd;
pinctrl-names = "default", "idle";
-- 
1.9.1

Re: [PATCH] tty: serial: msm: Add runtime PM and system sleep support

[Pramod Gurav]

Hi,

On 17 June 2016 at 15:46, Pramod Gurav  wrote:
> Add runtime pm and suspend/resume callback support to serial msm
> driver so that clock resources are managed runtime to save power.
>

Any comments on this patch?

> Signed-off-by: Pramod Gurav 
> ---
>  drivers/tty/serial/msm_serial.c | 183 
> 
>  1 file changed, 168 insertions(+), 15 deletions(-)
>

>

Re: [PATCH 2/5] Drivers: hv: balloon: account for gaps in hot add regions

[Yauheni Kaliuta]

Hi, kys!

> On Wed, 24 Aug 2016 16:23:10 -0700, kys   wrote:

[...]

 > -static bool pfn_covered(unsigned long start_pfn, unsigned long pfn_cnt)
 > +static int pfn_covered(unsigned long start_pfn, unsigned long pfn_cnt)
 >  {
 >  struct list_head *cur;
 >  struct hv_hotadd_state *has;
 > +struct hv_hotadd_gap *gap;
 >  unsigned long residual, new_inc;
 
 >  if (list_empty(_device.ha_region_list))

One "return false;" left here.


[...]

 > -if (has->covered_end_pfn != start_pfn)
 > -has->covered_end_pfn = start_pfn;
 > -
 > -return true;
 > -
 > +return 1;
 >  }
 
 > -return false;
 > +return 0;
 >  }

[...]

-- 
WBR,
Yauheni Kaliuta

Re: [PATCH 2/5] Drivers: hv: balloon: account for gaps in hot add regions

[Yauheni Kaliuta]

Hi, kys!

> On Wed, 24 Aug 2016 16:23:10 -0700, kys   wrote:

[...]

 > -static bool pfn_covered(unsigned long start_pfn, unsigned long pfn_cnt)
 > +static int pfn_covered(unsigned long start_pfn, unsigned long pfn_cnt)
 >  {
 >  struct list_head *cur;
 >  struct hv_hotadd_state *has;
 > +struct hv_hotadd_gap *gap;
 >  unsigned long residual, new_inc;
 
 >  if (list_empty(_device.ha_region_list))

One "return false;" left here.


[...]

 > -if (has->covered_end_pfn != start_pfn)
 > -has->covered_end_pfn = start_pfn;
 > -
 > -return true;
 > -
 > +return 1;
 >  }
 
 > -return false;
 > +return 0;
 >  }

[...]

-- 
WBR,
Yauheni Kaliuta

Re: [PATCH for-next 0/2] {IB,net}/hns: Add support of ACPI to the Hisilicon RoCE Driver

[David Miller]

From: Salil Mehta 
Date: Wed, 24 Aug 2016 04:44:48 +0800

> This patch is meant to add support of ACPI to the Hisilicon RoCE driver.
> Following changes have been made in the driver(s):
> 
> Patch 1/2: HNS Ethernet Driver: changes to support ACPI have been done in
>the RoCE reset function part of the HNS ethernet driver. Earlier it only
>supported DT/syscon.
> 
> Patch 2/2. HNS RoCE driver: changes done in RoCE driver are meant to detect
>the type and then either use DT specific or ACPI spcific functions. Where
>ever possible, this patch tries to make use of "Unified Device Property
>Interface" APIs to support both DT and ACPI through single interface.
> 
> NOTE 1: ACPI changes done in both of the drivers depend upon the ACPI Table
>  (DSDT and IORT tables) changes part of UEFI/BIOS. These changes are NOT
>  part of this patch-set.
> NOTE 2: Reset function in Patch 1/2 depends upon the reset function added in
>  ACPI tables(basically DSDT table) part of the UEFI/BIOS. Again, this
>  change is NOT reflected in this patch-set.

I can't apply this series to my tree because the hns infiniband driver
doesn't exist in it.

Re: [PATCH for-next 0/2] {IB,net}/hns: Add support of ACPI to the Hisilicon RoCE Driver

[David Miller]

From: Salil Mehta 
Date: Wed, 24 Aug 2016 04:44:48 +0800

> This patch is meant to add support of ACPI to the Hisilicon RoCE driver.
> Following changes have been made in the driver(s):
> 
> Patch 1/2: HNS Ethernet Driver: changes to support ACPI have been done in
>the RoCE reset function part of the HNS ethernet driver. Earlier it only
>supported DT/syscon.
> 
> Patch 2/2. HNS RoCE driver: changes done in RoCE driver are meant to detect
>the type and then either use DT specific or ACPI spcific functions. Where
>ever possible, this patch tries to make use of "Unified Device Property
>Interface" APIs to support both DT and ACPI through single interface.
> 
> NOTE 1: ACPI changes done in both of the drivers depend upon the ACPI Table
>  (DSDT and IORT tables) changes part of UEFI/BIOS. These changes are NOT
>  part of this patch-set.
> NOTE 2: Reset function in Patch 1/2 depends upon the reset function added in
>  ACPI tables(basically DSDT table) part of the UEFI/BIOS. Again, this
>  change is NOT reflected in this patch-set.

I can't apply this series to my tree because the hns infiniband driver
doesn't exist in it.

Re: [PATCH 2/2] ARM: dts: sun8i: enable UART1 for iNet D978 Rev2 board

[Chen-Yu Tsai]

On Thu, Aug 25, 2016 at 7:58 AM, Icenowy Zheng  wrote:
>
>
> 25.08.2016, 03:36, "Maxime Ripard" :
>> Hi,
>>
>> On Tue, Aug 23, 2016 at 02:44:51PM +0800, Icenowy Zheng wrote:
>>>  UART1 is connected to the bluetooth part of RTL8723BS WiFi/BT combo card
>>>  on iNet D978 Rev2 board.
>>>
>>>  Enable the UART1 to make it possible to use the modified hciattach by
>>>  Realtek to drive the BT part of RTL8723BS.
>>>
>>>  Signed-off-by: Icenowy Zheng 
>>
>> I guess you could fold that patch into the previous one.
>>
>>>  ---
>>>   arch/arm/boot/dts/sun8i-a33-inet-d978-rev2.dts | 11 +++
>>>   1 file changed, 11 insertions(+)
>>>
>>>  diff --git a/arch/arm/boot/dts/sun8i-a33-inet-d978-rev2.dts 
>>> b/arch/arm/boot/dts/sun8i-a33-inet-d978-rev2.dts
>>>  index 78823d8..3ac22d4 100644
>>>  --- a/arch/arm/boot/dts/sun8i-a33-inet-d978-rev2.dts
>>>  +++ b/arch/arm/boot/dts/sun8i-a33-inet-d978-rev2.dts
>>>  @@ -48,6 +48,10 @@
>>>   model = "INet-D978 Rev 02";
>>>   compatible = "primux,inet-d978-rev2", "allwinner,sun8i-a33";
>>>
>>>  + aliases {
>>>  + serial1 = 
>>>  + };
>>>  +
>>
>> Is there any other UART in the system?
>
> serial0 is defined in sun8i-reference-design-tablet.dtsi, as r_uart.

If your board does not have r_uart pads, then the right thing to do
would be to disable it. You can then have uart1 as serial0.

AFAIK Linux requires a console, but that console can be simplefb.

ChenYu

>>
>> The alias is not supposed to be about the controller index, but the
>> index in the board, meaning that if you only have a single UART, that
>> would be serial0.
>>
>> Thanks!
>> Maxime
>>
>> --
>> Maxime Ripard, Free Electrons
>> Embedded Linux and Kernel engineering
>> http://free-electrons.com

Re: [PATCH 2/2] ARM: dts: sun8i: enable UART1 for iNet D978 Rev2 board

[Chen-Yu Tsai]

On Thu, Aug 25, 2016 at 7:58 AM, Icenowy Zheng  wrote:
>
>
> 25.08.2016, 03:36, "Maxime Ripard" :
>> Hi,
>>
>> On Tue, Aug 23, 2016 at 02:44:51PM +0800, Icenowy Zheng wrote:
>>>  UART1 is connected to the bluetooth part of RTL8723BS WiFi/BT combo card
>>>  on iNet D978 Rev2 board.
>>>
>>>  Enable the UART1 to make it possible to use the modified hciattach by
>>>  Realtek to drive the BT part of RTL8723BS.
>>>
>>>  Signed-off-by: Icenowy Zheng 
>>
>> I guess you could fold that patch into the previous one.
>>
>>>  ---
>>>   arch/arm/boot/dts/sun8i-a33-inet-d978-rev2.dts | 11 +++
>>>   1 file changed, 11 insertions(+)
>>>
>>>  diff --git a/arch/arm/boot/dts/sun8i-a33-inet-d978-rev2.dts 
>>> b/arch/arm/boot/dts/sun8i-a33-inet-d978-rev2.dts
>>>  index 78823d8..3ac22d4 100644
>>>  --- a/arch/arm/boot/dts/sun8i-a33-inet-d978-rev2.dts
>>>  +++ b/arch/arm/boot/dts/sun8i-a33-inet-d978-rev2.dts
>>>  @@ -48,6 +48,10 @@
>>>   model = "INet-D978 Rev 02";
>>>   compatible = "primux,inet-d978-rev2", "allwinner,sun8i-a33";
>>>
>>>  + aliases {
>>>  + serial1 = 
>>>  + };
>>>  +
>>
>> Is there any other UART in the system?
>
> serial0 is defined in sun8i-reference-design-tablet.dtsi, as r_uart.

If your board does not have r_uart pads, then the right thing to do
would be to disable it. You can then have uart1 as serial0.

AFAIK Linux requires a console, but that console can be simplefb.

ChenYu

>>
>> The alias is not supposed to be about the controller index, but the
>> index in the board, meaning that if you only have a single UART, that
>> would be serial0.
>>
>> Thanks!
>> Maxime
>>
>> --
>> Maxime Ripard, Free Electrons
>> Embedded Linux and Kernel engineering
>> http://free-electrons.com

Re: [kbuild-all] make[2]: *** No rule to make target 'tools/testing/nvdimm//config_check.o', needed by 'tools/testing/nvdimm//dax.o'.

[Fengguang Wu]

On Wed, Aug 24, 2016 at 07:59:05AM -0700, Dan Williams wrote:

On Tue, Aug 23, 2016 at 7:47 PM, Fengguang Wu  wrote:

On Tue, Aug 23, 2016 at 04:42:15PM -0700, Dan Williams wrote:

I was not able to reproduce this, I tried on Fedora 23 and Fedora 24
and both attempts succeeded.



Hi Dan, it looks the error only happens with separated obj dir, when
KBUILD_OUTPUT or "-C .. O=.." is used in make command line.


The following worked for me, what am I missing?

$ make -j 64 O=$HOME/git/obj 2>out; make -j 64 O=$HOME/git/obj
M=tools/testing/nvdimm 2>>out;


In 0day builds, $PWD is the obj dir and so we used "-C" too:

   wfg@inn ~/linux/obj-compiletest% ls -l source
   lrwxrwxrwx 1 wfg wfg 2 Aug 24 10:40 source -> ..

   wfg@inn ~/linux/obj-compiletest% make M=tools/testing/nvdimm/
==> /usr/bin/make -C source O=/home/wfg/linux/obj-compiletest ARCH=x86_64 
-j32 M=tools/testing/nvdimm/
   make: Entering directory '/c/wfg/linux'
   make[1]: Entering directory '/c/wfg/linux/obj-compiletest'
   make[2]: *** No rule to make target 
'tools/testing/nvdimm//config_check.o', needed by 
'tools/testing/nvdimm//libnvdimm.o'.  Stop.
   /c/wfg/linux/Makefile:1478: recipe for target 
'_module_tools/testing/nvdimm/' failed
   make[1]: *** [_module_tools/testing/nvdimm/] Error 2
   make[1]: Leaving directory '/c/wfg/linux/obj-compiletest'
   Makefile:150: recipe for target 'sub-make' failed
   make: *** [sub-make] Error 2
   make: Leaving directory '/c/wfg/linux'

Thanks,
Fengguang

Re: [kbuild-all] make[2]: *** No rule to make target 'tools/testing/nvdimm//config_check.o', needed by 'tools/testing/nvdimm//dax.o'.

[Fengguang Wu]

On Wed, Aug 24, 2016 at 07:59:05AM -0700, Dan Williams wrote:

On Tue, Aug 23, 2016 at 7:47 PM, Fengguang Wu  wrote:

On Tue, Aug 23, 2016 at 04:42:15PM -0700, Dan Williams wrote:

I was not able to reproduce this, I tried on Fedora 23 and Fedora 24
and both attempts succeeded.



Hi Dan, it looks the error only happens with separated obj dir, when
KBUILD_OUTPUT or "-C .. O=.." is used in make command line.


The following worked for me, what am I missing?

$ make -j 64 O=$HOME/git/obj 2>out; make -j 64 O=$HOME/git/obj
M=tools/testing/nvdimm 2>>out;


In 0day builds, $PWD is the obj dir and so we used "-C" too:

   wfg@inn ~/linux/obj-compiletest% ls -l source
   lrwxrwxrwx 1 wfg wfg 2 Aug 24 10:40 source -> ..

   wfg@inn ~/linux/obj-compiletest% make M=tools/testing/nvdimm/
==> /usr/bin/make -C source O=/home/wfg/linux/obj-compiletest ARCH=x86_64 
-j32 M=tools/testing/nvdimm/
   make: Entering directory '/c/wfg/linux'
   make[1]: Entering directory '/c/wfg/linux/obj-compiletest'
   make[2]: *** No rule to make target 
'tools/testing/nvdimm//config_check.o', needed by 
'tools/testing/nvdimm//libnvdimm.o'.  Stop.
   /c/wfg/linux/Makefile:1478: recipe for target 
'_module_tools/testing/nvdimm/' failed
   make[1]: *** [_module_tools/testing/nvdimm/] Error 2
   make[1]: Leaving directory '/c/wfg/linux/obj-compiletest'
   Makefile:150: recipe for target 'sub-make' failed
   make: *** [sub-make] Error 2
   make: Leaving directory '/c/wfg/linux'

Thanks,
Fengguang

Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

[Matthijs van Duin]

On 13 January 2016 at 19:18, Nishanth Menon  wrote:
> As you already see it is ridiculously round about way of protecting RTC
> time.. but anyways, for what ever reason, that was mandatory function to
> support on certain product lines.

Having secure date/time is probably necessary for some digital rights
management schemes; e.g. you rent a movie for limited time, but it may
not always be acceptable to require working internet connectivity to
be able to hit the play button hence the need to rely on a secure RTC.

There wouldn't even be an SMC for setting the RTC, probably it would
synchronize when the secure-world shizzle contacts the Big Server
O'Secrety Bits. :P

Protecting pinmux through the L4 firewall sounds hilarious: the whole
ctrl_core module (0x4a002000 - 0x4a002fff) is a single firewall
region. All permitted access to it by linux would have to be
redirected to an SMC or similar.

On 13 January 2016 at 20:05, Nishanth Menon  wrote:
> An internal feedback I got some time back on AM57 (not OMAP5) - context
> was that we were discussing if an external pull up resistor was needed
> for a GPIO button:
> "Internal pull-ups are relatively weak (ranging to 100kOhm or higher)

Unlike the OMAP5, AM57xx uses 1.8V/3.3V drivers for its generic IOs,
which have to do magic to not get fried by such high voltages.
Crappier specs result, especially for pulling up to 3.3V:
1.8V mode, pull-down current while pin is held high: 50-210 uA
3.3V mode, pull-down current while pin is held high: 40-200 uA
1.8V mode, pull-up current while pin is held low: 60-200 uA
3.3V mode, pull-up current while pin is held low: 10-290 uA

Note the worst-case equivalent pull-up resistance in 3.3V mode is 330
kOhm, eleven times higher than in 1.8V mode.

Matthijs

Re: [PATCH] livepatch/module: make TAINT_LIVEPATCH module-specific

[Jiri Kosina]

On Wed, 24 Aug 2016, Josh Poimboeuf wrote:

> There's no reliable way to determine which module tainted the kernel
> with CONFIG_LIVEPATCH.  For example, /sys/module//taint
> doesn't report it.  Neither does the "mod -t" command in the crash tool.
> 
> Make it crystal clear who the guilty party is by converting
> CONFIG_LIVEPATCH to a module taint flag.
> 
> This changes the behavior a bit: now the the flag gets set when the
> module is loaded, rather than when it's enabled.
> 
> Reviewed-by: Chunyu Hu 
> Signed-off-by: Josh Poimboeuf 

I like this change.

Rusty, in case you're okay with it as well, could you please either 
provide your Ack so that I could take it through livepatching.git? 
Alternatively, if you prefer to merge this through your tree, please feel 
free to add

Acked-by: Jiri Kosina 

Thanks,

-- 
Jiri Kosina
SUSE Labs