Re: [PATCH 0/2] MCA support on Centaur CPU

2018-03-30 Thread Ingo Molnar

* David Wang  wrote:

> This patch set is to provide MCA support on new Centaur CPU. 
> 
> The first patch is used to tell the kernel that newer Centaur CPU support 
> MCE broadcasting.
> 
> The second patch is used to tell the kernel that newer Centaur CPU support 
> CMCI. 
> 
> David Wang (2):
>   x86/mce: new centaur CPUs support MCE broadcasting
>   x86/mce: add CMCI support for centaur CPUs
> 
>  arch/x86/kernel/cpu/mcheck/mce.c | 12 
>  1 file changed, 12 insertions(+)

Please capitalize 'Centaur' properly in the changelogs and in comments.

Thanks,

Ingo


Re: [PATCH 0/2] MCA support on Centaur CPU

2018-03-30 Thread Ingo Molnar

* David Wang  wrote:

> This patch set is to provide MCA support on new Centaur CPU. 
> 
> The first patch is used to tell the kernel that newer Centaur CPU support 
> MCE broadcasting.
> 
> The second patch is used to tell the kernel that newer Centaur CPU support 
> CMCI. 
> 
> David Wang (2):
>   x86/mce: new centaur CPUs support MCE broadcasting
>   x86/mce: add CMCI support for centaur CPUs
> 
>  arch/x86/kernel/cpu/mcheck/mce.c | 12 
>  1 file changed, 12 insertions(+)

Please capitalize 'Centaur' properly in the changelogs and in comments.

Thanks,

Ingo


Re: [PATCH v6 1/6] Staging: iio: adis16209: Indent the field definitions

2018-03-30 Thread Jonathan Cameron
On Thu, 29 Mar 2018 14:42:02 +0530
Shreeya Patel  wrote:

> Have indentation in field definitions to make them
> clearly different from the register addresses.
> 
> Signed-off-by: Shreeya Patel 
Applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to play with it.

Note that, given the timing wrt to the current kernel cycle
(merge window will probably open this weekend), this and
everything for the last 2 weeks is now destined to go upstream
in the next cycle.

Thanks,

Jonathan

> ---
> 
> Changes in v5
>   -Change some macro names and have indentation in the field
> definitions.
> 
> Changes in v6
>   -Have indentation in the field definitions and do not
> change the names of the macros as the patch for changing 
> the names has already been applied.
> 
>  drivers/staging/iio/accel/adis16209.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/staging/iio/accel/adis16209.c 
> b/drivers/staging/iio/accel/adis16209.c
> index a8453bf..0e6366a 100644
> --- a/drivers/staging/iio/accel/adis16209.c
> +++ b/drivers/staging/iio/accel/adis16209.c
> @@ -71,13 +71,13 @@
>  #define ADIS16209_STAT_REG   0x3C
>  #define  ADIS16209_STAT_ALARM2   BIT(9)
>  #define  ADIS16209_STAT_ALARM1   BIT(8)
> -#define ADIS16209_STAT_SELFTEST_FAIL_BIT 5
> -#define ADIS16209_STAT_SPI_FAIL_BIT  3
> -#define ADIS16209_STAT_FLASH_UPT_FAIL_BIT2
> +#define  ADIS16209_STAT_SELFTEST_FAIL_BIT5
> +#define  ADIS16209_STAT_SPI_FAIL_BIT 3
> +#define  ADIS16209_STAT_FLASH_UPT_FAIL_BIT   2
>  /* Power supply above 3.625 V */
> -#define ADIS16209_STAT_POWER_HIGH_BIT1
> +#define  ADIS16209_STAT_POWER_HIGH_BIT   1
>  /* Power supply below 3.15 V */
> -#define ADIS16209_STAT_POWER_LOW_BIT 0
> +#define  ADIS16209_STAT_POWER_LOW_BIT0
>  
>  #define ADIS16209_CMD_REG0x3E
>  #define  ADIS16209_CMD_SW_RESET  BIT(7)



Re: [PATCH v6 1/6] Staging: iio: adis16209: Indent the field definitions

2018-03-30 Thread Jonathan Cameron
On Thu, 29 Mar 2018 14:42:02 +0530
Shreeya Patel  wrote:

> Have indentation in field definitions to make them
> clearly different from the register addresses.
> 
> Signed-off-by: Shreeya Patel 
Applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to play with it.

Note that, given the timing wrt to the current kernel cycle
(merge window will probably open this weekend), this and
everything for the last 2 weeks is now destined to go upstream
in the next cycle.

Thanks,

Jonathan

> ---
> 
> Changes in v5
>   -Change some macro names and have indentation in the field
> definitions.
> 
> Changes in v6
>   -Have indentation in the field definitions and do not
> change the names of the macros as the patch for changing 
> the names has already been applied.
> 
>  drivers/staging/iio/accel/adis16209.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/staging/iio/accel/adis16209.c 
> b/drivers/staging/iio/accel/adis16209.c
> index a8453bf..0e6366a 100644
> --- a/drivers/staging/iio/accel/adis16209.c
> +++ b/drivers/staging/iio/accel/adis16209.c
> @@ -71,13 +71,13 @@
>  #define ADIS16209_STAT_REG   0x3C
>  #define  ADIS16209_STAT_ALARM2   BIT(9)
>  #define  ADIS16209_STAT_ALARM1   BIT(8)
> -#define ADIS16209_STAT_SELFTEST_FAIL_BIT 5
> -#define ADIS16209_STAT_SPI_FAIL_BIT  3
> -#define ADIS16209_STAT_FLASH_UPT_FAIL_BIT2
> +#define  ADIS16209_STAT_SELFTEST_FAIL_BIT5
> +#define  ADIS16209_STAT_SPI_FAIL_BIT 3
> +#define  ADIS16209_STAT_FLASH_UPT_FAIL_BIT   2
>  /* Power supply above 3.625 V */
> -#define ADIS16209_STAT_POWER_HIGH_BIT1
> +#define  ADIS16209_STAT_POWER_HIGH_BIT   1
>  /* Power supply below 3.15 V */
> -#define ADIS16209_STAT_POWER_LOW_BIT 0
> +#define  ADIS16209_STAT_POWER_LOW_BIT0
>  
>  #define ADIS16209_CMD_REG0x3E
>  #define  ADIS16209_CMD_SW_RESET  BIT(7)



Re: [PATCH net-next v2 1/2] fs/crashdd: add API to collect hardware dump in second kernel

2018-03-30 Thread Jiri Pirko
Sat, Mar 24, 2018 at 11:56:33AM CET, rahul.lakkire...@chelsio.com wrote:
>Add a new module crashdd that exports the /sys/kernel/crashdd/
>directory in second kernel, containing collected hardware/firmware
>dumps.
>
>The sequence of actions done by device drivers to append their device
>specific hardware/firmware logs to /sys/kernel/crashdd/ directory are
>as follows:
>
>1. During probe (before hardware is initialized), device drivers
>register to the crashdd module (via crashdd_add_dump()), with
>callback function, along with buffer size and log name needed for
>firmware/hardware log collection.
>
>2. Crashdd creates a driver's directory under
>/sys/kernel/crashdd/. Then, it allocates the buffer with

This smells. I need to identify the exact ASIC instance that produced
the dump. To identify by driver name does not help me if I have multiple
instances of the same driver. This looks wrong to me. This looks like
a job for devlink where you have 1 devlink instance per 1 ASIC instance.

Please see:
http://patchwork.ozlabs.org/project/netdev/list/?series=36524

I bevieve that the solution in the patchset could be used for
your usecase too.


>requested size and invokes the device driver's registered callback
>function.
>
>3. Device driver collects all hardware/firmware logs into the buffer
>and returns control back to crashdd.
>
>4. Crashdd exposes the buffer as a binary file via
>/sys/kernel/crashdd//.
>


Re: [PATCH net-next v2 1/2] fs/crashdd: add API to collect hardware dump in second kernel

2018-03-30 Thread Jiri Pirko
Sat, Mar 24, 2018 at 11:56:33AM CET, rahul.lakkire...@chelsio.com wrote:
>Add a new module crashdd that exports the /sys/kernel/crashdd/
>directory in second kernel, containing collected hardware/firmware
>dumps.
>
>The sequence of actions done by device drivers to append their device
>specific hardware/firmware logs to /sys/kernel/crashdd/ directory are
>as follows:
>
>1. During probe (before hardware is initialized), device drivers
>register to the crashdd module (via crashdd_add_dump()), with
>callback function, along with buffer size and log name needed for
>firmware/hardware log collection.
>
>2. Crashdd creates a driver's directory under
>/sys/kernel/crashdd/. Then, it allocates the buffer with

This smells. I need to identify the exact ASIC instance that produced
the dump. To identify by driver name does not help me if I have multiple
instances of the same driver. This looks wrong to me. This looks like
a job for devlink where you have 1 devlink instance per 1 ASIC instance.

Please see:
http://patchwork.ozlabs.org/project/netdev/list/?series=36524

I bevieve that the solution in the patchset could be used for
your usecase too.


>requested size and invokes the device driver's registered callback
>function.
>
>3. Device driver collects all hardware/firmware logs into the buffer
>and returns control back to crashdd.
>
>4. Crashdd exposes the buffer as a binary file via
>/sys/kernel/crashdd//.
>


Re: [PATCH 1/3] iio: adc: meson-saradc: squash and share the common adc platform data

2018-03-30 Thread Yixun Lan
On 03/30/18 17:48, Jonathan Cameron wrote:
> On Mon, 26 Mar 2018 16:46:27 +0800
> Yixun Lan  wrote:
> 
>> Extract and promote common adc platform data into a new structure,
>> to make it better share the info between several SoCs,
>> this will avoid duplicating the code all over the place,
>> Save a few memory and make the code more maintainable.
>>
>> Signed-off-by: Yixun Lan 
> Applied to the togreg branch of iio.git and pushed out as testing
> for the autobuilders to play with it.

Hi Jonathan

  Great! Thanks for taking these

Yixun


Re: [PATCH 1/3] iio: adc: meson-saradc: squash and share the common adc platform data

2018-03-30 Thread Yixun Lan
On 03/30/18 17:48, Jonathan Cameron wrote:
> On Mon, 26 Mar 2018 16:46:27 +0800
> Yixun Lan  wrote:
> 
>> Extract and promote common adc platform data into a new structure,
>> to make it better share the info between several SoCs,
>> this will avoid duplicating the code all over the place,
>> Save a few memory and make the code more maintainable.
>>
>> Signed-off-by: Yixun Lan 
> Applied to the togreg branch of iio.git and pushed out as testing
> for the autobuilders to play with it.

Hi Jonathan

  Great! Thanks for taking these

Yixun


Re: omap4-droid4: voice call support was Re: [PATCHv5,5/5] ARM: dts: omap4-droid4: add soundcard

2018-03-30 Thread Pavel Machek
On Thu 2018-03-29 14:56:13, Tony Lindgren wrote:
> * Pavel Machek  [180329 18:41]:
> > Thanks. I got call working including outgoing audio: in capture
> > settings, right->mic 1, Mic1 + Mic2 in alsamixer -> 100%. But I had
> > the other phone muted, so I don't yet know if such call would be of
> > usable quality.
> 
> Great, good to hear that :)

I also got ofonod to work, with rather crazy hacks. But I now have
incoming/outgoing calls with GUI :-).

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


signature.asc
Description: Digital signature


Re: omap4-droid4: voice call support was Re: [PATCHv5,5/5] ARM: dts: omap4-droid4: add soundcard

2018-03-30 Thread Pavel Machek
On Thu 2018-03-29 14:56:13, Tony Lindgren wrote:
> * Pavel Machek  [180329 18:41]:
> > Thanks. I got call working including outgoing audio: in capture
> > settings, right->mic 1, Mic1 + Mic2 in alsamixer -> 100%. But I had
> > the other phone muted, so I don't yet know if such call would be of
> > usable quality.
> 
> Great, good to hear that :)

I also got ofonod to work, with rather crazy hacks. But I now have
incoming/outgoing calls with GUI :-).

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


signature.asc
Description: Digital signature


Re: [PATCH v7 09/14] mm, dev_pagemap: introduce CONFIG_DEV_PAGEMAP_OPS

2018-03-30 Thread Jan Kara
On Wed 21-03-18 15:57:59, Dan Williams wrote:
> The HMM sub-system extended dev_pagemap to arrange a callback when a
> dev_pagemap managed page is freed. Since a dev_pagemap page is free /
> idle when its reference count is 1 it requires an additional branch to
> check the page-type at put_page() time. Given put_page() is a hot-path
> we do not want to incur that check if HMM is not in use, so a static
> branch is used to avoid that overhead when not necessary.
> 
> Now, the FS_DAX implementation wants to reuse this mechanism for
> receiving dev_pagemap ->page_free() callbacks. Rework the HMM-specific
> static-key into a generic mechanism that either HMM or FS_DAX code paths
> can enable.
> 
> Cc: Michal Hocko 
> Reviewed-by: "Jérôme Glisse" 
> Signed-off-by: Dan Williams 

Looks good to me. You can add:

Reviewed-by: Jan Kara 

Honza

> ---
>  drivers/dax/super.c  |2 ++
>  fs/Kconfig   |1 +
>  include/linux/memremap.h |   20 ++-
>  include/linux/mm.h   |   61 
> --
>  kernel/memremap.c|   30 ---
>  mm/Kconfig   |5 
>  mm/hmm.c |   13 ++
>  mm/swap.c|3 ++
>  8 files changed, 84 insertions(+), 51 deletions(-)
> 
> diff --git a/drivers/dax/super.c b/drivers/dax/super.c
> index ecefe9f7eb60..619b1ed6434c 100644
> --- a/drivers/dax/super.c
> +++ b/drivers/dax/super.c
> @@ -191,6 +191,7 @@ struct dax_device *fs_dax_claim_bdev(struct block_device 
> *bdev, void *owner)
>   return NULL;
>   }
>  
> + dev_pagemap_get_ops();
>   pgmap->type = MEMORY_DEVICE_FS_DAX;
>   pgmap->page_free = generic_dax_pagefree;
>   pgmap->data = owner;
> @@ -215,6 +216,7 @@ void fs_dax_release(struct dax_device *dax_dev, void 
> *owner)
>   pgmap->type = MEMORY_DEVICE_HOST;
>   pgmap->page_free = NULL;
>   pgmap->data = NULL;
> + dev_pagemap_put_ops();
>   mutex_unlock(_lock);
>  }
>  EXPORT_SYMBOL_GPL(fs_dax_release);
> diff --git a/fs/Kconfig b/fs/Kconfig
> index bc821a86d965..1f0832bbc32f 100644
> --- a/fs/Kconfig
> +++ b/fs/Kconfig
> @@ -38,6 +38,7 @@ config FS_DAX
>   bool "Direct Access (DAX) support"
>   depends on MMU
>   depends on !(ARM || MIPS || SPARC)
> + select DEV_PAGEMAP_OPS
>   select FS_IOMAP
>   select DAX
>   help
> diff --git a/include/linux/memremap.h b/include/linux/memremap.h
> index 02d6d042ee7f..9faf25d6abef 100644
> --- a/include/linux/memremap.h
> +++ b/include/linux/memremap.h
> @@ -1,7 +1,6 @@
>  /* SPDX-License-Identifier: GPL-2.0 */
>  #ifndef _LINUX_MEMREMAP_H_
>  #define _LINUX_MEMREMAP_H_
> -#include 
>  #include 
>  #include 
>  
> @@ -130,6 +129,9 @@ struct dev_pagemap {
>   enum memory_type type;
>  };
>  
> +void dev_pagemap_get_ops(void);
> +void dev_pagemap_put_ops(void);
> +
>  #ifdef CONFIG_ZONE_DEVICE
>  void *devm_memremap_pages(struct device *dev, struct dev_pagemap *pgmap);
>  struct dev_pagemap *get_dev_pagemap(unsigned long pfn,
> @@ -137,8 +139,6 @@ struct dev_pagemap *get_dev_pagemap(unsigned long pfn,
>  
>  unsigned long vmem_altmap_offset(struct vmem_altmap *altmap);
>  void vmem_altmap_free(struct vmem_altmap *altmap, unsigned long nr_pfns);
> -
> -static inline bool is_zone_device_page(const struct page *page);
>  #else
>  static inline void *devm_memremap_pages(struct device *dev,
>   struct dev_pagemap *pgmap)
> @@ -169,20 +169,6 @@ static inline void vmem_altmap_free(struct vmem_altmap 
> *altmap,
>  }
>  #endif /* CONFIG_ZONE_DEVICE */
>  
> -#if defined(CONFIG_DEVICE_PRIVATE) || defined(CONFIG_DEVICE_PUBLIC)
> -static inline bool is_device_private_page(const struct page *page)
> -{
> - return is_zone_device_page(page) &&
> - page->pgmap->type == MEMORY_DEVICE_PRIVATE;
> -}
> -
> -static inline bool is_device_public_page(const struct page *page)
> -{
> - return is_zone_device_page(page) &&
> - page->pgmap->type == MEMORY_DEVICE_PUBLIC;
> -}
> -#endif /* CONFIG_DEVICE_PRIVATE || CONFIG_DEVICE_PUBLIC */
> -
>  static inline void put_dev_pagemap(struct dev_pagemap *pgmap)
>  {
>   if (pgmap)
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index ad06d42adb1a..088c76bce360 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -812,27 +812,55 @@ static inline bool is_zone_device_page(const struct 
> page *page)
>  }
>  #endif
>  
> -#if defined(CONFIG_DEVICE_PRIVATE) || defined(CONFIG_DEVICE_PUBLIC)
> -void put_zone_device_private_or_public_page(struct page *page);
> -DECLARE_STATIC_KEY_FALSE(device_private_key);
> -#define IS_HMM_ENABLED static_branch_unlikely(_private_key)
> -static inline bool is_device_private_page(const struct page *page);
> -static inline bool is_device_public_page(const struct page *page);
> 

Re: [PATCH v7 09/14] mm, dev_pagemap: introduce CONFIG_DEV_PAGEMAP_OPS

2018-03-30 Thread Jan Kara
On Wed 21-03-18 15:57:59, Dan Williams wrote:
> The HMM sub-system extended dev_pagemap to arrange a callback when a
> dev_pagemap managed page is freed. Since a dev_pagemap page is free /
> idle when its reference count is 1 it requires an additional branch to
> check the page-type at put_page() time. Given put_page() is a hot-path
> we do not want to incur that check if HMM is not in use, so a static
> branch is used to avoid that overhead when not necessary.
> 
> Now, the FS_DAX implementation wants to reuse this mechanism for
> receiving dev_pagemap ->page_free() callbacks. Rework the HMM-specific
> static-key into a generic mechanism that either HMM or FS_DAX code paths
> can enable.
> 
> Cc: Michal Hocko 
> Reviewed-by: "Jérôme Glisse" 
> Signed-off-by: Dan Williams 

Looks good to me. You can add:

Reviewed-by: Jan Kara 

Honza

> ---
>  drivers/dax/super.c  |2 ++
>  fs/Kconfig   |1 +
>  include/linux/memremap.h |   20 ++-
>  include/linux/mm.h   |   61 
> --
>  kernel/memremap.c|   30 ---
>  mm/Kconfig   |5 
>  mm/hmm.c |   13 ++
>  mm/swap.c|3 ++
>  8 files changed, 84 insertions(+), 51 deletions(-)
> 
> diff --git a/drivers/dax/super.c b/drivers/dax/super.c
> index ecefe9f7eb60..619b1ed6434c 100644
> --- a/drivers/dax/super.c
> +++ b/drivers/dax/super.c
> @@ -191,6 +191,7 @@ struct dax_device *fs_dax_claim_bdev(struct block_device 
> *bdev, void *owner)
>   return NULL;
>   }
>  
> + dev_pagemap_get_ops();
>   pgmap->type = MEMORY_DEVICE_FS_DAX;
>   pgmap->page_free = generic_dax_pagefree;
>   pgmap->data = owner;
> @@ -215,6 +216,7 @@ void fs_dax_release(struct dax_device *dax_dev, void 
> *owner)
>   pgmap->type = MEMORY_DEVICE_HOST;
>   pgmap->page_free = NULL;
>   pgmap->data = NULL;
> + dev_pagemap_put_ops();
>   mutex_unlock(_lock);
>  }
>  EXPORT_SYMBOL_GPL(fs_dax_release);
> diff --git a/fs/Kconfig b/fs/Kconfig
> index bc821a86d965..1f0832bbc32f 100644
> --- a/fs/Kconfig
> +++ b/fs/Kconfig
> @@ -38,6 +38,7 @@ config FS_DAX
>   bool "Direct Access (DAX) support"
>   depends on MMU
>   depends on !(ARM || MIPS || SPARC)
> + select DEV_PAGEMAP_OPS
>   select FS_IOMAP
>   select DAX
>   help
> diff --git a/include/linux/memremap.h b/include/linux/memremap.h
> index 02d6d042ee7f..9faf25d6abef 100644
> --- a/include/linux/memremap.h
> +++ b/include/linux/memremap.h
> @@ -1,7 +1,6 @@
>  /* SPDX-License-Identifier: GPL-2.0 */
>  #ifndef _LINUX_MEMREMAP_H_
>  #define _LINUX_MEMREMAP_H_
> -#include 
>  #include 
>  #include 
>  
> @@ -130,6 +129,9 @@ struct dev_pagemap {
>   enum memory_type type;
>  };
>  
> +void dev_pagemap_get_ops(void);
> +void dev_pagemap_put_ops(void);
> +
>  #ifdef CONFIG_ZONE_DEVICE
>  void *devm_memremap_pages(struct device *dev, struct dev_pagemap *pgmap);
>  struct dev_pagemap *get_dev_pagemap(unsigned long pfn,
> @@ -137,8 +139,6 @@ struct dev_pagemap *get_dev_pagemap(unsigned long pfn,
>  
>  unsigned long vmem_altmap_offset(struct vmem_altmap *altmap);
>  void vmem_altmap_free(struct vmem_altmap *altmap, unsigned long nr_pfns);
> -
> -static inline bool is_zone_device_page(const struct page *page);
>  #else
>  static inline void *devm_memremap_pages(struct device *dev,
>   struct dev_pagemap *pgmap)
> @@ -169,20 +169,6 @@ static inline void vmem_altmap_free(struct vmem_altmap 
> *altmap,
>  }
>  #endif /* CONFIG_ZONE_DEVICE */
>  
> -#if defined(CONFIG_DEVICE_PRIVATE) || defined(CONFIG_DEVICE_PUBLIC)
> -static inline bool is_device_private_page(const struct page *page)
> -{
> - return is_zone_device_page(page) &&
> - page->pgmap->type == MEMORY_DEVICE_PRIVATE;
> -}
> -
> -static inline bool is_device_public_page(const struct page *page)
> -{
> - return is_zone_device_page(page) &&
> - page->pgmap->type == MEMORY_DEVICE_PUBLIC;
> -}
> -#endif /* CONFIG_DEVICE_PRIVATE || CONFIG_DEVICE_PUBLIC */
> -
>  static inline void put_dev_pagemap(struct dev_pagemap *pgmap)
>  {
>   if (pgmap)
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index ad06d42adb1a..088c76bce360 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -812,27 +812,55 @@ static inline bool is_zone_device_page(const struct 
> page *page)
>  }
>  #endif
>  
> -#if defined(CONFIG_DEVICE_PRIVATE) || defined(CONFIG_DEVICE_PUBLIC)
> -void put_zone_device_private_or_public_page(struct page *page);
> -DECLARE_STATIC_KEY_FALSE(device_private_key);
> -#define IS_HMM_ENABLED static_branch_unlikely(_private_key)
> -static inline bool is_device_private_page(const struct page *page);
> -static inline bool is_device_public_page(const struct page *page);
> -#else /* CONFIG_DEVICE_PRIVATE || CONFIG_DEVICE_PUBLIC */
> -static inline void 

[PATCH v2 2/2] net: mvneta: improve suspend/resume

2018-03-30 Thread Jisheng Zhang
Current suspend/resume implementation reuses the mvneta_open() and
mvneta_close(), but it could be optimized to take only necessary
actions during suspend/resume.

One obvious problem of current implementation is: after hundreds of
system suspend/resume cycles, the resume of mvneta could fail due to
fragmented dma coherent memory. After this patch, the non-necessary
memory alloc/free is optimized out.

Signed-off-by: Jisheng Zhang 
---
 drivers/net/ethernet/marvell/mvneta.c | 71 ++-
 1 file changed, 61 insertions(+), 10 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mvneta.c 
b/drivers/net/ethernet/marvell/mvneta.c
index f96815853108..cb7fce99ed6d 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -4586,16 +4586,43 @@ static int mvneta_remove(struct platform_device *pdev)
 #ifdef CONFIG_PM_SLEEP
 static int mvneta_suspend(struct device *device)
 {
+   int queue;
struct net_device *dev = dev_get_drvdata(device);
struct mvneta_port *pp = netdev_priv(dev);
 
-   rtnl_lock();
-   if (netif_running(dev))
-   mvneta_stop(dev);
-   rtnl_unlock();
+   if (!netif_running(dev))
+   goto clean_exit;
+
+   if (!pp->neta_armada3700) {
+   spin_lock(>lock);
+   pp->is_stopped = true;
+   spin_unlock(>lock);
+
+   cpuhp_state_remove_instance_nocalls(online_hpstate,
+   >node_online);
+   cpuhp_state_remove_instance_nocalls(CPUHP_NET_MVNETA_DEAD,
+   >node_dead);
+   }
+
+   mvneta_stop_dev(pp);
+
+   for (queue = 0; queue < rxq_number; queue++) {
+   struct mvneta_rx_queue *rxq = >rxqs[queue];
+
+   mvneta_rxq_drop_pkts(pp, rxq);
+   }
+
+   for (queue = 0; queue < txq_number; queue++) {
+   struct mvneta_tx_queue *txq = >txqs[queue];
+
+   mvneta_txq_hw_deinit(pp, txq);
+   }
+
+clean_exit:
netif_device_detach(dev);
clk_disable_unprepare(pp->clk_bus);
clk_disable_unprepare(pp->clk);
+
return 0;
 }
 
@@ -4604,7 +4631,7 @@ static int mvneta_resume(struct device *device)
struct platform_device *pdev = to_platform_device(device);
struct net_device *dev = dev_get_drvdata(device);
struct mvneta_port *pp = netdev_priv(dev);
-   int err;
+   int err, queue;
 
clk_prepare_enable(pp->clk);
if (!IS_ERR(pp->clk_bus))
@@ -4626,12 +4653,36 @@ static int mvneta_resume(struct device *device)
}
 
netif_device_attach(dev);
-   rtnl_lock();
-   if (netif_running(dev)) {
-   mvneta_open(dev);
-   mvneta_set_rx_mode(dev);
+
+   if (!netif_running(dev))
+   return 0;
+
+   for (queue = 0; queue < rxq_number; queue++) {
+   struct mvneta_rx_queue *rxq = >rxqs[queue];
+
+   rxq->next_desc_to_proc = 0;
+   mvneta_rxq_hw_init(pp, rxq);
}
-   rtnl_unlock();
+
+   for (queue = 0; queue < txq_number; queue++) {
+   struct mvneta_tx_queue *txq = >txqs[queue];
+
+   txq->next_desc_to_proc = 0;
+   mvneta_txq_hw_init(pp, txq);
+   }
+
+   if (!pp->neta_armada3700) {
+   spin_lock(>lock);
+   pp->is_stopped = false;
+   spin_unlock(>lock);
+   cpuhp_state_add_instance_nocalls(online_hpstate,
+>node_online);
+   cpuhp_state_add_instance_nocalls(CPUHP_NET_MVNETA_DEAD,
+>node_dead);
+   }
+
+   mvneta_start_dev(pp);
+   mvneta_set_rx_mode(dev);
 
return 0;
 }
-- 
2.16.3



[PATCH v2 2/2] net: mvneta: improve suspend/resume

2018-03-30 Thread Jisheng Zhang
Current suspend/resume implementation reuses the mvneta_open() and
mvneta_close(), but it could be optimized to take only necessary
actions during suspend/resume.

One obvious problem of current implementation is: after hundreds of
system suspend/resume cycles, the resume of mvneta could fail due to
fragmented dma coherent memory. After this patch, the non-necessary
memory alloc/free is optimized out.

Signed-off-by: Jisheng Zhang 
---
 drivers/net/ethernet/marvell/mvneta.c | 71 ++-
 1 file changed, 61 insertions(+), 10 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mvneta.c 
b/drivers/net/ethernet/marvell/mvneta.c
index f96815853108..cb7fce99ed6d 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -4586,16 +4586,43 @@ static int mvneta_remove(struct platform_device *pdev)
 #ifdef CONFIG_PM_SLEEP
 static int mvneta_suspend(struct device *device)
 {
+   int queue;
struct net_device *dev = dev_get_drvdata(device);
struct mvneta_port *pp = netdev_priv(dev);
 
-   rtnl_lock();
-   if (netif_running(dev))
-   mvneta_stop(dev);
-   rtnl_unlock();
+   if (!netif_running(dev))
+   goto clean_exit;
+
+   if (!pp->neta_armada3700) {
+   spin_lock(>lock);
+   pp->is_stopped = true;
+   spin_unlock(>lock);
+
+   cpuhp_state_remove_instance_nocalls(online_hpstate,
+   >node_online);
+   cpuhp_state_remove_instance_nocalls(CPUHP_NET_MVNETA_DEAD,
+   >node_dead);
+   }
+
+   mvneta_stop_dev(pp);
+
+   for (queue = 0; queue < rxq_number; queue++) {
+   struct mvneta_rx_queue *rxq = >rxqs[queue];
+
+   mvneta_rxq_drop_pkts(pp, rxq);
+   }
+
+   for (queue = 0; queue < txq_number; queue++) {
+   struct mvneta_tx_queue *txq = >txqs[queue];
+
+   mvneta_txq_hw_deinit(pp, txq);
+   }
+
+clean_exit:
netif_device_detach(dev);
clk_disable_unprepare(pp->clk_bus);
clk_disable_unprepare(pp->clk);
+
return 0;
 }
 
@@ -4604,7 +4631,7 @@ static int mvneta_resume(struct device *device)
struct platform_device *pdev = to_platform_device(device);
struct net_device *dev = dev_get_drvdata(device);
struct mvneta_port *pp = netdev_priv(dev);
-   int err;
+   int err, queue;
 
clk_prepare_enable(pp->clk);
if (!IS_ERR(pp->clk_bus))
@@ -4626,12 +4653,36 @@ static int mvneta_resume(struct device *device)
}
 
netif_device_attach(dev);
-   rtnl_lock();
-   if (netif_running(dev)) {
-   mvneta_open(dev);
-   mvneta_set_rx_mode(dev);
+
+   if (!netif_running(dev))
+   return 0;
+
+   for (queue = 0; queue < rxq_number; queue++) {
+   struct mvneta_rx_queue *rxq = >rxqs[queue];
+
+   rxq->next_desc_to_proc = 0;
+   mvneta_rxq_hw_init(pp, rxq);
}
-   rtnl_unlock();
+
+   for (queue = 0; queue < txq_number; queue++) {
+   struct mvneta_tx_queue *txq = >txqs[queue];
+
+   txq->next_desc_to_proc = 0;
+   mvneta_txq_hw_init(pp, txq);
+   }
+
+   if (!pp->neta_armada3700) {
+   spin_lock(>lock);
+   pp->is_stopped = false;
+   spin_unlock(>lock);
+   cpuhp_state_add_instance_nocalls(online_hpstate,
+>node_online);
+   cpuhp_state_add_instance_nocalls(CPUHP_NET_MVNETA_DEAD,
+>node_dead);
+   }
+
+   mvneta_start_dev(pp);
+   mvneta_set_rx_mode(dev);
 
return 0;
 }
-- 
2.16.3



[PATCH v2 1/2] net: mvneta: split rxq/txq init and txq deinit into SW and HW parts

2018-03-30 Thread Jisheng Zhang
This is to prepare the suspend/resume improvement in next patch. The
SW parts can be optimized out during resume.

As for rxq handling during suspend, we'd like to drop packets by
calling mvneta_rxq_drop_pkts() which is both SW and HW operation,
so we don't split rxq deinit.

Signed-off-by: Jisheng Zhang 
---
 drivers/net/ethernet/marvell/mvneta.c | 85 +++
 1 file changed, 66 insertions(+), 19 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mvneta.c 
b/drivers/net/ethernet/marvell/mvneta.c
index 30aab9bf77cc..f96815853108 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -2796,10 +2796,8 @@ static void mvneta_rx_reset(struct mvneta_port *pp)
 
 /* Rx/Tx queue initialization/cleanup methods */
 
-/* Create a specified RX queue */
-static int mvneta_rxq_init(struct mvneta_port *pp,
-  struct mvneta_rx_queue *rxq)
-
+static int mvneta_rxq_sw_init(struct mvneta_port *pp,
+ struct mvneta_rx_queue *rxq)
 {
rxq->size = pp->rx_ring_size;
 
@@ -2812,6 +2810,12 @@ static int mvneta_rxq_init(struct mvneta_port *pp,
 
rxq->last_desc = rxq->size - 1;
 
+   return 0;
+}
+
+static void mvneta_rxq_hw_init(struct mvneta_port *pp,
+  struct mvneta_rx_queue *rxq)
+{
/* Set Rx descriptors queue starting address */
mvreg_write(pp, MVNETA_RXQ_BASE_ADDR_REG(rxq->id), rxq->descs_phys);
mvreg_write(pp, MVNETA_RXQ_SIZE_REG(rxq->id), rxq->size);
@@ -2835,6 +2839,20 @@ static int mvneta_rxq_init(struct mvneta_port *pp,
mvneta_rxq_short_pool_set(pp, rxq);
mvneta_rxq_non_occup_desc_add(pp, rxq, rxq->size);
}
+}
+
+/* Create a specified RX queue */
+static int mvneta_rxq_init(struct mvneta_port *pp,
+  struct mvneta_rx_queue *rxq)
+
+{
+   int ret;
+
+   ret = mvneta_rxq_sw_init(pp, rxq);
+   if (ret < 0)
+   return ret;
+
+   mvneta_rxq_hw_init(pp, rxq);
 
return 0;
 }
@@ -2857,9 +2875,8 @@ static void mvneta_rxq_deinit(struct mvneta_port *pp,
rxq->descs_phys= 0;
 }
 
-/* Create and initialize a tx queue */
-static int mvneta_txq_init(struct mvneta_port *pp,
-  struct mvneta_tx_queue *txq)
+static int mvneta_txq_sw_init(struct mvneta_port *pp,
+ struct mvneta_tx_queue *txq)
 {
int cpu;
 
@@ -2872,7 +2889,6 @@ static int mvneta_txq_init(struct mvneta_port *pp,
txq->tx_stop_threshold = txq->size - MVNETA_MAX_SKB_DESCS;
txq->tx_wake_threshold = txq->tx_stop_threshold / 2;
 
-
/* Allocate memory for TX descriptors */
txq->descs = dma_alloc_coherent(pp->dev->dev.parent,
txq->size * MVNETA_DESC_ALIGNED_SIZE,
@@ -2882,14 +2898,6 @@ static int mvneta_txq_init(struct mvneta_port *pp,
 
txq->last_desc = txq->size - 1;
 
-   /* Set maximum bandwidth for enabled TXQs */
-   mvreg_write(pp, MVETH_TXQ_TOKEN_CFG_REG(txq->id), 0x03ff);
-   mvreg_write(pp, MVETH_TXQ_TOKEN_COUNT_REG(txq->id), 0x3fff);
-
-   /* Set Tx descriptors queue starting address */
-   mvreg_write(pp, MVNETA_TXQ_BASE_ADDR_REG(txq->id), txq->descs_phys);
-   mvreg_write(pp, MVNETA_TXQ_SIZE_REG(txq->id), txq->size);
-
txq->tx_skb = kmalloc_array(txq->size, sizeof(*txq->tx_skb),
GFP_KERNEL);
if (!txq->tx_skb) {
@@ -2910,7 +2918,6 @@ static int mvneta_txq_init(struct mvneta_port *pp,
  txq->descs, txq->descs_phys);
return -ENOMEM;
}
-   mvneta_tx_done_pkts_coal_set(pp, txq, txq->done_pkts_coal);
 
/* Setup XPS mapping */
if (txq_number > 1)
@@ -2923,9 +2930,38 @@ static int mvneta_txq_init(struct mvneta_port *pp,
return 0;
 }
 
+static void mvneta_txq_hw_init(struct mvneta_port *pp,
+  struct mvneta_tx_queue *txq)
+{
+   /* Set maximum bandwidth for enabled TXQs */
+   mvreg_write(pp, MVETH_TXQ_TOKEN_CFG_REG(txq->id), 0x03ff);
+   mvreg_write(pp, MVETH_TXQ_TOKEN_COUNT_REG(txq->id), 0x3fff);
+
+   /* Set Tx descriptors queue starting address */
+   mvreg_write(pp, MVNETA_TXQ_BASE_ADDR_REG(txq->id), txq->descs_phys);
+   mvreg_write(pp, MVNETA_TXQ_SIZE_REG(txq->id), txq->size);
+
+   mvneta_tx_done_pkts_coal_set(pp, txq, txq->done_pkts_coal);
+}
+
+/* Create and initialize a tx queue */
+static int mvneta_txq_init(struct mvneta_port *pp,
+  struct mvneta_tx_queue *txq)
+{
+   int ret;
+
+   ret = mvneta_txq_sw_init(pp, txq);
+   if (ret < 0)
+   return ret;
+
+   mvneta_txq_hw_init(pp, txq);
+
+   return 0;
+}
+
 /* Free allocated resources when mvneta_txq_init() fails to allocate memory*/
-static void 

[PATCH v2 1/2] net: mvneta: split rxq/txq init and txq deinit into SW and HW parts

2018-03-30 Thread Jisheng Zhang
This is to prepare the suspend/resume improvement in next patch. The
SW parts can be optimized out during resume.

As for rxq handling during suspend, we'd like to drop packets by
calling mvneta_rxq_drop_pkts() which is both SW and HW operation,
so we don't split rxq deinit.

Signed-off-by: Jisheng Zhang 
---
 drivers/net/ethernet/marvell/mvneta.c | 85 +++
 1 file changed, 66 insertions(+), 19 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mvneta.c 
b/drivers/net/ethernet/marvell/mvneta.c
index 30aab9bf77cc..f96815853108 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -2796,10 +2796,8 @@ static void mvneta_rx_reset(struct mvneta_port *pp)
 
 /* Rx/Tx queue initialization/cleanup methods */
 
-/* Create a specified RX queue */
-static int mvneta_rxq_init(struct mvneta_port *pp,
-  struct mvneta_rx_queue *rxq)
-
+static int mvneta_rxq_sw_init(struct mvneta_port *pp,
+ struct mvneta_rx_queue *rxq)
 {
rxq->size = pp->rx_ring_size;
 
@@ -2812,6 +2810,12 @@ static int mvneta_rxq_init(struct mvneta_port *pp,
 
rxq->last_desc = rxq->size - 1;
 
+   return 0;
+}
+
+static void mvneta_rxq_hw_init(struct mvneta_port *pp,
+  struct mvneta_rx_queue *rxq)
+{
/* Set Rx descriptors queue starting address */
mvreg_write(pp, MVNETA_RXQ_BASE_ADDR_REG(rxq->id), rxq->descs_phys);
mvreg_write(pp, MVNETA_RXQ_SIZE_REG(rxq->id), rxq->size);
@@ -2835,6 +2839,20 @@ static int mvneta_rxq_init(struct mvneta_port *pp,
mvneta_rxq_short_pool_set(pp, rxq);
mvneta_rxq_non_occup_desc_add(pp, rxq, rxq->size);
}
+}
+
+/* Create a specified RX queue */
+static int mvneta_rxq_init(struct mvneta_port *pp,
+  struct mvneta_rx_queue *rxq)
+
+{
+   int ret;
+
+   ret = mvneta_rxq_sw_init(pp, rxq);
+   if (ret < 0)
+   return ret;
+
+   mvneta_rxq_hw_init(pp, rxq);
 
return 0;
 }
@@ -2857,9 +2875,8 @@ static void mvneta_rxq_deinit(struct mvneta_port *pp,
rxq->descs_phys= 0;
 }
 
-/* Create and initialize a tx queue */
-static int mvneta_txq_init(struct mvneta_port *pp,
-  struct mvneta_tx_queue *txq)
+static int mvneta_txq_sw_init(struct mvneta_port *pp,
+ struct mvneta_tx_queue *txq)
 {
int cpu;
 
@@ -2872,7 +2889,6 @@ static int mvneta_txq_init(struct mvneta_port *pp,
txq->tx_stop_threshold = txq->size - MVNETA_MAX_SKB_DESCS;
txq->tx_wake_threshold = txq->tx_stop_threshold / 2;
 
-
/* Allocate memory for TX descriptors */
txq->descs = dma_alloc_coherent(pp->dev->dev.parent,
txq->size * MVNETA_DESC_ALIGNED_SIZE,
@@ -2882,14 +2898,6 @@ static int mvneta_txq_init(struct mvneta_port *pp,
 
txq->last_desc = txq->size - 1;
 
-   /* Set maximum bandwidth for enabled TXQs */
-   mvreg_write(pp, MVETH_TXQ_TOKEN_CFG_REG(txq->id), 0x03ff);
-   mvreg_write(pp, MVETH_TXQ_TOKEN_COUNT_REG(txq->id), 0x3fff);
-
-   /* Set Tx descriptors queue starting address */
-   mvreg_write(pp, MVNETA_TXQ_BASE_ADDR_REG(txq->id), txq->descs_phys);
-   mvreg_write(pp, MVNETA_TXQ_SIZE_REG(txq->id), txq->size);
-
txq->tx_skb = kmalloc_array(txq->size, sizeof(*txq->tx_skb),
GFP_KERNEL);
if (!txq->tx_skb) {
@@ -2910,7 +2918,6 @@ static int mvneta_txq_init(struct mvneta_port *pp,
  txq->descs, txq->descs_phys);
return -ENOMEM;
}
-   mvneta_tx_done_pkts_coal_set(pp, txq, txq->done_pkts_coal);
 
/* Setup XPS mapping */
if (txq_number > 1)
@@ -2923,9 +2930,38 @@ static int mvneta_txq_init(struct mvneta_port *pp,
return 0;
 }
 
+static void mvneta_txq_hw_init(struct mvneta_port *pp,
+  struct mvneta_tx_queue *txq)
+{
+   /* Set maximum bandwidth for enabled TXQs */
+   mvreg_write(pp, MVETH_TXQ_TOKEN_CFG_REG(txq->id), 0x03ff);
+   mvreg_write(pp, MVETH_TXQ_TOKEN_COUNT_REG(txq->id), 0x3fff);
+
+   /* Set Tx descriptors queue starting address */
+   mvreg_write(pp, MVNETA_TXQ_BASE_ADDR_REG(txq->id), txq->descs_phys);
+   mvreg_write(pp, MVNETA_TXQ_SIZE_REG(txq->id), txq->size);
+
+   mvneta_tx_done_pkts_coal_set(pp, txq, txq->done_pkts_coal);
+}
+
+/* Create and initialize a tx queue */
+static int mvneta_txq_init(struct mvneta_port *pp,
+  struct mvneta_tx_queue *txq)
+{
+   int ret;
+
+   ret = mvneta_txq_sw_init(pp, txq);
+   if (ret < 0)
+   return ret;
+
+   mvneta_txq_hw_init(pp, txq);
+
+   return 0;
+}
+
 /* Free allocated resources when mvneta_txq_init() fails to allocate memory*/
-static void mvneta_txq_deinit(struct mvneta_port *pp,

[PATCH v2 0/2] net: mvneta: improve suspend/resume

2018-03-30 Thread Jisheng Zhang
This series tries to optimize the mvneta's suspend/resume
implementation by only taking necessary actions.

Since v1:
 - unify ret check
 - try best to keep the suspend/resume behavior
 - split txq deinit into sw/hw parts as well
 - adjust mvneta_stop_dev() location

I didn't add Thomas's Ack tag to patch1, because in v2, I added new code
to split the txq deinit into two parts.

Jisheng Zhang (2):
  net: mvneta: split rxq/txq init and txq deinit into SW and HW parts
  net: mvneta: improve suspend/resume

 drivers/net/ethernet/marvell/mvneta.c | 156 +++---
 1 file changed, 127 insertions(+), 29 deletions(-)

-- 
2.16.3



[PATCH v2 0/2] net: mvneta: improve suspend/resume

2018-03-30 Thread Jisheng Zhang
This series tries to optimize the mvneta's suspend/resume
implementation by only taking necessary actions.

Since v1:
 - unify ret check
 - try best to keep the suspend/resume behavior
 - split txq deinit into sw/hw parts as well
 - adjust mvneta_stop_dev() location

I didn't add Thomas's Ack tag to patch1, because in v2, I added new code
to split the txq deinit into two parts.

Jisheng Zhang (2):
  net: mvneta: split rxq/txq init and txq deinit into SW and HW parts
  net: mvneta: improve suspend/resume

 drivers/net/ethernet/marvell/mvneta.c | 156 +++---
 1 file changed, 127 insertions(+), 29 deletions(-)

-- 
2.16.3



Re: [PATCH 1/2] x86/mce: new centaur CPUs support MCE broadcasting

2018-03-30 Thread Borislav Petkov
On Fri, Mar 30, 2018 at 05:53:41PM +0800, David Wang wrote:
> This patch is used to tell the kernel that newer Centaur CPU support MCE
> broadcasting.
> 
> Signed-off-by: David Wang 
> ---
>  arch/x86/kernel/cpu/mcheck/mce.c | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/arch/x86/kernel/cpu/mcheck/mce.c 
> b/arch/x86/kernel/cpu/mcheck/mce.c
> index 7065846..82b25e1 100644
> --- a/arch/x86/kernel/cpu/mcheck/mce.c
> +++ b/arch/x86/kernel/cpu/mcheck/mce.c
> @@ -1688,6 +1688,17 @@ static int __mcheck_cpu_apply_quirks(struct 
> cpuinfo_x86 *c)
>   if (c->x86 == 6 && c->x86_model == 45)
>   quirk_no_way_out = quirk_sandybridge_ifu;
>   }
> +
> + if (c->x86_vendor == X86_VENDOR_CENTAUR) {
> + /*
> +  * All newer centaur CPUs support MCE broadcasting. Enable
> +  * synchronization with a one second timeout.
> +  */
> + if ((c->x86 > 6 || (c->x86 == 6 && c->x86_model == 0xf && 
> c->x86_mask >=0xe)) &&

Are some specs or manuals available somewhere on the web for those?

Thx.

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.


Re: [PATCH 1/2] x86/mce: new centaur CPUs support MCE broadcasting

2018-03-30 Thread Borislav Petkov
On Fri, Mar 30, 2018 at 05:53:41PM +0800, David Wang wrote:
> This patch is used to tell the kernel that newer Centaur CPU support MCE
> broadcasting.
> 
> Signed-off-by: David Wang 
> ---
>  arch/x86/kernel/cpu/mcheck/mce.c | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/arch/x86/kernel/cpu/mcheck/mce.c 
> b/arch/x86/kernel/cpu/mcheck/mce.c
> index 7065846..82b25e1 100644
> --- a/arch/x86/kernel/cpu/mcheck/mce.c
> +++ b/arch/x86/kernel/cpu/mcheck/mce.c
> @@ -1688,6 +1688,17 @@ static int __mcheck_cpu_apply_quirks(struct 
> cpuinfo_x86 *c)
>   if (c->x86 == 6 && c->x86_model == 45)
>   quirk_no_way_out = quirk_sandybridge_ifu;
>   }
> +
> + if (c->x86_vendor == X86_VENDOR_CENTAUR) {
> + /*
> +  * All newer centaur CPUs support MCE broadcasting. Enable
> +  * synchronization with a one second timeout.
> +  */
> + if ((c->x86 > 6 || (c->x86 == 6 && c->x86_model == 0xf && 
> c->x86_mask >=0xe)) &&

Are some specs or manuals available somewhere on the web for those?

Thx.

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.


Re: [PATCH v2] PM / wakeup: use seq_open() to show wakeup stats

2018-03-30 Thread Rafael J. Wysocki
On Monday, March 5, 2018 9:47:46 AM CEST Ganesh Mahendran wrote:
> single_open() interface requires that the whole output must
> fit into a single buffer. This will lead to timeout when
> system memory is not in a good situation.
> 
> This patch use seq_open() to show wakeup stats. This method
> need only one page, so timeout will not be observed.
> 
> Signed-off-by: Ganesh Mahendran 
> 
> v2: use srcu_read_lock instead of rcu_read_lock
> ---
>  drivers/base/power/wakeup.c | 77 
> +++--
>  1 file changed, 61 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/base/power/wakeup.c b/drivers/base/power/wakeup.c
> index ea01621..3bcab7d 100644
> --- a/drivers/base/power/wakeup.c
> +++ b/drivers/base/power/wakeup.c
> @@ -1029,32 +1029,77 @@ static int print_wakeup_source_stats(struct seq_file 
> *m,
>   return 0;
>  }
>  
> -/**
> - * wakeup_sources_stats_show - Print wakeup sources statistics information.
> - * @m: seq_file to print the statistics into.
> - */
> -static int wakeup_sources_stats_show(struct seq_file *m, void *unused)
> +static void *wakeup_sources_stats_seq_start(struct seq_file *m,
> + loff_t *pos)
>  {
>   struct wakeup_source *ws;
> - int srcuidx;
> + loff_t n = *pos;
> + int *srcuidx = m->private;
>  
> - seq_puts(m, "name\t\tactive_count\tevent_count\twakeup_count\t"
> - "expire_count\tactive_since\ttotal_time\tmax_time\t"
> - "last_change\tprevent_suspend_time\n");
> + if (n == 0) {
> + seq_puts(m, "name\t\tactive_count\tevent_count\twakeup_count\t"
> + "expire_count\tactive_since\ttotal_time\tmax_time\t"
> + "last_change\tprevent_suspend_time\n");
> + }
>  
> - srcuidx = srcu_read_lock(_srcu);
> - list_for_each_entry_rcu(ws, _sources, entry)
> - print_wakeup_source_stats(m, ws);
> - srcu_read_unlock(_srcu, srcuidx);
> + *srcuidx = srcu_read_lock(_srcu);
> + list_for_each_entry_rcu(ws, _sources, entry) {
> + if (n-- > 0)
> + continue;
> + goto out;
> + }
> + ws = NULL;
> +out:
> + return ws;
> +}

Please clean up the above at least.

If I'm not mistaken, you don't need the label and the goto here.



Re: [PATCH v2] PM / wakeup: use seq_open() to show wakeup stats

2018-03-30 Thread Rafael J. Wysocki
On Monday, March 5, 2018 9:47:46 AM CEST Ganesh Mahendran wrote:
> single_open() interface requires that the whole output must
> fit into a single buffer. This will lead to timeout when
> system memory is not in a good situation.
> 
> This patch use seq_open() to show wakeup stats. This method
> need only one page, so timeout will not be observed.
> 
> Signed-off-by: Ganesh Mahendran 
> 
> v2: use srcu_read_lock instead of rcu_read_lock
> ---
>  drivers/base/power/wakeup.c | 77 
> +++--
>  1 file changed, 61 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/base/power/wakeup.c b/drivers/base/power/wakeup.c
> index ea01621..3bcab7d 100644
> --- a/drivers/base/power/wakeup.c
> +++ b/drivers/base/power/wakeup.c
> @@ -1029,32 +1029,77 @@ static int print_wakeup_source_stats(struct seq_file 
> *m,
>   return 0;
>  }
>  
> -/**
> - * wakeup_sources_stats_show - Print wakeup sources statistics information.
> - * @m: seq_file to print the statistics into.
> - */
> -static int wakeup_sources_stats_show(struct seq_file *m, void *unused)
> +static void *wakeup_sources_stats_seq_start(struct seq_file *m,
> + loff_t *pos)
>  {
>   struct wakeup_source *ws;
> - int srcuidx;
> + loff_t n = *pos;
> + int *srcuidx = m->private;
>  
> - seq_puts(m, "name\t\tactive_count\tevent_count\twakeup_count\t"
> - "expire_count\tactive_since\ttotal_time\tmax_time\t"
> - "last_change\tprevent_suspend_time\n");
> + if (n == 0) {
> + seq_puts(m, "name\t\tactive_count\tevent_count\twakeup_count\t"
> + "expire_count\tactive_since\ttotal_time\tmax_time\t"
> + "last_change\tprevent_suspend_time\n");
> + }
>  
> - srcuidx = srcu_read_lock(_srcu);
> - list_for_each_entry_rcu(ws, _sources, entry)
> - print_wakeup_source_stats(m, ws);
> - srcu_read_unlock(_srcu, srcuidx);
> + *srcuidx = srcu_read_lock(_srcu);
> + list_for_each_entry_rcu(ws, _sources, entry) {
> + if (n-- > 0)
> + continue;
> + goto out;
> + }
> + ws = NULL;
> +out:
> + return ws;
> +}

Please clean up the above at least.

If I'm not mistaken, you don't need the label and the goto here.



Re: [PATCH] net: mvneta: fix enable of all initialized RXQs

2018-03-30 Thread Thomas Petazzoni
Hello,

On Fri, 30 Mar 2018 12:05:31 +0200, Gregory CLEMENT wrote:
> From: Yelena Krivosheev 
> 
> In mvneta_port_up() we enable relevant RX and TX port queues by write
> queues bit map to an appropriate register.
> 
> q_map must be ZERO in the beginning of this process.
> 
> Signed-off-by: Yelena Krivosheev 
> Signed-off-by: Gregory CLEMENT 

Acked-by: Thomas Petazzoni 

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


Re: [PATCH] net: mvneta: fix enable of all initialized RXQs

2018-03-30 Thread Thomas Petazzoni
Hello,

On Fri, 30 Mar 2018 12:05:31 +0200, Gregory CLEMENT wrote:
> From: Yelena Krivosheev 
> 
> In mvneta_port_up() we enable relevant RX and TX port queues by write
> queues bit map to an appropriate register.
> 
> q_map must be ZERO in the beginning of this process.
> 
> Signed-off-by: Yelena Krivosheev 
> Signed-off-by: Gregory CLEMENT 

Acked-by: Thomas Petazzoni 

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


[PATCH] staging: fsl-dpaa2/ethsw: Remove unused variable irq

2018-03-30 Thread Nguyen Phan Quang Minh
Local variable irq is not used. Remove it.

Signed-off-by: Nguyen Phan Quang Minh
---
 drivers/staging/fsl-dpaa2/ethsw/ethsw.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/staging/fsl-dpaa2/ethsw/ethsw.c 
b/drivers/staging/fsl-dpaa2/ethsw/ethsw.c
index c723a04bc3d6..a698498b8537 100644
--- a/drivers/staging/fsl-dpaa2/ethsw/ethsw.c
+++ b/drivers/staging/fsl-dpaa2/ethsw/ethsw.c
@@ -616,10 +616,8 @@ static void ethsw_teardown_irqs(struct fsl_mc_device 
*sw_dev)
 {
struct device *dev = _dev->dev;
struct ethsw_core *ethsw = dev_get_drvdata(dev);
-   struct fsl_mc_device_irq *irq;
int err;
 
-   irq = sw_dev->irqs[DPSW_IRQ_INDEX_IF];
err = dpsw_set_irq_enable(ethsw->mc_io, 0, ethsw->dpsw_handle,
  DPSW_IRQ_INDEX_IF, 0);
if (err)
-- 
2.15.1



[PATCH] staging: fsl-dpaa2/ethsw: Remove unused variable irq

2018-03-30 Thread Nguyen Phan Quang Minh
Local variable irq is not used. Remove it.

Signed-off-by: Nguyen Phan Quang Minh
---
 drivers/staging/fsl-dpaa2/ethsw/ethsw.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/staging/fsl-dpaa2/ethsw/ethsw.c 
b/drivers/staging/fsl-dpaa2/ethsw/ethsw.c
index c723a04bc3d6..a698498b8537 100644
--- a/drivers/staging/fsl-dpaa2/ethsw/ethsw.c
+++ b/drivers/staging/fsl-dpaa2/ethsw/ethsw.c
@@ -616,10 +616,8 @@ static void ethsw_teardown_irqs(struct fsl_mc_device 
*sw_dev)
 {
struct device *dev = _dev->dev;
struct ethsw_core *ethsw = dev_get_drvdata(dev);
-   struct fsl_mc_device_irq *irq;
int err;
 
-   irq = sw_dev->irqs[DPSW_IRQ_INDEX_IF];
err = dpsw_set_irq_enable(ethsw->mc_io, 0, ethsw->dpsw_handle,
  DPSW_IRQ_INDEX_IF, 0);
if (err)
-- 
2.15.1



Re: [PATCH] cpufreq: cppc: Use transition_delay_us depending on the transition_latency

2018-03-30 Thread Rafael J. Wysocki
On Friday, March 23, 2018 11:30:31 AM CEST George Cherian wrote:
> With commit e948bc8fbee0 ("cpufreq: Cap the default transition delay
> value to 10 ms")  the cpufreq was not honouring the delay passed via
> ACPI (PCCT). Due to which on ARM based platforms using CPPC the cpufreq
> governor tries to change the frequency of CPU faster than expeted.
> 
> This leads to continuous error messages like the following.
> " ACPI CPPC: PCC check channel failed. Status=0 "
> 
> Earlier (without above commit) the default transition delay was
> taken form the value passed from PCCT. Use the same value provided by PCCT
> to set the transition_delay_us.
> 
> Fixes: e948bc8fbee0 (cpufreq: Cap the default transition delay value to 10 ms)
> Signed-off-by: George Cherian 
> ---
>  drivers/cpufreq/cppc_cpufreq.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/cpufreq/cppc_cpufreq.c b/drivers/cpufreq/cppc_cpufreq.c
> index a1c3025..dcb1cb9 100644
> --- a/drivers/cpufreq/cppc_cpufreq.c
> +++ b/drivers/cpufreq/cppc_cpufreq.c
> @@ -20,6 +20,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #include 
> @@ -162,6 +163,8 @@ static int cppc_cpufreq_cpu_init(struct cpufreq_policy 
> *policy)
>   policy->cpuinfo.max_freq = cppc_dmi_max_khz;
>  
>   policy->cpuinfo.transition_latency = 
> cppc_get_transition_latency(cpu_num);
> + policy->transition_delay_us = cppc_get_transition_latency(cpu_num) /
> + NSEC_PER_USEC;
>   policy->shared_type = cpu->shared_type;
>  
>   if (policy->shared_type == CPUFREQ_SHARED_TYPE_ANY)
> 

Applied, thanks!




Re: [PATCH] cpufreq: cppc: Use transition_delay_us depending on the transition_latency

2018-03-30 Thread Rafael J. Wysocki
On Friday, March 23, 2018 11:30:31 AM CEST George Cherian wrote:
> With commit e948bc8fbee0 ("cpufreq: Cap the default transition delay
> value to 10 ms")  the cpufreq was not honouring the delay passed via
> ACPI (PCCT). Due to which on ARM based platforms using CPPC the cpufreq
> governor tries to change the frequency of CPU faster than expeted.
> 
> This leads to continuous error messages like the following.
> " ACPI CPPC: PCC check channel failed. Status=0 "
> 
> Earlier (without above commit) the default transition delay was
> taken form the value passed from PCCT. Use the same value provided by PCCT
> to set the transition_delay_us.
> 
> Fixes: e948bc8fbee0 (cpufreq: Cap the default transition delay value to 10 ms)
> Signed-off-by: George Cherian 
> ---
>  drivers/cpufreq/cppc_cpufreq.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/cpufreq/cppc_cpufreq.c b/drivers/cpufreq/cppc_cpufreq.c
> index a1c3025..dcb1cb9 100644
> --- a/drivers/cpufreq/cppc_cpufreq.c
> +++ b/drivers/cpufreq/cppc_cpufreq.c
> @@ -20,6 +20,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #include 
> @@ -162,6 +163,8 @@ static int cppc_cpufreq_cpu_init(struct cpufreq_policy 
> *policy)
>   policy->cpuinfo.max_freq = cppc_dmi_max_khz;
>  
>   policy->cpuinfo.transition_latency = 
> cppc_get_transition_latency(cpu_num);
> + policy->transition_delay_us = cppc_get_transition_latency(cpu_num) /
> + NSEC_PER_USEC;
>   policy->shared_type = cpu->shared_type;
>  
>   if (policy->shared_type == CPUFREQ_SHARED_TYPE_ANY)
> 

Applied, thanks!




Re: [PATCH 0/7] use struct pt_regs based syscall calling for x86-64

2018-03-30 Thread Ingo Molnar

* Dominik Brodowski  wrote:

> A few questions remain, from important stuff to bikeshedding:
> 
> 1) Is it acceptable to pass the existing struct pt_regs to the sys_*()
>kernel functions in emulate_vsyscall(), or should it use a hand-crafted
>struct pt_regs instead?

I think so: we already have task_pt_regs() which gives access to the real 
return 
registers on the kernel stack.

I think as long as we constify the pointer, we should pass in the real thing.

> 2) Is it the right approach to generate the __sys32_ia32_*() names to
>include in the syscall table on-the-fly, or should they all be listed
>in arch/x86/entry/syscalls/syscall_32.tbl ?

I think as a general principle all system call tables should point to the 
first-hop wrapper symbol name (i.e. __sys32_ia32_*() in this case), not to the 
generic symbol name - even though we could generate the former from the latter.

The more indirection in these tables, the harder to read they become I think.

> 3) I have chosen to name the default 64-bit syscall stub sys_*(), same as
>the "normal" syscall, and the IA32_EMULATION compat syscall stub
>compat_sys_*(), same as the "normal" compat syscall. Though this
>might cause some confusion, as the "same" function uses a different
>calling convention and different parameters on x86, it has the
>advantages that
> - the kernel *has* a function sys_*() implementing the syscall,
>   so those curious in stack traces etc. will find it in plain
>   sight,
> - it is easier to handle in the syscall table generation, and
> - error injection works the same.

I don't think there should be a symbol space overlap, that will only lead to 
confusion. The symbols can be _similar_, with a prefix, underscores or so, but 
they shouldn't match I think.

> The whole series is available at
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/brodo/linux.git 
> syscalls-WIP

BTW., I'd like all these bits to go through the x86 tree.

What is the expected merge route of the generic preparatory bits?

Thanks,

Ingo


Re: [PATCH 0/7] use struct pt_regs based syscall calling for x86-64

2018-03-30 Thread Ingo Molnar

* Dominik Brodowski  wrote:

> A few questions remain, from important stuff to bikeshedding:
> 
> 1) Is it acceptable to pass the existing struct pt_regs to the sys_*()
>kernel functions in emulate_vsyscall(), or should it use a hand-crafted
>struct pt_regs instead?

I think so: we already have task_pt_regs() which gives access to the real 
return 
registers on the kernel stack.

I think as long as we constify the pointer, we should pass in the real thing.

> 2) Is it the right approach to generate the __sys32_ia32_*() names to
>include in the syscall table on-the-fly, or should they all be listed
>in arch/x86/entry/syscalls/syscall_32.tbl ?

I think as a general principle all system call tables should point to the 
first-hop wrapper symbol name (i.e. __sys32_ia32_*() in this case), not to the 
generic symbol name - even though we could generate the former from the latter.

The more indirection in these tables, the harder to read they become I think.

> 3) I have chosen to name the default 64-bit syscall stub sys_*(), same as
>the "normal" syscall, and the IA32_EMULATION compat syscall stub
>compat_sys_*(), same as the "normal" compat syscall. Though this
>might cause some confusion, as the "same" function uses a different
>calling convention and different parameters on x86, it has the
>advantages that
> - the kernel *has* a function sys_*() implementing the syscall,
>   so those curious in stack traces etc. will find it in plain
>   sight,
> - it is easier to handle in the syscall table generation, and
> - error injection works the same.

I don't think there should be a symbol space overlap, that will only lead to 
confusion. The symbols can be _similar_, with a prefix, underscores or so, but 
they shouldn't match I think.

> The whole series is available at
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/brodo/linux.git 
> syscalls-WIP

BTW., I'd like all these bits to go through the x86 tree.

What is the expected merge route of the generic preparatory bits?

Thanks,

Ingo


Re: [PATCH 7/7] x86/entry/64: extend register clearing on syscall entry to lower registers

2018-03-30 Thread Ingo Molnar

* Dominik Brodowski  wrote:

>   .endif
>   pushq   \rdx/* pt_regs->dx */
> + xorl%edx, %edx  /* nosepc   dx */
>   pushq   %rcx/* pt_regs->cx */
> + xorl%ecx, %ecx  /* nosepc   cx */
>   pushq   \rax/* pt_regs->ax */
>   pushq   %r8 /* pt_regs->r8 */
>   xorl%r8d, %r8d  /* nospec   r8 */
> diff --git a/arch/x86/entry/entry_64_compat.S 
> b/arch/x86/entry/entry_64_compat.S
> index 08425c42f8b7..23e0945959e5 100644
> --- a/arch/x86/entry/entry_64_compat.S
> +++ b/arch/x86/entry/entry_64_compat.S
> @@ -220,8 +220,11 @@ GLOBAL(entry_SYSCALL_compat_after_hwframe)
>   pushq   %rax/* pt_regs->orig_ax */
>   pushq   %rdi/* pt_regs->di */
>   pushq   %rsi/* pt_regs->si */
> + xorl%esi, %esi  /* nosepc   si */
>   pushq   %rdx/* pt_regs->dx */
> + xorl%edx, %edx  /* nosepc   dx */
>   pushq   %rbp/* pt_regs->cx (stashed in bp) */
> + xorl%ecx, %ecx  /* nosepc   cx */
>   pushq   $-ENOSYS/* pt_regs->ax */
>   pushq   $0  /* pt_regs->r8  = 0 */
>   xorl%r8d, %r8d  /* nospec   r8 */
> @@ -365,8 +368,11 @@ ENTRY(entry_INT80_compat)
>  
>   pushq   (%rdi)  /* pt_regs->di */
>   pushq   %rsi/* pt_regs->si */
> + xorl%esi, %esi  /* nosepc   si */
>   pushq   %rdx/* pt_regs->dx */
> + xorl%edx, %edx  /* nosepc   dx */
>   pushq   %rcx/* pt_regs->cx */
> + xorl%ecx, %ecx  /* nosepc   cx */
>   pushq   $-ENOSYS/* pt_regs->ax */
>   pushq   $0  /* pt_regs->r8  = 0 */
>   xorl%r8d, %r8d  /* nospec   r8 */

s/nosepc
 /nospec

Thanks,

Ingo


Re: [PATCH 7/7] x86/entry/64: extend register clearing on syscall entry to lower registers

2018-03-30 Thread Ingo Molnar

* Dominik Brodowski  wrote:

>   .endif
>   pushq   \rdx/* pt_regs->dx */
> + xorl%edx, %edx  /* nosepc   dx */
>   pushq   %rcx/* pt_regs->cx */
> + xorl%ecx, %ecx  /* nosepc   cx */
>   pushq   \rax/* pt_regs->ax */
>   pushq   %r8 /* pt_regs->r8 */
>   xorl%r8d, %r8d  /* nospec   r8 */
> diff --git a/arch/x86/entry/entry_64_compat.S 
> b/arch/x86/entry/entry_64_compat.S
> index 08425c42f8b7..23e0945959e5 100644
> --- a/arch/x86/entry/entry_64_compat.S
> +++ b/arch/x86/entry/entry_64_compat.S
> @@ -220,8 +220,11 @@ GLOBAL(entry_SYSCALL_compat_after_hwframe)
>   pushq   %rax/* pt_regs->orig_ax */
>   pushq   %rdi/* pt_regs->di */
>   pushq   %rsi/* pt_regs->si */
> + xorl%esi, %esi  /* nosepc   si */
>   pushq   %rdx/* pt_regs->dx */
> + xorl%edx, %edx  /* nosepc   dx */
>   pushq   %rbp/* pt_regs->cx (stashed in bp) */
> + xorl%ecx, %ecx  /* nosepc   cx */
>   pushq   $-ENOSYS/* pt_regs->ax */
>   pushq   $0  /* pt_regs->r8  = 0 */
>   xorl%r8d, %r8d  /* nospec   r8 */
> @@ -365,8 +368,11 @@ ENTRY(entry_INT80_compat)
>  
>   pushq   (%rdi)  /* pt_regs->di */
>   pushq   %rsi/* pt_regs->si */
> + xorl%esi, %esi  /* nosepc   si */
>   pushq   %rdx/* pt_regs->dx */
> + xorl%edx, %edx  /* nosepc   dx */
>   pushq   %rcx/* pt_regs->cx */
> + xorl%ecx, %ecx  /* nosepc   cx */
>   pushq   $-ENOSYS/* pt_regs->ax */
>   pushq   $0  /* pt_regs->r8  = 0 */
>   xorl%r8d, %r8d  /* nospec   r8 */

s/nosepc
 /nospec

Thanks,

Ingo


Re: [PATCH] ACPI: acpi_pad: Fix memory leak in power saving threads

2018-03-30 Thread Rafael J. Wysocki
On Tuesday, March 27, 2018 3:56:40 PM CEST Lenny Szubowicz wrote:
> Fix once per second (round_robin_time) memory leak of about 1 KB in
> each acpi_pad kernel idling thread that is activated.
> 
> Found by testing with kmemleak.
> 
> Signed-off-by: Lenny Szubowicz 
> ---
>  drivers/acpi/acpi_pad.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/acpi/acpi_pad.c b/drivers/acpi/acpi_pad.c
> index 7544310..552c1f7 100644
> --- a/drivers/acpi/acpi_pad.c
> +++ b/drivers/acpi/acpi_pad.c
> @@ -110,6 +110,7 @@ static void round_robin_cpu(unsigned int tsk_index)
>   cpumask_andnot(tmp, cpu_online_mask, pad_busy_cpus);
>   if (cpumask_empty(tmp)) {
>   mutex_unlock(_robin_lock);
> + free_cpumask_var(tmp);
>   return;
>   }
>   for_each_cpu(cpu, tmp) {
> @@ -127,6 +128,8 @@ static void round_robin_cpu(unsigned int tsk_index)
>   mutex_unlock(_robin_lock);
>  
>   set_cpus_allowed_ptr(current, cpumask_of(preferred_cpu));
> +
> + free_cpumask_var(tmp);
>  }
>  
>  static void exit_round_robin(unsigned int tsk_index)
> 

Applied, thanks!




Re: [PATCH] ACPI: acpi_pad: Fix memory leak in power saving threads

2018-03-30 Thread Rafael J. Wysocki
On Tuesday, March 27, 2018 3:56:40 PM CEST Lenny Szubowicz wrote:
> Fix once per second (round_robin_time) memory leak of about 1 KB in
> each acpi_pad kernel idling thread that is activated.
> 
> Found by testing with kmemleak.
> 
> Signed-off-by: Lenny Szubowicz 
> ---
>  drivers/acpi/acpi_pad.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/acpi/acpi_pad.c b/drivers/acpi/acpi_pad.c
> index 7544310..552c1f7 100644
> --- a/drivers/acpi/acpi_pad.c
> +++ b/drivers/acpi/acpi_pad.c
> @@ -110,6 +110,7 @@ static void round_robin_cpu(unsigned int tsk_index)
>   cpumask_andnot(tmp, cpu_online_mask, pad_busy_cpus);
>   if (cpumask_empty(tmp)) {
>   mutex_unlock(_robin_lock);
> + free_cpumask_var(tmp);
>   return;
>   }
>   for_each_cpu(cpu, tmp) {
> @@ -127,6 +128,8 @@ static void round_robin_cpu(unsigned int tsk_index)
>   mutex_unlock(_robin_lock);
>  
>   set_cpus_allowed_ptr(current, cpumask_of(preferred_cpu));
> +
> + free_cpumask_var(tmp);
>  }
>  
>  static void exit_round_robin(unsigned int tsk_index)
> 

Applied, thanks!




Re: [PATCH v3 2/2] power/hibernate: Change message when writing to /sys/power/resume

2018-03-30 Thread Rafael J. Wysocki
On Wednesday, March 28, 2018 7:01:10 PM CEST Mario Limonciello wrote:
> This file is used both for setting the wakeup device without kernel
> command line as well as for actually waking the system (when appropriate
> swap header is in place).
> 
> To avoid confusion on incorrect logs in system log downgrade the
> message to debug and make it clearer.
> 
> Signed-off-by: Mario Limonciello 
> ---
>  kernel/power/hibernate.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
> index d58fad3d..1028ecb 100644
> --- a/kernel/power/hibernate.c
> +++ b/kernel/power/hibernate.c
> @@ -1053,7 +1053,7 @@ static ssize_t resume_store(struct kobject *kobj, 
> struct kobj_attribute *attr,
>   lock_system_sleep();
>   swsusp_resume_device = res;
>   unlock_system_sleep();
> - pr_info("Starting manual resume from disk\n");
> + pm_pr_dbg("Configured resume from disk to %u\n", swsusp_resume_device);
>   noresume = 0;
>   software_resume();
>   return n;
> 

Both [1-2/2] applied, thanks!




Re: [PATCH v3 2/2] power/hibernate: Change message when writing to /sys/power/resume

2018-03-30 Thread Rafael J. Wysocki
On Wednesday, March 28, 2018 7:01:10 PM CEST Mario Limonciello wrote:
> This file is used both for setting the wakeup device without kernel
> command line as well as for actually waking the system (when appropriate
> swap header is in place).
> 
> To avoid confusion on incorrect logs in system log downgrade the
> message to debug and make it clearer.
> 
> Signed-off-by: Mario Limonciello 
> ---
>  kernel/power/hibernate.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
> index d58fad3d..1028ecb 100644
> --- a/kernel/power/hibernate.c
> +++ b/kernel/power/hibernate.c
> @@ -1053,7 +1053,7 @@ static ssize_t resume_store(struct kobject *kobj, 
> struct kobj_attribute *attr,
>   lock_system_sleep();
>   swsusp_resume_device = res;
>   unlock_system_sleep();
> - pr_info("Starting manual resume from disk\n");
> + pm_pr_dbg("Configured resume from disk to %u\n", swsusp_resume_device);
>   noresume = 0;
>   software_resume();
>   return n;
> 

Both [1-2/2] applied, thanks!




[PATCH] net: mvneta: fix enable of all initialized RXQs

2018-03-30 Thread Gregory CLEMENT
From: Yelena Krivosheev 

In mvneta_port_up() we enable relevant RX and TX port queues by write
queues bit map to an appropriate register.

q_map must be ZERO in the beginning of this process.

Signed-off-by: Yelena Krivosheev 
Signed-off-by: Gregory CLEMENT 
---
 drivers/net/ethernet/marvell/mvneta.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/marvell/mvneta.c 
b/drivers/net/ethernet/marvell/mvneta.c
index 25e9a551cc8c..3f6fb635738c 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -1132,6 +1132,7 @@ static void mvneta_port_up(struct mvneta_port *pp)
}
mvreg_write(pp, MVNETA_TXQ_CMD, q_map);
 
+   q_map = 0;
/* Enable all initialized RXQs. */
for (queue = 0; queue < rxq_number; queue++) {
struct mvneta_rx_queue *rxq = >rxqs[queue];
-- 
2.16.2



[PATCH] net: mvneta: fix enable of all initialized RXQs

2018-03-30 Thread Gregory CLEMENT
From: Yelena Krivosheev 

In mvneta_port_up() we enable relevant RX and TX port queues by write
queues bit map to an appropriate register.

q_map must be ZERO in the beginning of this process.

Signed-off-by: Yelena Krivosheev 
Signed-off-by: Gregory CLEMENT 
---
 drivers/net/ethernet/marvell/mvneta.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/marvell/mvneta.c 
b/drivers/net/ethernet/marvell/mvneta.c
index 25e9a551cc8c..3f6fb635738c 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -1132,6 +1132,7 @@ static void mvneta_port_up(struct mvneta_port *pp)
}
mvreg_write(pp, MVNETA_TXQ_CMD, q_map);
 
+   q_map = 0;
/* Enable all initialized RXQs. */
for (queue = 0; queue < rxq_number; queue++) {
struct mvneta_rx_queue *rxq = >rxqs[queue];
-- 
2.16.2



[PATCH v3 2/6] mfd: stm32-timers: add support for dmas

2018-03-30 Thread Fabrice Gasnier
STM32 Timers can support up to 7 DMA requests:
- 4 channels, update, compare and trigger.
Optionally request part, or all DMAs from stm32-timers MFD core.

Also add routine to implement burst reads using DMA from timer registers.
This is exported. So, it can be used by child drivers, PWM capture
for instance (but not limited to).

Signed-off-by: Fabrice Gasnier 
Reviewed-by: Benjamin Gaignard 
---
Changes in v3:
- Basically Lee's comments:
- rather create a struct stm32_timers_dma, and place a reference to it
  in existing ddata (instead of adding priv struct).
- rather use a struct device in exported routine prototype, and use
  standard helpers instead of ddata. Get rid of to_stm32_timers_priv().
- simplify error handling in probe (remove a goto)
- comment on devm_of_platform_*populate() usage.

Changes in v2:
- Abstract DMA handling from child driver: move it to MFD core
- Add comments on optional dma support
---
 drivers/mfd/stm32-timers.c   | 219 ++-
 include/linux/mfd/stm32-timers.h |  32 ++
 2 files changed, 249 insertions(+), 2 deletions(-)

diff --git a/drivers/mfd/stm32-timers.c b/drivers/mfd/stm32-timers.c
index 1d347e5..98191ec 100644
--- a/drivers/mfd/stm32-timers.c
+++ b/drivers/mfd/stm32-timers.c
@@ -4,16 +4,165 @@
  * Author: Benjamin Gaignard 
  */
 
+#include 
+#include 
+#include 
 #include 
 #include 
 #include 
 #include 
 
+#define STM32_TIMERS_MAX_REGISTERS 0x3fc
+
+struct stm32_timers_dma {
+   struct completion completion;
+   phys_addr_t phys_base;
+   struct mutex lock;  /* protect dma access */
+   struct dma_chan *chan;
+   struct dma_chan *chans[STM32_TIMERS_MAX_DMAS];
+};
+
+/* DIER register DMA enable bits */
+static const u32 stm32_timers_dier_dmaen[STM32_TIMERS_MAX_DMAS] = {
+   TIM_DIER_CC1DE,
+   TIM_DIER_CC2DE,
+   TIM_DIER_CC3DE,
+   TIM_DIER_CC4DE,
+   TIM_DIER_UIE,
+   TIM_DIER_TDE,
+   TIM_DIER_COMDE
+};
+
+static void stm32_timers_dma_done(void *p)
+{
+   struct stm32_timers_dma *dma = p;
+   struct dma_tx_state state;
+   enum dma_status status;
+
+   status = dmaengine_tx_status(dma->chan, dma->chan->cookie, );
+   if (status == DMA_COMPLETE)
+   complete(>completion);
+}
+
+/**
+ * stm32_timers_dma_burst_read - Read from timers registers using DMA.
+ *
+ * Read from STM32 timers registers using DMA on a single event.
+ * @dev: reference to stm32_timers MFD device
+ * @buf: dma'able destination buffer
+ * @id: stm32_timers_dmas event identifier (ch[1..4], up, trig or com)
+ * @reg: registers start offset for DMA to read from (like CCRx for capture)
+ * @num_reg: number of registers to read upon each dma request, starting @reg.
+ * @bursts: number of bursts to read (e.g. like two for pwm period capture)
+ * @tmo_ms: timeout (milliseconds)
+ */
+int stm32_timers_dma_burst_read(struct device *dev, u32 *buf,
+   enum stm32_timers_dmas id, u32 reg,
+   unsigned int num_reg, unsigned int bursts,
+   unsigned long tmo_ms)
+{
+   struct stm32_timers *ddata = dev_get_drvdata(dev);
+   unsigned long timeout = msecs_to_jiffies(tmo_ms);
+   struct regmap *regmap = ddata->regmap;
+   struct stm32_timers_dma *dma = ddata->dma;
+   size_t len = num_reg * bursts * sizeof(u32);
+   struct dma_async_tx_descriptor *desc;
+   struct dma_slave_config config;
+   dma_cookie_t cookie;
+   dma_addr_t dma_buf;
+   u32 dbl, dba;
+   long err;
+   int ret;
+
+   /* sanity check */
+   if (id < STM32_TIMERS_DMA_CH1 || id >= STM32_TIMERS_MAX_DMAS)
+   return -EINVAL;
+
+   if (!num_reg || !bursts || reg > STM32_TIMERS_MAX_REGISTERS ||
+   (reg + num_reg * sizeof(u32)) > STM32_TIMERS_MAX_REGISTERS)
+   return -EINVAL;
+
+   if (!dma->chans[id])
+   return -ENODEV;
+   mutex_lock(>lock);
+
+   /* select dma channel in use */
+   dma->chan = dma->chans[id];
+   dma_buf = dma_map_single(dev, buf, len, DMA_FROM_DEVICE);
+   ret = dma_mapping_error(dev, dma_buf);
+   if (ret)
+   goto unlock;
+
+   /* Prepare DMA read from timer registers, using DMA burst mode */
+   memset(, 0, sizeof(config));
+   config.src_addr = (dma_addr_t)dma->phys_base + TIM_DMAR;
+   config.src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
+   ret = dmaengine_slave_config(dma->chan, );
+   if (ret)
+   goto unmap;
+
+   desc = dmaengine_prep_slave_single(dma->chan, dma_buf, len,
+  DMA_DEV_TO_MEM, DMA_PREP_INTERRUPT);
+   if (!desc) {
+   ret = -EBUSY;
+   goto unmap;
+   }
+
+   desc->callback = stm32_timers_dma_done;
+   desc->callback_param = dma;
+   cookie = 

[PATCH v3 2/6] mfd: stm32-timers: add support for dmas

2018-03-30 Thread Fabrice Gasnier
STM32 Timers can support up to 7 DMA requests:
- 4 channels, update, compare and trigger.
Optionally request part, or all DMAs from stm32-timers MFD core.

Also add routine to implement burst reads using DMA from timer registers.
This is exported. So, it can be used by child drivers, PWM capture
for instance (but not limited to).

Signed-off-by: Fabrice Gasnier 
Reviewed-by: Benjamin Gaignard 
---
Changes in v3:
- Basically Lee's comments:
- rather create a struct stm32_timers_dma, and place a reference to it
  in existing ddata (instead of adding priv struct).
- rather use a struct device in exported routine prototype, and use
  standard helpers instead of ddata. Get rid of to_stm32_timers_priv().
- simplify error handling in probe (remove a goto)
- comment on devm_of_platform_*populate() usage.

Changes in v2:
- Abstract DMA handling from child driver: move it to MFD core
- Add comments on optional dma support
---
 drivers/mfd/stm32-timers.c   | 219 ++-
 include/linux/mfd/stm32-timers.h |  32 ++
 2 files changed, 249 insertions(+), 2 deletions(-)

diff --git a/drivers/mfd/stm32-timers.c b/drivers/mfd/stm32-timers.c
index 1d347e5..98191ec 100644
--- a/drivers/mfd/stm32-timers.c
+++ b/drivers/mfd/stm32-timers.c
@@ -4,16 +4,165 @@
  * Author: Benjamin Gaignard 
  */
 
+#include 
+#include 
+#include 
 #include 
 #include 
 #include 
 #include 
 
+#define STM32_TIMERS_MAX_REGISTERS 0x3fc
+
+struct stm32_timers_dma {
+   struct completion completion;
+   phys_addr_t phys_base;
+   struct mutex lock;  /* protect dma access */
+   struct dma_chan *chan;
+   struct dma_chan *chans[STM32_TIMERS_MAX_DMAS];
+};
+
+/* DIER register DMA enable bits */
+static const u32 stm32_timers_dier_dmaen[STM32_TIMERS_MAX_DMAS] = {
+   TIM_DIER_CC1DE,
+   TIM_DIER_CC2DE,
+   TIM_DIER_CC3DE,
+   TIM_DIER_CC4DE,
+   TIM_DIER_UIE,
+   TIM_DIER_TDE,
+   TIM_DIER_COMDE
+};
+
+static void stm32_timers_dma_done(void *p)
+{
+   struct stm32_timers_dma *dma = p;
+   struct dma_tx_state state;
+   enum dma_status status;
+
+   status = dmaengine_tx_status(dma->chan, dma->chan->cookie, );
+   if (status == DMA_COMPLETE)
+   complete(>completion);
+}
+
+/**
+ * stm32_timers_dma_burst_read - Read from timers registers using DMA.
+ *
+ * Read from STM32 timers registers using DMA on a single event.
+ * @dev: reference to stm32_timers MFD device
+ * @buf: dma'able destination buffer
+ * @id: stm32_timers_dmas event identifier (ch[1..4], up, trig or com)
+ * @reg: registers start offset for DMA to read from (like CCRx for capture)
+ * @num_reg: number of registers to read upon each dma request, starting @reg.
+ * @bursts: number of bursts to read (e.g. like two for pwm period capture)
+ * @tmo_ms: timeout (milliseconds)
+ */
+int stm32_timers_dma_burst_read(struct device *dev, u32 *buf,
+   enum stm32_timers_dmas id, u32 reg,
+   unsigned int num_reg, unsigned int bursts,
+   unsigned long tmo_ms)
+{
+   struct stm32_timers *ddata = dev_get_drvdata(dev);
+   unsigned long timeout = msecs_to_jiffies(tmo_ms);
+   struct regmap *regmap = ddata->regmap;
+   struct stm32_timers_dma *dma = ddata->dma;
+   size_t len = num_reg * bursts * sizeof(u32);
+   struct dma_async_tx_descriptor *desc;
+   struct dma_slave_config config;
+   dma_cookie_t cookie;
+   dma_addr_t dma_buf;
+   u32 dbl, dba;
+   long err;
+   int ret;
+
+   /* sanity check */
+   if (id < STM32_TIMERS_DMA_CH1 || id >= STM32_TIMERS_MAX_DMAS)
+   return -EINVAL;
+
+   if (!num_reg || !bursts || reg > STM32_TIMERS_MAX_REGISTERS ||
+   (reg + num_reg * sizeof(u32)) > STM32_TIMERS_MAX_REGISTERS)
+   return -EINVAL;
+
+   if (!dma->chans[id])
+   return -ENODEV;
+   mutex_lock(>lock);
+
+   /* select dma channel in use */
+   dma->chan = dma->chans[id];
+   dma_buf = dma_map_single(dev, buf, len, DMA_FROM_DEVICE);
+   ret = dma_mapping_error(dev, dma_buf);
+   if (ret)
+   goto unlock;
+
+   /* Prepare DMA read from timer registers, using DMA burst mode */
+   memset(, 0, sizeof(config));
+   config.src_addr = (dma_addr_t)dma->phys_base + TIM_DMAR;
+   config.src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
+   ret = dmaengine_slave_config(dma->chan, );
+   if (ret)
+   goto unmap;
+
+   desc = dmaengine_prep_slave_single(dma->chan, dma_buf, len,
+  DMA_DEV_TO_MEM, DMA_PREP_INTERRUPT);
+   if (!desc) {
+   ret = -EBUSY;
+   goto unmap;
+   }
+
+   desc->callback = stm32_timers_dma_done;
+   desc->callback_param = dma;
+   cookie = dmaengine_submit(desc);
+   ret = dma_submit_error(cookie);
+   if (ret)

Re: [PATCH v5] ANDROID: binder: change down_write to down_read

2018-03-30 Thread Greg Kroah-Hartman
On Fri, Mar 30, 2018 at 10:29:21AM +0900, Minchan Kim wrote:
> Hi Ganesh,
> 
> On Fri, Mar 30, 2018 at 09:21:55AM +0800, Ganesh Mahendran wrote:
> > 2018-03-29 14:54 GMT+08:00 Minchan Kim :
> > > binder_update_page_range needs down_write of mmap_sem because
> > > vm_insert_page need to change vma->vm_flags to VM_MIXEDMAP unless
> > > it is set. However, when I profile binder working, it seems
> > > every binder buffers should be mapped in advance by binder_mmap.
> > > It means we could set VM_MIXEDMAP in binder_mmap time which is
> > > already hold a mmap_sem as down_write so binder_update_page_range
> > > doesn't need to hold a mmap_sem as down_write.
> > >
> > > Android suffers from mmap_sem contention so let's reduce mmap_sem
> > > down_write.
> > 
> > Hi, Minchan:
> > 
> > It seems there is performance regression of this patch.
> 
> You mean "This patch aims for solving performance regression" not "This patch
> makes performance regression"?
> 
> > 
> > Do you have some test result of android app launch time or binderThroughput?
> 
> Unfortunately, I don't have any number. The goal is to reduce the number of
> call mmap_sem as write-side lock because it makes priority inversion of 
> threads
> easily and that's one of clear part I spot that we don't need write-side lock.

Please always run the binderThroughput tests when making binder changes
(there is a binder test suite in the CTS Android tests), as that ensures
that you are not causing performance regressions as well as just normal
bug regressions :)

thanks,

greg k-h


[PATCH v3 4/6] pwm: stm32: improve capture by tuning counter prescaler

2018-03-30 Thread Fabrice Gasnier
Currently, capture is based on timeout window to configure prescaler.
PWM capture framework provides 1s window at the time of writing.

There's place for improvement, after input signal has been captured once:
- Finer tune counter clock prescaler, by using 1st capture result (with
arbitrary margin).
- Do a 2nd capture, with scaled capture window.
This increases accuracy, especially at high rates.

Signed-off-by: Fabrice Gasnier 
Reviewed-by: Benjamin Gaignard 
Acked-by: Thierry Reding 
---
Changes in v2:
- Adopt DMA read from MFD core.
---
 drivers/pwm/pwm-stm32.c | 24 +++-
 1 file changed, 23 insertions(+), 1 deletion(-)

diff --git a/drivers/pwm/pwm-stm32.c b/drivers/pwm/pwm-stm32.c
index 00c6251..c6eb0a8 100644
--- a/drivers/pwm/pwm-stm32.c
+++ b/drivers/pwm/pwm-stm32.c
@@ -169,7 +169,7 @@ static int stm32_pwm_capture(struct pwm_chip *chip, struct 
pwm_device *pwm,
struct stm32_pwm *priv = to_stm32_pwm_dev(chip);
unsigned long long prd, div, dty;
unsigned long rate;
-   unsigned int psc = 0;
+   unsigned int psc = 0, scale;
u32 raw_prd, raw_dty;
int ret = 0;
 
@@ -220,6 +220,28 @@ static int stm32_pwm_capture(struct pwm_chip *chip, struct 
pwm_device *pwm,
if (ret)
goto stop;
 
+   /*
+* Got a capture. Try to improve accuracy at high rates:
+* - decrease counter clock prescaler, scale up to max rate.
+*/
+   if (raw_prd) {
+   u32 max_arr = priv->max_arr - 0x1000; /* arbitrary margin */
+
+   scale = max_arr / min(max_arr, raw_prd);
+   } else {
+   scale = priv->max_arr; /* bellow resolution, use max scale */
+   }
+
+   if (psc && scale > 1) {
+   /* 2nd measure with new scale */
+   psc /= scale;
+   regmap_write(priv->regmap, TIM_PSC, psc);
+   ret = stm32_pwm_raw_capture(priv, pwm, tmo_ms, _prd,
+   _dty);
+   if (ret)
+   goto stop;
+   }
+
prd = (unsigned long long)raw_prd * (psc + 1) * NSEC_PER_SEC;
result->period = DIV_ROUND_UP_ULL(prd, rate);
dty = (unsigned long long)raw_dty * (psc + 1) * NSEC_PER_SEC;
-- 
1.9.1



Re: [PATCH v5] ANDROID: binder: change down_write to down_read

2018-03-30 Thread Greg Kroah-Hartman
On Fri, Mar 30, 2018 at 10:29:21AM +0900, Minchan Kim wrote:
> Hi Ganesh,
> 
> On Fri, Mar 30, 2018 at 09:21:55AM +0800, Ganesh Mahendran wrote:
> > 2018-03-29 14:54 GMT+08:00 Minchan Kim :
> > > binder_update_page_range needs down_write of mmap_sem because
> > > vm_insert_page need to change vma->vm_flags to VM_MIXEDMAP unless
> > > it is set. However, when I profile binder working, it seems
> > > every binder buffers should be mapped in advance by binder_mmap.
> > > It means we could set VM_MIXEDMAP in binder_mmap time which is
> > > already hold a mmap_sem as down_write so binder_update_page_range
> > > doesn't need to hold a mmap_sem as down_write.
> > >
> > > Android suffers from mmap_sem contention so let's reduce mmap_sem
> > > down_write.
> > 
> > Hi, Minchan:
> > 
> > It seems there is performance regression of this patch.
> 
> You mean "This patch aims for solving performance regression" not "This patch
> makes performance regression"?
> 
> > 
> > Do you have some test result of android app launch time or binderThroughput?
> 
> Unfortunately, I don't have any number. The goal is to reduce the number of
> call mmap_sem as write-side lock because it makes priority inversion of 
> threads
> easily and that's one of clear part I spot that we don't need write-side lock.

Please always run the binderThroughput tests when making binder changes
(there is a binder test suite in the CTS Android tests), as that ensures
that you are not causing performance regressions as well as just normal
bug regressions :)

thanks,

greg k-h


[PATCH v3 4/6] pwm: stm32: improve capture by tuning counter prescaler

2018-03-30 Thread Fabrice Gasnier
Currently, capture is based on timeout window to configure prescaler.
PWM capture framework provides 1s window at the time of writing.

There's place for improvement, after input signal has been captured once:
- Finer tune counter clock prescaler, by using 1st capture result (with
arbitrary margin).
- Do a 2nd capture, with scaled capture window.
This increases accuracy, especially at high rates.

Signed-off-by: Fabrice Gasnier 
Reviewed-by: Benjamin Gaignard 
Acked-by: Thierry Reding 
---
Changes in v2:
- Adopt DMA read from MFD core.
---
 drivers/pwm/pwm-stm32.c | 24 +++-
 1 file changed, 23 insertions(+), 1 deletion(-)

diff --git a/drivers/pwm/pwm-stm32.c b/drivers/pwm/pwm-stm32.c
index 00c6251..c6eb0a8 100644
--- a/drivers/pwm/pwm-stm32.c
+++ b/drivers/pwm/pwm-stm32.c
@@ -169,7 +169,7 @@ static int stm32_pwm_capture(struct pwm_chip *chip, struct 
pwm_device *pwm,
struct stm32_pwm *priv = to_stm32_pwm_dev(chip);
unsigned long long prd, div, dty;
unsigned long rate;
-   unsigned int psc = 0;
+   unsigned int psc = 0, scale;
u32 raw_prd, raw_dty;
int ret = 0;
 
@@ -220,6 +220,28 @@ static int stm32_pwm_capture(struct pwm_chip *chip, struct 
pwm_device *pwm,
if (ret)
goto stop;
 
+   /*
+* Got a capture. Try to improve accuracy at high rates:
+* - decrease counter clock prescaler, scale up to max rate.
+*/
+   if (raw_prd) {
+   u32 max_arr = priv->max_arr - 0x1000; /* arbitrary margin */
+
+   scale = max_arr / min(max_arr, raw_prd);
+   } else {
+   scale = priv->max_arr; /* bellow resolution, use max scale */
+   }
+
+   if (psc && scale > 1) {
+   /* 2nd measure with new scale */
+   psc /= scale;
+   regmap_write(priv->regmap, TIM_PSC, psc);
+   ret = stm32_pwm_raw_capture(priv, pwm, tmo_ms, _prd,
+   _dty);
+   if (ret)
+   goto stop;
+   }
+
prd = (unsigned long long)raw_prd * (psc + 1) * NSEC_PER_SEC;
result->period = DIV_ROUND_UP_ULL(prd, rate);
dty = (unsigned long long)raw_dty * (psc + 1) * NSEC_PER_SEC;
-- 
1.9.1



[PATCH v3 3/6] pwm: stm32: add capture support

2018-03-30 Thread Fabrice Gasnier
Add support for PMW input mode on pwm-stm32. STM32 timers support
period and duty cycle capture as long as they have at least two PWM
channels. One capture channel is used for period (rising-edge), one
for duty-cycle (falling-edge).
When there's only one channel available, only period can be captured.
Duty-cycle is simply zero'ed in such a case.

Capture requires exclusive access (e.g. no pwm output running at the
same time, to protect common prescaler).
Timer DMA burst mode (from MFD core) is being used, to take two
snapshots of capture registers (upon each period rising edge).

Signed-off-by: Fabrice Gasnier 
Reviewed-by: Benjamin Gaignard 
Acked-by: Thierry Reding 
---
Changes in v3:
- update stm32_timers_dma_burst_read() call: don't pass ddata structure,
  use MFD parent device structure instead since MFD core update.

Changes in v2:
- DMA handling has been moved to MFD core. Rework capture routines to
  use it.
---
 drivers/pwm/pwm-stm32.c  | 176 +++
 include/linux/mfd/stm32-timers.h |  11 +++
 2 files changed, 187 insertions(+)

diff --git a/drivers/pwm/pwm-stm32.c b/drivers/pwm/pwm-stm32.c
index 3ac55df..00c6251 100644
--- a/drivers/pwm/pwm-stm32.c
+++ b/drivers/pwm/pwm-stm32.c
@@ -26,6 +26,7 @@ struct stm32_pwm {
struct regmap *regmap;
u32 max_arr;
bool have_complementary_output;
+   u32 capture[4] cacheline_aligned; /* DMA'able buffer */
 };
 
 struct stm32_breakinput {
@@ -63,6 +64,178 @@ static int write_ccrx(struct stm32_pwm *dev, int ch, u32 
value)
return -EINVAL;
 }
 
+#define TIM_CCER_CC12P (TIM_CCER_CC1P | TIM_CCER_CC2P)
+#define TIM_CCER_CC12E (TIM_CCER_CC1E | TIM_CCER_CC2E)
+#define TIM_CCER_CC34P (TIM_CCER_CC3P | TIM_CCER_CC4P)
+#define TIM_CCER_CC34E (TIM_CCER_CC3E | TIM_CCER_CC4E)
+
+/*
+ * Capture using PWM input mode:
+ *  ___  ___
+ * TI[1, 2, 3 or 4]: ._|   ||
+ * ^0  ^1   ^2
+ *  .   ..
+ *  .   .X
+ *  .   .   X |
+ *  .  X .|
+ *X ..|
+ * COUNTER:__X  .   ..|_XXX
+ * start^   .   ..^stop
+ *  .   .   ..
+ *  v   v   .v
+ *  v
+ * CCR1/CCR3:   tx..t0...t2
+ * CCR2/CCR4:   tx..t1.
+ *
+ * DMA burst transfer:  ||
+ *  vv
+ * DMA buffer:  { t0, tx }   { t2, t1 }
+ * DMA done: ^
+ *
+ * 0: IC1/3 snapchot on rising edge: counter value -> CCR1/CCR3
+ *+ DMA transfer CCR[1/3] & CCR[2/4] values (t0, tx: doesn't care)
+ * 1: IC2/4 snapchot on falling edge: counter value -> CCR2/CCR4
+ * 2: IC1/3 snapchot on rising edge: counter value -> CCR1/CCR3
+ *+ DMA transfer CCR[1/3] & CCR[2/4] values (t2, t1)
+ *
+ * DMA done, compute:
+ * - Period = t2 - t0
+ * - Duty cycle = t1 - t0
+ */
+static int stm32_pwm_raw_capture(struct stm32_pwm *priv, struct pwm_device 
*pwm,
+unsigned long tmo_ms, u32 *raw_prd,
+u32 *raw_dty)
+{
+   struct device *parent = priv->chip.dev->parent;
+   enum stm32_timers_dmas dma_id;
+   u32 ccen, ccr;
+   int ret;
+
+   /* Ensure registers have been updated, enable counter and capture */
+   regmap_update_bits(priv->regmap, TIM_EGR, TIM_EGR_UG, TIM_EGR_UG);
+   regmap_update_bits(priv->regmap, TIM_CR1, TIM_CR1_CEN, TIM_CR1_CEN);
+
+   /* Use cc1 or cc3 DMA resp for PWM input channels 1 & 2 or 3 & 4 */
+   dma_id = pwm->hwpwm < 2 ? STM32_TIMERS_DMA_CH1 : STM32_TIMERS_DMA_CH3;
+   ccen = pwm->hwpwm < 2 ? TIM_CCER_CC12E : TIM_CCER_CC34E;
+   ccr = pwm->hwpwm < 2 ? TIM_CCR1 : TIM_CCR3;
+   regmap_update_bits(priv->regmap, TIM_CCER, ccen, ccen);
+
+   /*
+* Timer DMA burst mode. Request 2 registers, 2 bursts, to get both
+* CCR1 & CCR2 (or CCR3 & CCR4) on each capture event.
+* We'll get two capture snapchots: { CCR1, CCR2 }, { CCR1, CCR2 }
+* or { CCR3, CCR4 }, { CCR3, CCR4 }
+*/
+   ret = stm32_timers_dma_burst_read(parent, priv->capture, dma_id, ccr, 2,
+ 2, tmo_ms);
+   if (ret)
+   goto stop;
+
+   /* Period: t2 - t0 (take care of counter overflow) */
+   if (priv->capture[0] <= priv->capture[2])
+   *raw_prd = priv->capture[2] - priv->capture[0];
+   else
+   *raw_prd = priv->max_arr - priv->capture[0] + priv->capture[2];
+
+   /* Duty cycle capture requires at 

[PATCH v3 3/6] pwm: stm32: add capture support

2018-03-30 Thread Fabrice Gasnier
Add support for PMW input mode on pwm-stm32. STM32 timers support
period and duty cycle capture as long as they have at least two PWM
channels. One capture channel is used for period (rising-edge), one
for duty-cycle (falling-edge).
When there's only one channel available, only period can be captured.
Duty-cycle is simply zero'ed in such a case.

Capture requires exclusive access (e.g. no pwm output running at the
same time, to protect common prescaler).
Timer DMA burst mode (from MFD core) is being used, to take two
snapshots of capture registers (upon each period rising edge).

Signed-off-by: Fabrice Gasnier 
Reviewed-by: Benjamin Gaignard 
Acked-by: Thierry Reding 
---
Changes in v3:
- update stm32_timers_dma_burst_read() call: don't pass ddata structure,
  use MFD parent device structure instead since MFD core update.

Changes in v2:
- DMA handling has been moved to MFD core. Rework capture routines to
  use it.
---
 drivers/pwm/pwm-stm32.c  | 176 +++
 include/linux/mfd/stm32-timers.h |  11 +++
 2 files changed, 187 insertions(+)

diff --git a/drivers/pwm/pwm-stm32.c b/drivers/pwm/pwm-stm32.c
index 3ac55df..00c6251 100644
--- a/drivers/pwm/pwm-stm32.c
+++ b/drivers/pwm/pwm-stm32.c
@@ -26,6 +26,7 @@ struct stm32_pwm {
struct regmap *regmap;
u32 max_arr;
bool have_complementary_output;
+   u32 capture[4] cacheline_aligned; /* DMA'able buffer */
 };
 
 struct stm32_breakinput {
@@ -63,6 +64,178 @@ static int write_ccrx(struct stm32_pwm *dev, int ch, u32 
value)
return -EINVAL;
 }
 
+#define TIM_CCER_CC12P (TIM_CCER_CC1P | TIM_CCER_CC2P)
+#define TIM_CCER_CC12E (TIM_CCER_CC1E | TIM_CCER_CC2E)
+#define TIM_CCER_CC34P (TIM_CCER_CC3P | TIM_CCER_CC4P)
+#define TIM_CCER_CC34E (TIM_CCER_CC3E | TIM_CCER_CC4E)
+
+/*
+ * Capture using PWM input mode:
+ *  ___  ___
+ * TI[1, 2, 3 or 4]: ._|   ||
+ * ^0  ^1   ^2
+ *  .   ..
+ *  .   .X
+ *  .   .   X |
+ *  .  X .|
+ *X ..|
+ * COUNTER:__X  .   ..|_XXX
+ * start^   .   ..^stop
+ *  .   .   ..
+ *  v   v   .v
+ *  v
+ * CCR1/CCR3:   tx..t0...t2
+ * CCR2/CCR4:   tx..t1.
+ *
+ * DMA burst transfer:  ||
+ *  vv
+ * DMA buffer:  { t0, tx }   { t2, t1 }
+ * DMA done: ^
+ *
+ * 0: IC1/3 snapchot on rising edge: counter value -> CCR1/CCR3
+ *+ DMA transfer CCR[1/3] & CCR[2/4] values (t0, tx: doesn't care)
+ * 1: IC2/4 snapchot on falling edge: counter value -> CCR2/CCR4
+ * 2: IC1/3 snapchot on rising edge: counter value -> CCR1/CCR3
+ *+ DMA transfer CCR[1/3] & CCR[2/4] values (t2, t1)
+ *
+ * DMA done, compute:
+ * - Period = t2 - t0
+ * - Duty cycle = t1 - t0
+ */
+static int stm32_pwm_raw_capture(struct stm32_pwm *priv, struct pwm_device 
*pwm,
+unsigned long tmo_ms, u32 *raw_prd,
+u32 *raw_dty)
+{
+   struct device *parent = priv->chip.dev->parent;
+   enum stm32_timers_dmas dma_id;
+   u32 ccen, ccr;
+   int ret;
+
+   /* Ensure registers have been updated, enable counter and capture */
+   regmap_update_bits(priv->regmap, TIM_EGR, TIM_EGR_UG, TIM_EGR_UG);
+   regmap_update_bits(priv->regmap, TIM_CR1, TIM_CR1_CEN, TIM_CR1_CEN);
+
+   /* Use cc1 or cc3 DMA resp for PWM input channels 1 & 2 or 3 & 4 */
+   dma_id = pwm->hwpwm < 2 ? STM32_TIMERS_DMA_CH1 : STM32_TIMERS_DMA_CH3;
+   ccen = pwm->hwpwm < 2 ? TIM_CCER_CC12E : TIM_CCER_CC34E;
+   ccr = pwm->hwpwm < 2 ? TIM_CCR1 : TIM_CCR3;
+   regmap_update_bits(priv->regmap, TIM_CCER, ccen, ccen);
+
+   /*
+* Timer DMA burst mode. Request 2 registers, 2 bursts, to get both
+* CCR1 & CCR2 (or CCR3 & CCR4) on each capture event.
+* We'll get two capture snapchots: { CCR1, CCR2 }, { CCR1, CCR2 }
+* or { CCR3, CCR4 }, { CCR3, CCR4 }
+*/
+   ret = stm32_timers_dma_burst_read(parent, priv->capture, dma_id, ccr, 2,
+ 2, tmo_ms);
+   if (ret)
+   goto stop;
+
+   /* Period: t2 - t0 (take care of counter overflow) */
+   if (priv->capture[0] <= priv->capture[2])
+   *raw_prd = priv->capture[2] - priv->capture[0];
+   else
+   *raw_prd = priv->max_arr - priv->capture[0] + priv->capture[2];
+
+   /* Duty cycle capture requires at least two capture units */
+   if (pwm->chip->npwm < 2)
+   

[PATCH v3 6/6] ARM: dts: stm32: Enable pwm3 input capture on stm32f429i-eval

2018-03-30 Thread Fabrice Gasnier
Enable pwm3 input capture on stm32f429i-eval, by using DMA.

Signed-off-by: Fabrice Gasnier 
Reviewed-by: Benjamin Gaignard 
---
 arch/arm/boot/dts/stm32429i-eval.dts | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/boot/dts/stm32429i-eval.dts 
b/arch/arm/boot/dts/stm32429i-eval.dts
index 293ecb9..d5498dd 100644
--- a/arch/arm/boot/dts/stm32429i-eval.dts
+++ b/arch/arm/boot/dts/stm32429i-eval.dts
@@ -271,6 +271,9 @@
  {
status = "okay";
 
+   /* Enable PWM input capture by using dma */
+   dmas = < 4 5 0x400 0x0>;
+   dma-names = "ch1";
pwm {
pinctrl-0 = <_pins>;
pinctrl-names = "default";
-- 
1.9.1



[PATCH v3 6/6] ARM: dts: stm32: Enable pwm3 input capture on stm32f429i-eval

2018-03-30 Thread Fabrice Gasnier
Enable pwm3 input capture on stm32f429i-eval, by using DMA.

Signed-off-by: Fabrice Gasnier 
Reviewed-by: Benjamin Gaignard 
---
 arch/arm/boot/dts/stm32429i-eval.dts | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/boot/dts/stm32429i-eval.dts 
b/arch/arm/boot/dts/stm32429i-eval.dts
index 293ecb9..d5498dd 100644
--- a/arch/arm/boot/dts/stm32429i-eval.dts
+++ b/arch/arm/boot/dts/stm32429i-eval.dts
@@ -271,6 +271,9 @@
  {
status = "okay";
 
+   /* Enable PWM input capture by using dma */
+   dmas = < 4 5 0x400 0x0>;
+   dma-names = "ch1";
pwm {
pinctrl-0 = <_pins>;
pinctrl-names = "default";
-- 
1.9.1



[PATCH v3 5/6] pwm: stm32: use input prescaler to improve period capture

2018-03-30 Thread Fabrice Gasnier
Using input prescaler, capture unit will trigger DMA once every
configurable /2, /4 or /8 events (rising edge). This helps improve
period (only) capture accuracy at high rates.

Signed-off-by: Fabrice Gasnier 
Reviewed-by: Benjamin Gaignard 
Acked-by: Thierry Reding 
---
Changes in v2:
- Adopt DMA read from MFD core.
---
 drivers/pwm/pwm-stm32.c  | 63 ++--
 include/linux/mfd/stm32-timers.h |  1 +
 2 files changed, 62 insertions(+), 2 deletions(-)

diff --git a/drivers/pwm/pwm-stm32.c b/drivers/pwm/pwm-stm32.c
index c6eb0a8..21ea762 100644
--- a/drivers/pwm/pwm-stm32.c
+++ b/drivers/pwm/pwm-stm32.c
@@ -9,6 +9,7 @@
  * pwm-atmel.c from Bo Shen
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -169,7 +170,7 @@ static int stm32_pwm_capture(struct pwm_chip *chip, struct 
pwm_device *pwm,
struct stm32_pwm *priv = to_stm32_pwm_dev(chip);
unsigned long long prd, div, dty;
unsigned long rate;
-   unsigned int psc = 0, scale;
+   unsigned int psc = 0, icpsc, scale;
u32 raw_prd, raw_dty;
int ret = 0;
 
@@ -223,6 +224,7 @@ static int stm32_pwm_capture(struct pwm_chip *chip, struct 
pwm_device *pwm,
/*
 * Got a capture. Try to improve accuracy at high rates:
 * - decrease counter clock prescaler, scale up to max rate.
+* - use input prescaler, capture once every /2 /4 or /8 edges.
 */
if (raw_prd) {
u32 max_arr = priv->max_arr - 0x1000; /* arbitrary margin */
@@ -242,8 +244,65 @@ static int stm32_pwm_capture(struct pwm_chip *chip, struct 
pwm_device *pwm,
goto stop;
}
 
+   /* Compute intermediate period not to exceed timeout at low rates */
prd = (unsigned long long)raw_prd * (psc + 1) * NSEC_PER_SEC;
-   result->period = DIV_ROUND_UP_ULL(prd, rate);
+   do_div(prd, rate);
+
+   for (icpsc = 0; icpsc < MAX_TIM_ICPSC ; icpsc++) {
+   /* input prescaler: also keep arbitrary margin */
+   if (raw_prd >= (priv->max_arr - 0x1000) >> (icpsc + 1))
+   break;
+   if (prd >= (tmo_ms * NSEC_PER_MSEC) >> (icpsc + 2))
+   break;
+   }
+
+   if (!icpsc)
+   goto done;
+
+   /* Last chance to improve period accuracy, using input prescaler */
+   regmap_update_bits(priv->regmap,
+  pwm->hwpwm < 2 ? TIM_CCMR1 : TIM_CCMR2,
+  TIM_CCMR_IC1PSC | TIM_CCMR_IC2PSC,
+  FIELD_PREP(TIM_CCMR_IC1PSC, icpsc) |
+  FIELD_PREP(TIM_CCMR_IC2PSC, icpsc));
+
+   ret = stm32_pwm_raw_capture(priv, pwm, tmo_ms, _prd, _dty);
+   if (ret)
+   goto stop;
+
+   if (raw_dty >= (raw_prd >> icpsc)) {
+   /*
+* We may fall here using input prescaler, when input
+* capture starts on high side (before falling edge).
+* Example with icpsc to capture on each 4 events:
+*
+*   start   1st capture 2nd capture
+* v v   v
+* ___   _   _   _   _   
+* TI1..4 |__||__||__||__||__|
+*v  v.  ..  ..   v  v
+* icpsc1/3:  .  0.  1.  2.  3.  0
+* icpsc2/4:  0   1   2   3   0
+*v  vv  v
+* CCR1/3  ..t0..t2
+* CCR2/4  ..t1..t1'...
+*   ..  .
+* Capture0: .<->.
+* Capture1: .<-->.  .
+*   ..  .
+* Period:   .<-->.  .
+* Low side:  .<>.
+*
+* Result:
+* - Period = Capture0 / icpsc
+* - Duty = Period - Low side = Period - (Capture0 - Capture1)
+*/
+   raw_dty = (raw_prd >> icpsc) - (raw_prd - raw_dty);
+   }
+
+done:
+   prd = (unsigned long long)raw_prd * (psc + 1) * NSEC_PER_SEC;
+   result->period = DIV_ROUND_UP_ULL(prd, rate << icpsc);
dty = (unsigned long long)raw_dty * (psc + 1) * NSEC_PER_SEC;
result->duty_cycle = DIV_ROUND_UP_ULL(dty, rate);
 stop:
diff --git a/include/linux/mfd/stm32-timers.h b/include/linux/mfd/stm32-timers.h
index 3c72b70..2f505c2 100644
--- a/include/linux/mfd/stm32-timers.h
+++ b/include/linux/mfd/stm32-timers.h
@@ -82,6 +82,7 

[PATCH v3 5/6] pwm: stm32: use input prescaler to improve period capture

2018-03-30 Thread Fabrice Gasnier
Using input prescaler, capture unit will trigger DMA once every
configurable /2, /4 or /8 events (rising edge). This helps improve
period (only) capture accuracy at high rates.

Signed-off-by: Fabrice Gasnier 
Reviewed-by: Benjamin Gaignard 
Acked-by: Thierry Reding 
---
Changes in v2:
- Adopt DMA read from MFD core.
---
 drivers/pwm/pwm-stm32.c  | 63 ++--
 include/linux/mfd/stm32-timers.h |  1 +
 2 files changed, 62 insertions(+), 2 deletions(-)

diff --git a/drivers/pwm/pwm-stm32.c b/drivers/pwm/pwm-stm32.c
index c6eb0a8..21ea762 100644
--- a/drivers/pwm/pwm-stm32.c
+++ b/drivers/pwm/pwm-stm32.c
@@ -9,6 +9,7 @@
  * pwm-atmel.c from Bo Shen
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -169,7 +170,7 @@ static int stm32_pwm_capture(struct pwm_chip *chip, struct 
pwm_device *pwm,
struct stm32_pwm *priv = to_stm32_pwm_dev(chip);
unsigned long long prd, div, dty;
unsigned long rate;
-   unsigned int psc = 0, scale;
+   unsigned int psc = 0, icpsc, scale;
u32 raw_prd, raw_dty;
int ret = 0;
 
@@ -223,6 +224,7 @@ static int stm32_pwm_capture(struct pwm_chip *chip, struct 
pwm_device *pwm,
/*
 * Got a capture. Try to improve accuracy at high rates:
 * - decrease counter clock prescaler, scale up to max rate.
+* - use input prescaler, capture once every /2 /4 or /8 edges.
 */
if (raw_prd) {
u32 max_arr = priv->max_arr - 0x1000; /* arbitrary margin */
@@ -242,8 +244,65 @@ static int stm32_pwm_capture(struct pwm_chip *chip, struct 
pwm_device *pwm,
goto stop;
}
 
+   /* Compute intermediate period not to exceed timeout at low rates */
prd = (unsigned long long)raw_prd * (psc + 1) * NSEC_PER_SEC;
-   result->period = DIV_ROUND_UP_ULL(prd, rate);
+   do_div(prd, rate);
+
+   for (icpsc = 0; icpsc < MAX_TIM_ICPSC ; icpsc++) {
+   /* input prescaler: also keep arbitrary margin */
+   if (raw_prd >= (priv->max_arr - 0x1000) >> (icpsc + 1))
+   break;
+   if (prd >= (tmo_ms * NSEC_PER_MSEC) >> (icpsc + 2))
+   break;
+   }
+
+   if (!icpsc)
+   goto done;
+
+   /* Last chance to improve period accuracy, using input prescaler */
+   regmap_update_bits(priv->regmap,
+  pwm->hwpwm < 2 ? TIM_CCMR1 : TIM_CCMR2,
+  TIM_CCMR_IC1PSC | TIM_CCMR_IC2PSC,
+  FIELD_PREP(TIM_CCMR_IC1PSC, icpsc) |
+  FIELD_PREP(TIM_CCMR_IC2PSC, icpsc));
+
+   ret = stm32_pwm_raw_capture(priv, pwm, tmo_ms, _prd, _dty);
+   if (ret)
+   goto stop;
+
+   if (raw_dty >= (raw_prd >> icpsc)) {
+   /*
+* We may fall here using input prescaler, when input
+* capture starts on high side (before falling edge).
+* Example with icpsc to capture on each 4 events:
+*
+*   start   1st capture 2nd capture
+* v v   v
+* ___   _   _   _   _   
+* TI1..4 |__||__||__||__||__|
+*v  v.  ..  ..   v  v
+* icpsc1/3:  .  0.  1.  2.  3.  0
+* icpsc2/4:  0   1   2   3   0
+*v  vv  v
+* CCR1/3  ..t0..t2
+* CCR2/4  ..t1..t1'...
+*   ..  .
+* Capture0: .<->.
+* Capture1: .<-->.  .
+*   ..  .
+* Period:   .<-->.  .
+* Low side:  .<>.
+*
+* Result:
+* - Period = Capture0 / icpsc
+* - Duty = Period - Low side = Period - (Capture0 - Capture1)
+*/
+   raw_dty = (raw_prd >> icpsc) - (raw_prd - raw_dty);
+   }
+
+done:
+   prd = (unsigned long long)raw_prd * (psc + 1) * NSEC_PER_SEC;
+   result->period = DIV_ROUND_UP_ULL(prd, rate << icpsc);
dty = (unsigned long long)raw_dty * (psc + 1) * NSEC_PER_SEC;
result->duty_cycle = DIV_ROUND_UP_ULL(dty, rate);
 stop:
diff --git a/include/linux/mfd/stm32-timers.h b/include/linux/mfd/stm32-timers.h
index 3c72b70..2f505c2 100644
--- a/include/linux/mfd/stm32-timers.h
+++ b/include/linux/mfd/stm32-timers.h
@@ -82,6 +82,7 @@
 #define TIM_DCR_DBLGENMASK(12, 8)  /* DMA burst len */
 
 #define 

[PATCH v3 0/6] Add support for PWM input capture on STM32

2018-03-30 Thread Fabrice Gasnier
This series adds support for capture to stm32-pwm driver.
Capture is based on DMAs.
- First two patches add support for requesting DMAs to MFD core
- Next three patches add support for capture to stm32-pwm driver
- This has been tested on stm32429i-eval board.

---
Changes in v3:
- Dropped 2 precusor patches applied by Thierry in pwm tree:
  "pwm: stm32: fix, remove unused struct device"
  "pwm: stm32: protect common prescaler for all channels"
- Note: this series applies on top on pwm tree
- Implements Lee's comments on MFD part: rework stm32_timers_dma struct,
  exported routine prototype now use generic device struct, more
  various comments (see patch 2 changelog).

Resend v2:
- Add collected Acks

Changes in v2:
- Abstract DMA handling from child driver: move it to MFD core
- Rework pwm capture routines to adopt this change
- Comment on optional dma support, beautify DMAs probe

Fabrice Gasnier (6):
  dt-bindings: mfd: stm32-timers: add support for dmas
  mfd: stm32-timers: add support for dmas
  pwm: stm32: add capture support
  pwm: stm32: improve capture by tuning counter prescaler
  pwm: stm32: use input prescaler to improve period capture
  ARM: dts: stm32: Enable pwm3 input capture on stm32f429i-eval

 .../devicetree/bindings/mfd/stm32-timers.txt   |  20 ++
 arch/arm/boot/dts/stm32429i-eval.dts   |   3 +
 drivers/mfd/stm32-timers.c | 219 +-
 drivers/pwm/pwm-stm32.c| 257 +
 include/linux/mfd/stm32-timers.h   |  44 
 5 files changed, 541 insertions(+), 2 deletions(-)

-- 
1.9.1



[PATCH v3 0/6] Add support for PWM input capture on STM32

2018-03-30 Thread Fabrice Gasnier
This series adds support for capture to stm32-pwm driver.
Capture is based on DMAs.
- First two patches add support for requesting DMAs to MFD core
- Next three patches add support for capture to stm32-pwm driver
- This has been tested on stm32429i-eval board.

---
Changes in v3:
- Dropped 2 precusor patches applied by Thierry in pwm tree:
  "pwm: stm32: fix, remove unused struct device"
  "pwm: stm32: protect common prescaler for all channels"
- Note: this series applies on top on pwm tree
- Implements Lee's comments on MFD part: rework stm32_timers_dma struct,
  exported routine prototype now use generic device struct, more
  various comments (see patch 2 changelog).

Resend v2:
- Add collected Acks

Changes in v2:
- Abstract DMA handling from child driver: move it to MFD core
- Rework pwm capture routines to adopt this change
- Comment on optional dma support, beautify DMAs probe

Fabrice Gasnier (6):
  dt-bindings: mfd: stm32-timers: add support for dmas
  mfd: stm32-timers: add support for dmas
  pwm: stm32: add capture support
  pwm: stm32: improve capture by tuning counter prescaler
  pwm: stm32: use input prescaler to improve period capture
  ARM: dts: stm32: Enable pwm3 input capture on stm32f429i-eval

 .../devicetree/bindings/mfd/stm32-timers.txt   |  20 ++
 arch/arm/boot/dts/stm32429i-eval.dts   |   3 +
 drivers/mfd/stm32-timers.c | 219 +-
 drivers/pwm/pwm-stm32.c| 257 +
 include/linux/mfd/stm32-timers.h   |  44 
 5 files changed, 541 insertions(+), 2 deletions(-)

-- 
1.9.1



[PATCH v3 1/6] dt-bindings: mfd: stm32-timers: add support for dmas

2018-03-30 Thread Fabrice Gasnier
Add support for DMAs to STM32 timers. STM32 Timers can support up to 7
dma requests: up to 4 channels, update, compare and trigger.
DMAs may be used to transfer data from pwm capture for instance.
DMA support is made optional, PWM capture support is also an option.
This is much more wise system-wide to avoid shortage on DMA request
lines as there's significant amount of timer instances that can
request up to 7 channels.

Signed-off-by: Fabrice Gasnier 
Reviewed-by: Rob Herring 
Reviewed-by: Benjamin Gaignard 
---
 .../devicetree/bindings/mfd/stm32-timers.txt | 20 
 1 file changed, 20 insertions(+)

diff --git a/Documentation/devicetree/bindings/mfd/stm32-timers.txt 
b/Documentation/devicetree/bindings/mfd/stm32-timers.txt
index 1db6e00..0e900b5 100644
--- a/Documentation/devicetree/bindings/mfd/stm32-timers.txt
+++ b/Documentation/devicetree/bindings/mfd/stm32-timers.txt
@@ -19,6 +19,11 @@ Required parameters:
 Optional parameters:
 - resets:  Phandle to the parent reset controller.
See ../reset/st,stm32-rcc.txt
+- dmas:List of phandle to dma channels that can be 
used for
+   this timer instance. There may be up to 7 dma channels.
+- dma-names:   List of dma names. Must match 'dmas' property. Valid
+   names are: "ch1", "ch2", "ch3", "ch4", "up", "trig",
+   "com".
 
 Optional subnodes:
 - pwm: See ../pwm/pwm-stm32.txt
@@ -44,3 +49,18 @@ Example:
reg = <0>;
};
};
+
+Example with all dmas:
+   timer@4001 {
+   ...
+   dmas = < 11 0x400 0x0>,
+  < 12 0x400 0x0>,
+  < 13 0x400 0x0>,
+  < 14 0x400 0x0>,
+  < 15 0x400 0x0>,
+  < 16 0x400 0x0>,
+  < 17 0x400 0x0>;
+   dma-names = "ch1", "ch2", "ch3", "ch4", "up", "trig", "com";
+   ...
+   child nodes...
+   };
-- 
1.9.1



[PATCH v3 1/6] dt-bindings: mfd: stm32-timers: add support for dmas

2018-03-30 Thread Fabrice Gasnier
Add support for DMAs to STM32 timers. STM32 Timers can support up to 7
dma requests: up to 4 channels, update, compare and trigger.
DMAs may be used to transfer data from pwm capture for instance.
DMA support is made optional, PWM capture support is also an option.
This is much more wise system-wide to avoid shortage on DMA request
lines as there's significant amount of timer instances that can
request up to 7 channels.

Signed-off-by: Fabrice Gasnier 
Reviewed-by: Rob Herring 
Reviewed-by: Benjamin Gaignard 
---
 .../devicetree/bindings/mfd/stm32-timers.txt | 20 
 1 file changed, 20 insertions(+)

diff --git a/Documentation/devicetree/bindings/mfd/stm32-timers.txt 
b/Documentation/devicetree/bindings/mfd/stm32-timers.txt
index 1db6e00..0e900b5 100644
--- a/Documentation/devicetree/bindings/mfd/stm32-timers.txt
+++ b/Documentation/devicetree/bindings/mfd/stm32-timers.txt
@@ -19,6 +19,11 @@ Required parameters:
 Optional parameters:
 - resets:  Phandle to the parent reset controller.
See ../reset/st,stm32-rcc.txt
+- dmas:List of phandle to dma channels that can be 
used for
+   this timer instance. There may be up to 7 dma channels.
+- dma-names:   List of dma names. Must match 'dmas' property. Valid
+   names are: "ch1", "ch2", "ch3", "ch4", "up", "trig",
+   "com".
 
 Optional subnodes:
 - pwm: See ../pwm/pwm-stm32.txt
@@ -44,3 +49,18 @@ Example:
reg = <0>;
};
};
+
+Example with all dmas:
+   timer@4001 {
+   ...
+   dmas = < 11 0x400 0x0>,
+  < 12 0x400 0x0>,
+  < 13 0x400 0x0>,
+  < 14 0x400 0x0>,
+  < 15 0x400 0x0>,
+  < 16 0x400 0x0>,
+  < 17 0x400 0x0>;
+   dma-names = "ch1", "ch2", "ch3", "ch4", "up", "trig", "com";
+   ...
+   child nodes...
+   };
-- 
1.9.1



Re: [PATCH 12/76] staging: ks7010: Remove trailing _t from 'struct hostif_mib_set_confirm_t'.

2018-03-30 Thread Greg KH
On Fri, Mar 30, 2018 at 12:07:35AM -0700, Quytelda Kahja wrote:
> The "_t" suffix is not needed for structure names in this driver, and is a
> reflection of an older typedef system that is no longer in place. Replace
> all occurences of 'struct hostif_mib_set_confirm_t' with 'struct
> hostif_mib_set_confirm'.
> 
> Signed-off-by: Quytelda Kahja 
> ---
>  drivers/staging/ks7010/ks_hostif.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/ks7010/ks_hostif.h 
> b/drivers/staging/ks7010/ks_hostif.h
> index 5261810fbc76..7a0e0c610c50 100644
> --- a/drivers/staging/ks7010/ks_hostif.h
> +++ b/drivers/staging/ks7010/ks_hostif.h
> @@ -175,7 +175,7 @@ struct hostif_mib_set_request {
>   struct hostif_mib_value mib_value;
>  } __packed;
>  
> -struct hostif_mib_set_confirm_t {
> +struct hostif_mib_set_confirm {
>   struct hostif_hdr header;
>   __le32 mib_status;
>   __le32 mib_attribute;

As Joe points out, please just remove structures that are not used at
all, it's pointless to keep them around.

thanks,

greg k-h


Re: [PATCH 12/76] staging: ks7010: Remove trailing _t from 'struct hostif_mib_set_confirm_t'.

2018-03-30 Thread Greg KH
On Fri, Mar 30, 2018 at 12:07:35AM -0700, Quytelda Kahja wrote:
> The "_t" suffix is not needed for structure names in this driver, and is a
> reflection of an older typedef system that is no longer in place. Replace
> all occurences of 'struct hostif_mib_set_confirm_t' with 'struct
> hostif_mib_set_confirm'.
> 
> Signed-off-by: Quytelda Kahja 
> ---
>  drivers/staging/ks7010/ks_hostif.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/ks7010/ks_hostif.h 
> b/drivers/staging/ks7010/ks_hostif.h
> index 5261810fbc76..7a0e0c610c50 100644
> --- a/drivers/staging/ks7010/ks_hostif.h
> +++ b/drivers/staging/ks7010/ks_hostif.h
> @@ -175,7 +175,7 @@ struct hostif_mib_set_request {
>   struct hostif_mib_value mib_value;
>  } __packed;
>  
> -struct hostif_mib_set_confirm_t {
> +struct hostif_mib_set_confirm {
>   struct hostif_hdr header;
>   __le32 mib_status;
>   __le32 mib_attribute;

As Joe points out, please just remove structures that are not used at
all, it's pointless to keep them around.

thanks,

greg k-h


Re: [PATCH AUTOSEL for 4.15 116/124] genirq/affinity: assign vectors to all possible CPUs

2018-03-30 Thread Thorsten Leemhuis
Lo! On 27.03.2018 20:33, Thorsten Leemhuis wrote:
> On 19.03.2018 16:49, Sasha Levin wrote:
>> From: Christoph Hellwig 
>> [ Upstream commit 84676c1f21e8ff54befe985f4f14dc1edc10046b ]
> TWIMC: That commit (also reported by autosel for 4.14) triggered a
> regression in 4.16 reported by Artem Bityutskiy in "regression:
> SCSI/SATA failure" (https://marc.info/?l=linux-kernel=151931128006031
> ). […]

For the record, from what I head it in between was fixed by these:

2f31115e940c scsi: core: introduce force_blk_mq
8b834bff1b73 scsi: hpsa: fix selection of reply queue
adbe552349f2 scsi: megaraid_sas: fix selection of reply queue
c3506df85091 scsi: virtio_scsi: unify scsi_host_template
b5b6e8c8d3b4 scsi: virtio_scsi: fix IO hang caused by automatic irq
vector affinity

Ciao, Thorsten

>> Currently we assign managed interrupt vectors to all present CPUs.  This
>> works fine for systems were we only online/offline CPUs.  But in case of
>> systems that support physical CPU hotplug (or the virtualized version of
>> it) this means the additional CPUs covered for in the ACPI tables or on
>> the command line are not catered for.  To fix this we'd either need to
>> introduce new hotplug CPU states just for this case, or we can start
>> assining vectors to possible but not present CPUs.
>>
>> Reported-by: Christian Borntraeger 
>> Tested-by: Christian Borntraeger 
>> Tested-by: Stefan Haberland 
>> Fixes: 4b855ad37194 ("blk-mq: Create hctx for each present CPU")
>> Cc: linux-kernel@vger.kernel.org
>> Cc: Thomas Gleixner 
>> Signed-off-by: Christoph Hellwig 
>> Signed-off-by: Jens Axboe 
>> Signed-off-by: Sasha Levin 
>> ---
>>  kernel/irq/affinity.c | 30 +++---
>>  1 file changed, 15 insertions(+), 15 deletions(-)
>>
>> diff --git a/kernel/irq/affinity.c b/kernel/irq/affinity.c
>> index e12d35108225..a37a3b4b6342 100644
>> --- a/kernel/irq/affinity.c
>> +++ b/kernel/irq/affinity.c
>> @@ -39,7 +39,7 @@ static void irq_spread_init_one(struct cpumask *irqmsk, 
>> struct cpumask *nmsk,
>>  }
>>  }
>>  
>> -static cpumask_var_t *alloc_node_to_present_cpumask(void)
>> +static cpumask_var_t *alloc_node_to_possible_cpumask(void)
>>  {
>>  cpumask_var_t *masks;
>>  int node;
>> @@ -62,7 +62,7 @@ static cpumask_var_t *alloc_node_to_present_cpumask(void)
>>  return NULL;
>>  }
>>  
>> -static void free_node_to_present_cpumask(cpumask_var_t *masks)
>> +static void free_node_to_possible_cpumask(cpumask_var_t *masks)
>>  {
>>  int node;
>>  
>> @@ -71,22 +71,22 @@ static void free_node_to_present_cpumask(cpumask_var_t 
>> *masks)
>>  kfree(masks);
>>  }
>>  
>> -static void build_node_to_present_cpumask(cpumask_var_t *masks)
>> +static void build_node_to_possible_cpumask(cpumask_var_t *masks)
>>  {
>>  int cpu;
>>  
>> -for_each_present_cpu(cpu)
>> +for_each_possible_cpu(cpu)
>>  cpumask_set_cpu(cpu, masks[cpu_to_node(cpu)]);
>>  }
>>  
>> -static int get_nodes_in_cpumask(cpumask_var_t *node_to_present_cpumask,
>> +static int get_nodes_in_cpumask(cpumask_var_t *node_to_possible_cpumask,
>>  const struct cpumask *mask, nodemask_t *nodemsk)
>>  {
>>  int n, nodes = 0;
>>  
>>  /* Calculate the number of nodes in the supplied affinity mask */
>>  for_each_node(n) {
>> -if (cpumask_intersects(mask, node_to_present_cpumask[n])) {
>> +if (cpumask_intersects(mask, node_to_possible_cpumask[n])) {
>>  node_set(n, *nodemsk);
>>  nodes++;
>>  }
>> @@ -109,7 +109,7 @@ irq_create_affinity_masks(int nvecs, const struct 
>> irq_affinity *affd)
>>  int last_affv = affv + affd->pre_vectors;
>>  nodemask_t nodemsk = NODE_MASK_NONE;
>>  struct cpumask *masks;
>> -cpumask_var_t nmsk, *node_to_present_cpumask;
>> +cpumask_var_t nmsk, *node_to_possible_cpumask;
>>  
>>  /*
>>   * If there aren't any vectors left after applying the pre/post
>> @@ -125,8 +125,8 @@ irq_create_affinity_masks(int nvecs, const struct 
>> irq_affinity *affd)
>>  if (!masks)
>>  goto out;
>>  
>> -node_to_present_cpumask = alloc_node_to_present_cpumask();
>> -if (!node_to_present_cpumask)
>> +node_to_possible_cpumask = alloc_node_to_possible_cpumask();
>> +if (!node_to_possible_cpumask)
>>  goto out;
>>  
>>  /* Fill out vectors at the beginning that don't need affinity */
>> @@ -135,8 +135,8 @@ irq_create_affinity_masks(int nvecs, const struct 
>> irq_affinity *affd)
>>  
>>  /* Stabilize the cpumasks */
>>  get_online_cpus();
>> -build_node_to_present_cpumask(node_to_present_cpumask);
>> -nodes = get_nodes_in_cpumask(node_to_present_cpumask, cpu_present_mask,
>> +build_node_to_possible_cpumask(node_to_possible_cpumask);
>> +nodes 

Re: [PATCH AUTOSEL for 4.15 116/124] genirq/affinity: assign vectors to all possible CPUs

2018-03-30 Thread Thorsten Leemhuis
Lo! On 27.03.2018 20:33, Thorsten Leemhuis wrote:
> On 19.03.2018 16:49, Sasha Levin wrote:
>> From: Christoph Hellwig 
>> [ Upstream commit 84676c1f21e8ff54befe985f4f14dc1edc10046b ]
> TWIMC: That commit (also reported by autosel for 4.14) triggered a
> regression in 4.16 reported by Artem Bityutskiy in "regression:
> SCSI/SATA failure" (https://marc.info/?l=linux-kernel=151931128006031
> ). […]

For the record, from what I head it in between was fixed by these:

2f31115e940c scsi: core: introduce force_blk_mq
8b834bff1b73 scsi: hpsa: fix selection of reply queue
adbe552349f2 scsi: megaraid_sas: fix selection of reply queue
c3506df85091 scsi: virtio_scsi: unify scsi_host_template
b5b6e8c8d3b4 scsi: virtio_scsi: fix IO hang caused by automatic irq
vector affinity

Ciao, Thorsten

>> Currently we assign managed interrupt vectors to all present CPUs.  This
>> works fine for systems were we only online/offline CPUs.  But in case of
>> systems that support physical CPU hotplug (or the virtualized version of
>> it) this means the additional CPUs covered for in the ACPI tables or on
>> the command line are not catered for.  To fix this we'd either need to
>> introduce new hotplug CPU states just for this case, or we can start
>> assining vectors to possible but not present CPUs.
>>
>> Reported-by: Christian Borntraeger 
>> Tested-by: Christian Borntraeger 
>> Tested-by: Stefan Haberland 
>> Fixes: 4b855ad37194 ("blk-mq: Create hctx for each present CPU")
>> Cc: linux-kernel@vger.kernel.org
>> Cc: Thomas Gleixner 
>> Signed-off-by: Christoph Hellwig 
>> Signed-off-by: Jens Axboe 
>> Signed-off-by: Sasha Levin 
>> ---
>>  kernel/irq/affinity.c | 30 +++---
>>  1 file changed, 15 insertions(+), 15 deletions(-)
>>
>> diff --git a/kernel/irq/affinity.c b/kernel/irq/affinity.c
>> index e12d35108225..a37a3b4b6342 100644
>> --- a/kernel/irq/affinity.c
>> +++ b/kernel/irq/affinity.c
>> @@ -39,7 +39,7 @@ static void irq_spread_init_one(struct cpumask *irqmsk, 
>> struct cpumask *nmsk,
>>  }
>>  }
>>  
>> -static cpumask_var_t *alloc_node_to_present_cpumask(void)
>> +static cpumask_var_t *alloc_node_to_possible_cpumask(void)
>>  {
>>  cpumask_var_t *masks;
>>  int node;
>> @@ -62,7 +62,7 @@ static cpumask_var_t *alloc_node_to_present_cpumask(void)
>>  return NULL;
>>  }
>>  
>> -static void free_node_to_present_cpumask(cpumask_var_t *masks)
>> +static void free_node_to_possible_cpumask(cpumask_var_t *masks)
>>  {
>>  int node;
>>  
>> @@ -71,22 +71,22 @@ static void free_node_to_present_cpumask(cpumask_var_t 
>> *masks)
>>  kfree(masks);
>>  }
>>  
>> -static void build_node_to_present_cpumask(cpumask_var_t *masks)
>> +static void build_node_to_possible_cpumask(cpumask_var_t *masks)
>>  {
>>  int cpu;
>>  
>> -for_each_present_cpu(cpu)
>> +for_each_possible_cpu(cpu)
>>  cpumask_set_cpu(cpu, masks[cpu_to_node(cpu)]);
>>  }
>>  
>> -static int get_nodes_in_cpumask(cpumask_var_t *node_to_present_cpumask,
>> +static int get_nodes_in_cpumask(cpumask_var_t *node_to_possible_cpumask,
>>  const struct cpumask *mask, nodemask_t *nodemsk)
>>  {
>>  int n, nodes = 0;
>>  
>>  /* Calculate the number of nodes in the supplied affinity mask */
>>  for_each_node(n) {
>> -if (cpumask_intersects(mask, node_to_present_cpumask[n])) {
>> +if (cpumask_intersects(mask, node_to_possible_cpumask[n])) {
>>  node_set(n, *nodemsk);
>>  nodes++;
>>  }
>> @@ -109,7 +109,7 @@ irq_create_affinity_masks(int nvecs, const struct 
>> irq_affinity *affd)
>>  int last_affv = affv + affd->pre_vectors;
>>  nodemask_t nodemsk = NODE_MASK_NONE;
>>  struct cpumask *masks;
>> -cpumask_var_t nmsk, *node_to_present_cpumask;
>> +cpumask_var_t nmsk, *node_to_possible_cpumask;
>>  
>>  /*
>>   * If there aren't any vectors left after applying the pre/post
>> @@ -125,8 +125,8 @@ irq_create_affinity_masks(int nvecs, const struct 
>> irq_affinity *affd)
>>  if (!masks)
>>  goto out;
>>  
>> -node_to_present_cpumask = alloc_node_to_present_cpumask();
>> -if (!node_to_present_cpumask)
>> +node_to_possible_cpumask = alloc_node_to_possible_cpumask();
>> +if (!node_to_possible_cpumask)
>>  goto out;
>>  
>>  /* Fill out vectors at the beginning that don't need affinity */
>> @@ -135,8 +135,8 @@ irq_create_affinity_masks(int nvecs, const struct 
>> irq_affinity *affd)
>>  
>>  /* Stabilize the cpumasks */
>>  get_online_cpus();
>> -build_node_to_present_cpumask(node_to_present_cpumask);
>> -nodes = get_nodes_in_cpumask(node_to_present_cpumask, cpu_present_mask,
>> +build_node_to_possible_cpumask(node_to_possible_cpumask);
>> +nodes = get_nodes_in_cpumask(node_to_possible_cpumask, 
>> cpu_possible_mask,
>>   );
>>  
>>  /*
>> @@ -146,7 +146,7 @@ 

Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.

2018-03-30 Thread Pavel Machek
On Fri 2018-03-30 12:07:58, Ilya Smith wrote:
> Hi
> 
> > On 30 Mar 2018, at 10:55, Pavel Machek  wrote:
> > 
> > Hi!
> > 
> >> Current implementation doesn't randomize address returned by mmap.
> >> All the entropy ends with choosing mmap_base_addr at the process
> >> creation. After that mmap build very predictable layout of address
> >> space. It allows to bypass ASLR in many cases. This patch make
> >> randomization of address on any mmap call.
> > 
> > How will this interact with people debugging their application, and
> > getting different behaviours based on memory layout?
> > 
> > strace, strace again, get different results?
> > 
> 
> Honestly I’m confused about your question. If the only one way for debugging 
> application is to use predictable mmap behaviour, then something went wrong 
> in 
> this live and we should stop using computers at all.

I'm not saying "only way". I'm saying one way, and you are breaking
that. There's advanced stuff like debuggers going "back in time".

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


signature.asc
Description: Digital signature


Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.

2018-03-30 Thread Pavel Machek
On Fri 2018-03-30 12:07:58, Ilya Smith wrote:
> Hi
> 
> > On 30 Mar 2018, at 10:55, Pavel Machek  wrote:
> > 
> > Hi!
> > 
> >> Current implementation doesn't randomize address returned by mmap.
> >> All the entropy ends with choosing mmap_base_addr at the process
> >> creation. After that mmap build very predictable layout of address
> >> space. It allows to bypass ASLR in many cases. This patch make
> >> randomization of address on any mmap call.
> > 
> > How will this interact with people debugging their application, and
> > getting different behaviours based on memory layout?
> > 
> > strace, strace again, get different results?
> > 
> 
> Honestly I’m confused about your question. If the only one way for debugging 
> application is to use predictable mmap behaviour, then something went wrong 
> in 
> this live and we should stop using computers at all.

I'm not saying "only way". I'm saying one way, and you are breaking
that. There's advanced stuff like debuggers going "back in time".

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


signature.asc
Description: Digital signature


[PATCH v2 2/2] spi: spi-ti-qspi: Add checking which flash chip has been mmap-ed

2018-03-30 Thread Arkadiusz Kwiatkowski
This patch allows placing more than one flash chip on the qspi bus
by checking which spi device has been memory-mapped and remapping
if necessary.

Signed-off-by: Arkadiusz Kwiatkowski 
---
 drivers/spi/spi-ti-qspi.c | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/spi/spi-ti-qspi.c b/drivers/spi/spi-ti-qspi.c
index d0ea62d..5b99a1e 100644
--- a/drivers/spi/spi-ti-qspi.c
+++ b/drivers/spi/spi-ti-qspi.c
@@ -66,7 +66,7 @@ struct ti_qspi {
u32 cmd;
u32 dc;

-   bool mmap_enabled;
+   struct spi_device   *mmap_spi_device;
 };

 #define QSPI_PID   (0x0)
@@ -493,7 +493,7 @@ static void ti_qspi_enable_memory_map(struct spi_device 
*spi)
   MEM_CS_MASK,
   MEM_CS_EN(spi->chip_select));
}
-   qspi->mmap_enabled = true;
+   qspi->mmap_spi_device = spi;
 }

 static void ti_qspi_disable_memory_map(struct spi_device *spi)
@@ -504,7 +504,7 @@ static void ti_qspi_disable_memory_map(struct spi_device 
*spi)
if (qspi->ctrl_base)
regmap_update_bits(qspi->ctrl_base, qspi->ctrl_reg,
   MEM_CS_MASK, 0);
-   qspi->mmap_enabled = false;
+   qspi->mmap_spi_device = NULL;
 }

 static void ti_qspi_setup_mmap_read(struct spi_device *spi,
@@ -544,8 +544,12 @@ static int ti_qspi_spi_flash_read(struct spi_device *spi,

mutex_lock(>list_lock);

-   if (!qspi->mmap_enabled)
+   if (qspi->mmap_spi_device != spi) {
+   if (qspi->mmap_spi_device)
+   ti_qspi_disable_memory_map(qspi->mmap_spi_device);
ti_qspi_enable_memory_map(spi);
+   }
+
ti_qspi_setup_mmap_read(spi, msg);

if (qspi->rx_chan) {
@@ -600,7 +604,7 @@ static int ti_qspi_start_transfer_one(struct spi_master 
*master,

mutex_lock(>list_lock);

-   if (qspi->mmap_enabled)
+   if (qspi->mmap_spi_device)
ti_qspi_disable_memory_map(spi);

list_for_each_entry(t, >transfers, transfer_list) {
@@ -787,7 +791,7 @@ static int ti_qspi_probe(struct platform_device *pdev)
master->spi_flash_read = NULL;
}
}
-   qspi->mmap_enabled = false;
+   qspi->mmap_spi_device = NULL;

ret = devm_spi_register_master(>dev, master);
if (!ret)
--
2.7.4


 Note: If the reader of this message is not the intended recipient, or an 
employee or agent responsible for delivering this message to the intended 
recipient, you are hereby notified that any dissemination, distribution or 
copying of this communication is strictly prohibited. If you have received this 
communication in error, please notify us immediately by replying to the message 
and deleting it from your computer. Thank you. 



[PATCH v2 2/2] spi: spi-ti-qspi: Add checking which flash chip has been mmap-ed

2018-03-30 Thread Arkadiusz Kwiatkowski
This patch allows placing more than one flash chip on the qspi bus
by checking which spi device has been memory-mapped and remapping
if necessary.

Signed-off-by: Arkadiusz Kwiatkowski 
---
 drivers/spi/spi-ti-qspi.c | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/spi/spi-ti-qspi.c b/drivers/spi/spi-ti-qspi.c
index d0ea62d..5b99a1e 100644
--- a/drivers/spi/spi-ti-qspi.c
+++ b/drivers/spi/spi-ti-qspi.c
@@ -66,7 +66,7 @@ struct ti_qspi {
u32 cmd;
u32 dc;

-   bool mmap_enabled;
+   struct spi_device   *mmap_spi_device;
 };

 #define QSPI_PID   (0x0)
@@ -493,7 +493,7 @@ static void ti_qspi_enable_memory_map(struct spi_device 
*spi)
   MEM_CS_MASK,
   MEM_CS_EN(spi->chip_select));
}
-   qspi->mmap_enabled = true;
+   qspi->mmap_spi_device = spi;
 }

 static void ti_qspi_disable_memory_map(struct spi_device *spi)
@@ -504,7 +504,7 @@ static void ti_qspi_disable_memory_map(struct spi_device 
*spi)
if (qspi->ctrl_base)
regmap_update_bits(qspi->ctrl_base, qspi->ctrl_reg,
   MEM_CS_MASK, 0);
-   qspi->mmap_enabled = false;
+   qspi->mmap_spi_device = NULL;
 }

 static void ti_qspi_setup_mmap_read(struct spi_device *spi,
@@ -544,8 +544,12 @@ static int ti_qspi_spi_flash_read(struct spi_device *spi,

mutex_lock(>list_lock);

-   if (!qspi->mmap_enabled)
+   if (qspi->mmap_spi_device != spi) {
+   if (qspi->mmap_spi_device)
+   ti_qspi_disable_memory_map(qspi->mmap_spi_device);
ti_qspi_enable_memory_map(spi);
+   }
+
ti_qspi_setup_mmap_read(spi, msg);

if (qspi->rx_chan) {
@@ -600,7 +604,7 @@ static int ti_qspi_start_transfer_one(struct spi_master 
*master,

mutex_lock(>list_lock);

-   if (qspi->mmap_enabled)
+   if (qspi->mmap_spi_device)
ti_qspi_disable_memory_map(spi);

list_for_each_entry(t, >transfers, transfer_list) {
@@ -787,7 +791,7 @@ static int ti_qspi_probe(struct platform_device *pdev)
master->spi_flash_read = NULL;
}
}
-   qspi->mmap_enabled = false;
+   qspi->mmap_spi_device = NULL;

ret = devm_spi_register_master(>dev, master);
if (!ret)
--
2.7.4


 Note: If the reader of this message is not the intended recipient, or an 
employee or agent responsible for delivering this message to the intended 
recipient, you are hereby notified that any dissemination, distribution or 
copying of this communication is strictly prohibited. If you have received this 
communication in error, please notify us immediately by replying to the message 
and deleting it from your computer. Thank you. 



[PATCH v2 1/2] spi: spi-ti-qspi: Fix parameters order in regmap_update_bits calls

2018-03-30 Thread Arkadiusz Kwiatkowski
This commit fixes the order of parameters passed to regmap_update_bits
function inside spi-ti-qspi driver. Accidentally the code worked
correctly when cs=0, but it is not the case for other values.

Signed-off-by: Arkadiusz Kwiatkowski 
---
 drivers/spi/spi-ti-qspi.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/spi/spi-ti-qspi.c b/drivers/spi/spi-ti-qspi.c
index c24d9b4..d0ea62d 100644
--- a/drivers/spi/spi-ti-qspi.c
+++ b/drivers/spi/spi-ti-qspi.c
@@ -490,8 +490,8 @@ static void ti_qspi_enable_memory_map(struct spi_device 
*spi)
ti_qspi_write(qspi, MM_SWITCH, QSPI_SPI_SWITCH_REG);
if (qspi->ctrl_base) {
regmap_update_bits(qspi->ctrl_base, qspi->ctrl_reg,
-  MEM_CS_EN(spi->chip_select),
-  MEM_CS_MASK);
+  MEM_CS_MASK,
+  MEM_CS_EN(spi->chip_select));
}
qspi->mmap_enabled = true;
 }
@@ -503,7 +503,7 @@ static void ti_qspi_disable_memory_map(struct spi_device 
*spi)
ti_qspi_write(qspi, 0, QSPI_SPI_SWITCH_REG);
if (qspi->ctrl_base)
regmap_update_bits(qspi->ctrl_base, qspi->ctrl_reg,
-  0, MEM_CS_MASK);
+  MEM_CS_MASK, 0);
qspi->mmap_enabled = false;
 }

--
2.7.4


 Note: If the reader of this message is not the intended recipient, or an 
employee or agent responsible for delivering this message to the intended 
recipient, you are hereby notified that any dissemination, distribution or 
copying of this communication is strictly prohibited. If you have received this 
communication in error, please notify us immediately by replying to the message 
and deleting it from your computer. Thank you. 



[PATCH v2 1/2] spi: spi-ti-qspi: Fix parameters order in regmap_update_bits calls

2018-03-30 Thread Arkadiusz Kwiatkowski
This commit fixes the order of parameters passed to regmap_update_bits
function inside spi-ti-qspi driver. Accidentally the code worked
correctly when cs=0, but it is not the case for other values.

Signed-off-by: Arkadiusz Kwiatkowski 
---
 drivers/spi/spi-ti-qspi.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/spi/spi-ti-qspi.c b/drivers/spi/spi-ti-qspi.c
index c24d9b4..d0ea62d 100644
--- a/drivers/spi/spi-ti-qspi.c
+++ b/drivers/spi/spi-ti-qspi.c
@@ -490,8 +490,8 @@ static void ti_qspi_enable_memory_map(struct spi_device 
*spi)
ti_qspi_write(qspi, MM_SWITCH, QSPI_SPI_SWITCH_REG);
if (qspi->ctrl_base) {
regmap_update_bits(qspi->ctrl_base, qspi->ctrl_reg,
-  MEM_CS_EN(spi->chip_select),
-  MEM_CS_MASK);
+  MEM_CS_MASK,
+  MEM_CS_EN(spi->chip_select));
}
qspi->mmap_enabled = true;
 }
@@ -503,7 +503,7 @@ static void ti_qspi_disable_memory_map(struct spi_device 
*spi)
ti_qspi_write(qspi, 0, QSPI_SPI_SWITCH_REG);
if (qspi->ctrl_base)
regmap_update_bits(qspi->ctrl_base, qspi->ctrl_reg,
-  0, MEM_CS_MASK);
+  MEM_CS_MASK, 0);
qspi->mmap_enabled = false;
 }

--
2.7.4


 Note: If the reader of this message is not the intended recipient, or an 
employee or agent responsible for delivering this message to the intended 
recipient, you are hereby notified that any dissemination, distribution or 
copying of this communication is strictly prohibited. If you have received this 
communication in error, please notify us immediately by replying to the message 
and deleting it from your computer. Thank you. 



[PATCH 0/2] MCA support on Centaur CPU

2018-03-30 Thread David Wang
This patch set is to provide MCA support on new Centaur CPU. 

The first patch is used to tell the kernel that newer Centaur CPU support 
MCE broadcasting.

The second patch is used to tell the kernel that newer Centaur CPU support 
CMCI. 

David Wang (2):
  x86/mce: new centaur CPUs support MCE broadcasting
  x86/mce: add CMCI support for centaur CPUs

 arch/x86/kernel/cpu/mcheck/mce.c | 12 
 1 file changed, 12 insertions(+)

-- 
1.9.1



[PATCH 2/2] x86/mce: add CMCI support for centaur CPUs

2018-03-30 Thread David Wang
This patch is used to tell the kernel that centaur CPUs support CMCI
mechanism which is compatible with INTEL CMCI.

Signed-off-by: David Wang 
---
 arch/x86/kernel/cpu/mcheck/mce.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 82b25e1..62aa85c 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -1751,6 +1751,7 @@ static void __mcheck_cpu_init_vendor(struct cpuinfo_x86 
*c)
 {
switch (c->x86_vendor) {
case X86_VENDOR_INTEL:
+   case X86_VENDOR_CENTAUR:
mce_intel_feature_init(c);
mce_adjust_timer = cmci_intel_adjust_timer;
break;
-- 
1.9.1



[PATCH 1/2] x86/mce: new centaur CPUs support MCE broadcasting

2018-03-30 Thread David Wang
This patch is used to tell the kernel that newer Centaur CPU support MCE
broadcasting.

Signed-off-by: David Wang 
---
 arch/x86/kernel/cpu/mcheck/mce.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 7065846..82b25e1 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -1688,6 +1688,17 @@ static int __mcheck_cpu_apply_quirks(struct cpuinfo_x86 
*c)
if (c->x86 == 6 && c->x86_model == 45)
quirk_no_way_out = quirk_sandybridge_ifu;
}
+
+   if (c->x86_vendor == X86_VENDOR_CENTAUR) {
+   /*
+* All newer centaur CPUs support MCE broadcasting. Enable
+* synchronization with a one second timeout.
+*/
+   if ((c->x86 > 6 || (c->x86 == 6 && c->x86_model == 0xf && 
c->x86_mask >=0xe)) &&
+   cfg->monarch_timeout < 0)
+   cfg->monarch_timeout = USEC_PER_SEC;
+   }
+
if (cfg->monarch_timeout < 0)
cfg->monarch_timeout = 0;
if (cfg->bootlog != 0)
-- 
1.9.1



[PATCH 0/2] MCA support on Centaur CPU

2018-03-30 Thread David Wang
This patch set is to provide MCA support on new Centaur CPU. 

The first patch is used to tell the kernel that newer Centaur CPU support 
MCE broadcasting.

The second patch is used to tell the kernel that newer Centaur CPU support 
CMCI. 

David Wang (2):
  x86/mce: new centaur CPUs support MCE broadcasting
  x86/mce: add CMCI support for centaur CPUs

 arch/x86/kernel/cpu/mcheck/mce.c | 12 
 1 file changed, 12 insertions(+)

-- 
1.9.1



[PATCH 2/2] x86/mce: add CMCI support for centaur CPUs

2018-03-30 Thread David Wang
This patch is used to tell the kernel that centaur CPUs support CMCI
mechanism which is compatible with INTEL CMCI.

Signed-off-by: David Wang 
---
 arch/x86/kernel/cpu/mcheck/mce.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 82b25e1..62aa85c 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -1751,6 +1751,7 @@ static void __mcheck_cpu_init_vendor(struct cpuinfo_x86 
*c)
 {
switch (c->x86_vendor) {
case X86_VENDOR_INTEL:
+   case X86_VENDOR_CENTAUR:
mce_intel_feature_init(c);
mce_adjust_timer = cmci_intel_adjust_timer;
break;
-- 
1.9.1



[PATCH 1/2] x86/mce: new centaur CPUs support MCE broadcasting

2018-03-30 Thread David Wang
This patch is used to tell the kernel that newer Centaur CPU support MCE
broadcasting.

Signed-off-by: David Wang 
---
 arch/x86/kernel/cpu/mcheck/mce.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 7065846..82b25e1 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -1688,6 +1688,17 @@ static int __mcheck_cpu_apply_quirks(struct cpuinfo_x86 
*c)
if (c->x86 == 6 && c->x86_model == 45)
quirk_no_way_out = quirk_sandybridge_ifu;
}
+
+   if (c->x86_vendor == X86_VENDOR_CENTAUR) {
+   /*
+* All newer centaur CPUs support MCE broadcasting. Enable
+* synchronization with a one second timeout.
+*/
+   if ((c->x86 > 6 || (c->x86 == 6 && c->x86_model == 0xf && 
c->x86_mask >=0xe)) &&
+   cfg->monarch_timeout < 0)
+   cfg->monarch_timeout = USEC_PER_SEC;
+   }
+
if (cfg->monarch_timeout < 0)
cfg->monarch_timeout = 0;
if (cfg->bootlog != 0)
-- 
1.9.1



Re: [PATCH] netfilter: ipset: Use is_zero_ether_addr instead of static and memcmp

2018-03-30 Thread Pablo Neira Ayuso
On Tue, Mar 20, 2018 at 10:35:47AM -0700, Joe Perches wrote:
> To make the test a bit clearer and to reduce object size a little.
> 
> Miscellanea:
> 
> o remove now unnecessary static const array
> 
> $ size ip_set_hash_mac.o*
>text  data bss dec hex filename
>   22822  4619  64   275056b71 
> ip_set_hash_mac.o.allyesconfig.new
>   22932  4683  64   276796c1f 
> ip_set_hash_mac.o.allyesconfig.old
>   10443  1040   0   114832cdb ip_set_hash_mac.o.defconfig.new
>   10507  1040   0   115472d1b ip_set_hash_mac.o.defconfig.old

Applied, thanks Joe.


Re: [PATCH] netfilter: ipset: Use is_zero_ether_addr instead of static and memcmp

2018-03-30 Thread Pablo Neira Ayuso
On Tue, Mar 20, 2018 at 10:35:47AM -0700, Joe Perches wrote:
> To make the test a bit clearer and to reduce object size a little.
> 
> Miscellanea:
> 
> o remove now unnecessary static const array
> 
> $ size ip_set_hash_mac.o*
>text  data bss dec hex filename
>   22822  4619  64   275056b71 
> ip_set_hash_mac.o.allyesconfig.new
>   22932  4683  64   276796c1f 
> ip_set_hash_mac.o.allyesconfig.old
>   10443  1040   0   114832cdb ip_set_hash_mac.o.defconfig.new
>   10507  1040   0   115472d1b ip_set_hash_mac.o.defconfig.old

Applied, thanks Joe.


Re: [PATCH] bridge: netfilter: ebt_stp: Use generic functions for comparisons

2018-03-30 Thread Pablo Neira Ayuso
On Wed, Mar 21, 2018 at 04:03:22AM -0700, Joe Perches wrote:
> Instead of unnecessary const declarations, use the generic functions to
> save a little object space.
> 
> $ size net/bridge/netfilter/ebt_stp.o*
>text  data bss dec hex filename
>1250   144   01394 572 
> net/bridge/netfilter/ebt_stp.o.new
>1344   144   01488 5d0 
> net/bridge/netfilter/ebt_stp.o.old

Applied, thanks Joe.


Re: [PATCH] bridge: netfilter: ebt_stp: Use generic functions for comparisons

2018-03-30 Thread Pablo Neira Ayuso
On Wed, Mar 21, 2018 at 04:03:22AM -0700, Joe Perches wrote:
> Instead of unnecessary const declarations, use the generic functions to
> save a little object space.
> 
> $ size net/bridge/netfilter/ebt_stp.o*
>text  data bss dec hex filename
>1250   144   01394 572 
> net/bridge/netfilter/ebt_stp.o.new
>1344   144   01488 5d0 
> net/bridge/netfilter/ebt_stp.o.old

Applied, thanks Joe.


[PATCH] cpufreq: intel_pstate: Do not include debugfs.h

2018-03-30 Thread Rafael J. Wysocki
From: Rafael J. Wysocki 

The intel_pstate driver doesn't use debugfs any more, so drop
linux/debugfs.h from the list of included headers in it.

Signed-off-by: Rafael J. Wysocki 
---
 drivers/cpufreq/intel_pstate.c |1 -
 1 file changed, 1 deletion(-)

Index: linux-pm/drivers/cpufreq/intel_pstate.c
===
--- linux-pm.orig/drivers/cpufreq/intel_pstate.c
+++ linux-pm/drivers/cpufreq/intel_pstate.c
@@ -26,7 +26,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 



[PATCH] cpufreq: intel_pstate: Do not include debugfs.h

2018-03-30 Thread Rafael J. Wysocki
From: Rafael J. Wysocki 

The intel_pstate driver doesn't use debugfs any more, so drop
linux/debugfs.h from the list of included headers in it.

Signed-off-by: Rafael J. Wysocki 
---
 drivers/cpufreq/intel_pstate.c |1 -
 1 file changed, 1 deletion(-)

Index: linux-pm/drivers/cpufreq/intel_pstate.c
===
--- linux-pm.orig/drivers/cpufreq/intel_pstate.c
+++ linux-pm/drivers/cpufreq/intel_pstate.c
@@ -26,7 +26,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 



Re: [PATCH 3/3] iio: adc: meson-axg: add saradc driver

2018-03-30 Thread Jonathan Cameron
On Mon, 26 Mar 2018 16:46:29 +0800
Yixun Lan  wrote:

> From: Xingyu Chen 
> 
> Add the SAR ADC driver for the Amlogic Meson-AXG SoC.
> 
> Signed-off-by: Xingyu Chen 
Applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to play with it.

Thanks,

Jonathan

> ---
>  drivers/iio/adc/meson_saradc.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/iio/adc/meson_saradc.c b/drivers/iio/adc/meson_saradc.c
> index 799ed929ab99..a5d481a2b4ef 100644
> --- a/drivers/iio/adc/meson_saradc.c
> +++ b/drivers/iio/adc/meson_saradc.c
> @@ -935,6 +935,11 @@ static const struct meson_sar_adc_data 
> meson_sar_adc_gxm_data = {
>   .name = "meson-gxm-saradc",
>  };
>  
> +static const struct meson_sar_adc_data meson_sar_adc_axg_data = {
> + .param = _sar_adc_gxl_param,
> + .name = "meson-axg-saradc",
> +};
> +
>  static const struct of_device_id meson_sar_adc_of_match[] = {
>   {
>   .compatible = "amlogic,meson8-saradc",
> @@ -953,6 +958,9 @@ static const struct of_device_id meson_sar_adc_of_match[] 
> = {
>   }, {
>   .compatible = "amlogic,meson-gxm-saradc",
>   .data = _sar_adc_gxm_data,
> + }, {
> + .compatible = "amlogic,meson-axg-saradc",
> + .data = _sar_adc_axg_data,
>   },
>   {},
>  };



Re: [PATCH 3/3] iio: adc: meson-axg: add saradc driver

2018-03-30 Thread Jonathan Cameron
On Mon, 26 Mar 2018 16:46:29 +0800
Yixun Lan  wrote:

> From: Xingyu Chen 
> 
> Add the SAR ADC driver for the Amlogic Meson-AXG SoC.
> 
> Signed-off-by: Xingyu Chen 
Applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to play with it.

Thanks,

Jonathan

> ---
>  drivers/iio/adc/meson_saradc.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/iio/adc/meson_saradc.c b/drivers/iio/adc/meson_saradc.c
> index 799ed929ab99..a5d481a2b4ef 100644
> --- a/drivers/iio/adc/meson_saradc.c
> +++ b/drivers/iio/adc/meson_saradc.c
> @@ -935,6 +935,11 @@ static const struct meson_sar_adc_data 
> meson_sar_adc_gxm_data = {
>   .name = "meson-gxm-saradc",
>  };
>  
> +static const struct meson_sar_adc_data meson_sar_adc_axg_data = {
> + .param = _sar_adc_gxl_param,
> + .name = "meson-axg-saradc",
> +};
> +
>  static const struct of_device_id meson_sar_adc_of_match[] = {
>   {
>   .compatible = "amlogic,meson8-saradc",
> @@ -953,6 +958,9 @@ static const struct of_device_id meson_sar_adc_of_match[] 
> = {
>   }, {
>   .compatible = "amlogic,meson-gxm-saradc",
>   .data = _sar_adc_gxm_data,
> + }, {
> + .compatible = "amlogic,meson-axg-saradc",
> + .data = _sar_adc_axg_data,
>   },
>   {},
>  };



Re: [PATCH] net: netfilter: Merge assignment with return

2018-03-30 Thread Pablo Neira Ayuso
On Thu, Mar 29, 2018 at 12:39:50AM +0530, Arushi Singhal wrote:
> Merge assignment with return statement to directly return the value.

Applied, thanks Arushi.


Re: [PATCH] net: netfilter: Merge assignment with return

2018-03-30 Thread Pablo Neira Ayuso
On Thu, Mar 29, 2018 at 12:39:50AM +0530, Arushi Singhal wrote:
> Merge assignment with return statement to directly return the value.

Applied, thanks Arushi.


Re: [PATCH] OPTIONAL: cpufreq/intel_pstate: fix debugfs_simple_attr.cocci warnings

2018-03-30 Thread Rafael J. Wysocki
Hi Julia,

On Thursday, March 29, 2018 9:12:06 PM CEST Julia Lawall wrote:
>  Use DEFINE_DEBUGFS_ATTRIBUTE rather than DEFINE_SIMPLE_ATTRIBUTE
>  for debugfs files.
> 
> Semantic patch information:
>  Rationale: DEFINE_SIMPLE_ATTRIBUTE + debugfs_create_file()
>  imposes some significant overhead as compared to
>  DEFINE_DEBUGFS_ATTRIBUTE + debugfs_create_file_unsafe().
> 
> Generated by: scripts/coccinelle/api/debugfs/debugfs_simple_attr.cocci

We've dropped the debugfs bits from intel_pstate entirely, so this change
is not applicable any more.

Thanks!

> Fixes: 9eec7989e762 ("OPTIONAL: cpufreq/intel_pstate: Expose LP controller 
> parameters via debugfs.")
> CC: Francisco Jerez 
> Signed-off-by: Fengguang Wu 
> Signed-off-by: Julia Lawall 
> ---
> 
> I don't actually know anything about this issue.  The change was suggested
> by kbuild.
> 
>  intel_pstate.c |9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
> 
> --- a/drivers/cpufreq/intel_pstate.c
> +++ b/drivers/cpufreq/intel_pstate.c
> @@ -885,7 +885,7 @@ static int lp_param_get(void *data, u64
>   *val = *(u32 *)data;
>   return 0;
>  }
> -DEFINE_SIMPLE_ATTRIBUTE(fops_lp_param, lp_param_get, lp_param_set, "%llu\n");
> +DEFINE_DEBUGFS_ATTRIBUTE(fops_lp_param, lp_param_get, lp_param_set, 
> "%llu\n");
> 
>  static struct dentry *debugfs_parent;
> 
> @@ -922,9 +922,10 @@ static void intel_pstate_debug_expose_pa
>   for (i = 0; lp_files[i].name; i++) {
>   struct dentry *dentry;
> 
> - dentry = debugfs_create_file(lp_files[i].name, 0660,
> -  debugfs_parent, lp_files[i].value,
> -  _lp_param);
> + dentry = debugfs_create_file_unsafe(lp_files[i].name, 0660,
> + debugfs_parent,
> + lp_files[i].value,
> + _lp_param);
>   if (!IS_ERR(dentry))
>   lp_files[i].dentry = dentry;
>   }
> 




Re: [PATCH] OPTIONAL: cpufreq/intel_pstate: fix debugfs_simple_attr.cocci warnings

2018-03-30 Thread Rafael J. Wysocki
Hi Julia,

On Thursday, March 29, 2018 9:12:06 PM CEST Julia Lawall wrote:
>  Use DEFINE_DEBUGFS_ATTRIBUTE rather than DEFINE_SIMPLE_ATTRIBUTE
>  for debugfs files.
> 
> Semantic patch information:
>  Rationale: DEFINE_SIMPLE_ATTRIBUTE + debugfs_create_file()
>  imposes some significant overhead as compared to
>  DEFINE_DEBUGFS_ATTRIBUTE + debugfs_create_file_unsafe().
> 
> Generated by: scripts/coccinelle/api/debugfs/debugfs_simple_attr.cocci

We've dropped the debugfs bits from intel_pstate entirely, so this change
is not applicable any more.

Thanks!

> Fixes: 9eec7989e762 ("OPTIONAL: cpufreq/intel_pstate: Expose LP controller 
> parameters via debugfs.")
> CC: Francisco Jerez 
> Signed-off-by: Fengguang Wu 
> Signed-off-by: Julia Lawall 
> ---
> 
> I don't actually know anything about this issue.  The change was suggested
> by kbuild.
> 
>  intel_pstate.c |9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
> 
> --- a/drivers/cpufreq/intel_pstate.c
> +++ b/drivers/cpufreq/intel_pstate.c
> @@ -885,7 +885,7 @@ static int lp_param_get(void *data, u64
>   *val = *(u32 *)data;
>   return 0;
>  }
> -DEFINE_SIMPLE_ATTRIBUTE(fops_lp_param, lp_param_get, lp_param_set, "%llu\n");
> +DEFINE_DEBUGFS_ATTRIBUTE(fops_lp_param, lp_param_get, lp_param_set, 
> "%llu\n");
> 
>  static struct dentry *debugfs_parent;
> 
> @@ -922,9 +922,10 @@ static void intel_pstate_debug_expose_pa
>   for (i = 0; lp_files[i].name; i++) {
>   struct dentry *dentry;
> 
> - dentry = debugfs_create_file(lp_files[i].name, 0660,
> -  debugfs_parent, lp_files[i].value,
> -  _lp_param);
> + dentry = debugfs_create_file_unsafe(lp_files[i].name, 0660,
> + debugfs_parent,
> + lp_files[i].value,
> + _lp_param);
>   if (!IS_ERR(dentry))
>   lp_files[i].dentry = dentry;
>   }
> 




Re: [PATCH 2/3] dt-bindings: iio: adc: document the Meson AXG support

2018-03-30 Thread Jonathan Cameron
On Tue, 27 Mar 2018 10:07:30 -0500
Rob Herring  wrote:

> On Mon, Mar 26, 2018 at 04:46:28PM +0800, Yixun Lan wrote:
> > From: Xingyu Chen 
> > 
> > Update the documentation to expicitly support the Meson-AXG SoC.
> > 
> > Signed-off-by: Xingyu Chen 
> > ---
> >  Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.txt | 1 +
> >  1 file changed, 1 insertion(+)  
> 
> Reviewed-by: Rob Herring 

Applied to the togreg branch of iio.git and pushed out as testing for
the autobuilders to ignore it ;)

Thanks,

Jonathan


Re: [PATCH 2/3] dt-bindings: iio: adc: document the Meson AXG support

2018-03-30 Thread Jonathan Cameron
On Tue, 27 Mar 2018 10:07:30 -0500
Rob Herring  wrote:

> On Mon, Mar 26, 2018 at 04:46:28PM +0800, Yixun Lan wrote:
> > From: Xingyu Chen 
> > 
> > Update the documentation to expicitly support the Meson-AXG SoC.
> > 
> > Signed-off-by: Xingyu Chen 
> > ---
> >  Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.txt | 1 +
> >  1 file changed, 1 insertion(+)  
> 
> Reviewed-by: Rob Herring 

Applied to the togreg branch of iio.git and pushed out as testing for
the autobuilders to ignore it ;)

Thanks,

Jonathan


Re: [PATCH 2/2] net: mvneta: improve suspend/resume

2018-03-30 Thread Thomas Petazzoni
Hello,

On Fri, 30 Mar 2018 17:15:47 +0800, Jisheng Zhang wrote:

> > > + cpuhp_state_remove_instance_nocalls(online_hpstate,
> > > + >node_online);
> > > + cpuhp_state_remove_instance_nocalls(CPUHP_NET_MVNETA_DEAD,
> > > + >node_dead);
> > 
> > Do we need to remove/add those CPU notifiers when suspending/resuming ?  
> 
> Take mvneta_cpu_online() as an example, if we don't remove it during
> suspend, when system is resume back, it will touch mac when secondary
> cpu is ON, but at this point the mvneta isn't resumed, this is not safe.

Hm. I'm still a bit confused by this new CPU hotplug API. I understand
the issue you have and indeed unregistering the CPU hotplug callbacks
is a way to solve the problem, but I find it weird that we have to do
this.

Anyway, it's OK to do it, because it's anyway what was done so far. It
is just annoying that there is a duplication of the logic between
mvneta_suspend() and mvneta_stop() on one side, and duplication between
mvneta_resume() and mvnete_start() on the other side.

> > > + for (queue = 0; queue < rxq_number; queue++) {
> > > + struct mvneta_rx_queue *rxq = >rxqs[queue];
> > > +
> > > + mvneta_rxq_drop_pkts(pp, rxq);
> > > + }
> > 
> > Wouldn't it make sense to have
> > mvneta_rxq_sw_deinit/mvneta_rxq_hw_deinit(), like you did for the
> > initialization ?  
> 
> For rxq deinit, we'd like to drop rx pkts, this is both HW and SW operation.
> So we reuse mvneta_rxq_drop_pkts() here.

Hum, OK, indeed. It would have been nicer to have something symmetric,
with the hw/sw parts split in a similar way for the init and deinit of
both txqs and rxqs, but I agree that dropping the RX packets before
going into suspend involves both HW and SW operations.

Thanks!

Thomas Petazzoni
-- 
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


Re: [PATCH 2/2] net: mvneta: improve suspend/resume

2018-03-30 Thread Thomas Petazzoni
Hello,

On Fri, 30 Mar 2018 17:15:47 +0800, Jisheng Zhang wrote:

> > > + cpuhp_state_remove_instance_nocalls(online_hpstate,
> > > + >node_online);
> > > + cpuhp_state_remove_instance_nocalls(CPUHP_NET_MVNETA_DEAD,
> > > + >node_dead);
> > 
> > Do we need to remove/add those CPU notifiers when suspending/resuming ?  
> 
> Take mvneta_cpu_online() as an example, if we don't remove it during
> suspend, when system is resume back, it will touch mac when secondary
> cpu is ON, but at this point the mvneta isn't resumed, this is not safe.

Hm. I'm still a bit confused by this new CPU hotplug API. I understand
the issue you have and indeed unregistering the CPU hotplug callbacks
is a way to solve the problem, but I find it weird that we have to do
this.

Anyway, it's OK to do it, because it's anyway what was done so far. It
is just annoying that there is a duplication of the logic between
mvneta_suspend() and mvneta_stop() on one side, and duplication between
mvneta_resume() and mvnete_start() on the other side.

> > > + for (queue = 0; queue < rxq_number; queue++) {
> > > + struct mvneta_rx_queue *rxq = >rxqs[queue];
> > > +
> > > + mvneta_rxq_drop_pkts(pp, rxq);
> > > + }
> > 
> > Wouldn't it make sense to have
> > mvneta_rxq_sw_deinit/mvneta_rxq_hw_deinit(), like you did for the
> > initialization ?  
> 
> For rxq deinit, we'd like to drop rx pkts, this is both HW and SW operation.
> So we reuse mvneta_rxq_drop_pkts() here.

Hum, OK, indeed. It would have been nicer to have something symmetric,
with the hw/sw parts split in a similar way for the init and deinit of
both txqs and rxqs, but I agree that dropping the RX packets before
going into suspend involves both HW and SW operations.

Thanks!

Thomas Petazzoni
-- 
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


Re: [PATCH 1/3] iio: adc: meson-saradc: squash and share the common adc platform data

2018-03-30 Thread Jonathan Cameron
On Mon, 26 Mar 2018 16:46:27 +0800
Yixun Lan  wrote:

> Extract and promote common adc platform data into a new structure,
> to make it better share the info between several SoCs,
> this will avoid duplicating the code all over the place,
> Save a few memory and make the code more maintainable.
> 
> Signed-off-by: Yixun Lan 
Applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to play with it.

Thanks,

Jonathan

> ---
>  drivers/iio/adc/meson_saradc.c | 75 
> +++---
>  1 file changed, 42 insertions(+), 33 deletions(-)
> 
> diff --git a/drivers/iio/adc/meson_saradc.c b/drivers/iio/adc/meson_saradc.c
> index 29fa7736d80c..799ed929ab99 100644
> --- a/drivers/iio/adc/meson_saradc.c
> +++ b/drivers/iio/adc/meson_saradc.c
> @@ -219,15 +219,19 @@ enum meson_sar_adc_chan7_mux_sel {
>   CHAN7_MUX_CH7_INPUT = 0x7,
>  };
>  
> -struct meson_sar_adc_data {
> +struct meson_sar_adc_param {
>   boolhas_bl30_integration;
>   unsigned long   clock_rate;
>   u32 bandgap_reg;
>   unsigned intresolution;
> - const char  *name;
>   const struct regmap_config  *regmap_config;
>  };
>  
> +struct meson_sar_adc_data {
> + const struct meson_sar_adc_param*param;
> + const char  *name;
> +};
> +
>  struct meson_sar_adc_priv {
>   struct regmap   *regmap;
>   struct regulator*vref;
> @@ -276,7 +280,7 @@ static int meson_sar_adc_calib_val(struct iio_dev 
> *indio_dev, int val)
>   /* use val_calib = scale * val_raw + offset calibration function */
>   tmp = div_s64((s64)val * priv->calibscale, MILLION) + priv->calibbias;
>  
> - return clamp(tmp, 0, (1 << priv->data->resolution) - 1);
> + return clamp(tmp, 0, (1 << priv->data->param->resolution) - 1);
>  }
>  
>  static int meson_sar_adc_wait_busy_clear(struct iio_dev *indio_dev)
> @@ -328,7 +332,7 @@ static int meson_sar_adc_read_raw_sample(struct iio_dev 
> *indio_dev,
>   }
>  
>   fifo_val = FIELD_GET(MESON_SAR_ADC_FIFO_RD_SAMPLE_VALUE_MASK, regval);
> - fifo_val &= GENMASK(priv->data->resolution - 1, 0);
> + fifo_val &= GENMASK(priv->data->param->resolution - 1, 0);
>   *val = meson_sar_adc_calib_val(indio_dev, fifo_val);
>  
>   return 0;
> @@ -447,7 +451,7 @@ static int meson_sar_adc_lock(struct iio_dev *indio_dev)
>  
>   mutex_lock(_dev->mlock);
>  
> - if (priv->data->has_bl30_integration) {
> + if (priv->data->param->has_bl30_integration) {
>   /* prevent BL30 from using the SAR ADC while we are using it */
>   regmap_update_bits(priv->regmap, MESON_SAR_ADC_DELAY,
>   MESON_SAR_ADC_DELAY_KERNEL_BUSY,
> @@ -473,7 +477,7 @@ static void meson_sar_adc_unlock(struct iio_dev 
> *indio_dev)
>  {
>   struct meson_sar_adc_priv *priv = iio_priv(indio_dev);
>  
> - if (priv->data->has_bl30_integration)
> + if (priv->data->param->has_bl30_integration)
>   /* allow BL30 to use the SAR ADC again */
>   regmap_update_bits(priv->regmap, MESON_SAR_ADC_DELAY,
>   MESON_SAR_ADC_DELAY_KERNEL_BUSY, 0);
> @@ -557,7 +561,7 @@ static int meson_sar_adc_iio_info_read_raw(struct iio_dev 
> *indio_dev,
>   }
>  
>   *val = ret / 1000;
> - *val2 = priv->data->resolution;
> + *val2 = priv->data->param->resolution;
>   return IIO_VAL_FRACTIONAL_LOG2;
>  
>   case IIO_CHAN_INFO_CALIBBIAS:
> @@ -630,7 +634,7 @@ static int meson_sar_adc_init(struct iio_dev *indio_dev)
>*/
>   meson_sar_adc_set_chan7_mux(indio_dev, CHAN7_MUX_CH7_INPUT);
>  
> - if (priv->data->has_bl30_integration) {
> + if (priv->data->param->has_bl30_integration) {
>   /*
>* leave sampling delay and the input clocks as configured by
>* BL30 to make sure BL30 gets the values it expects when
> @@ -710,7 +714,7 @@ static int meson_sar_adc_init(struct iio_dev *indio_dev)
>   return ret;
>   }
>  
> - ret = clk_set_rate(priv->adc_clk, priv->data->clock_rate);
> + ret = clk_set_rate(priv->adc_clk, priv->data->param->clock_rate);
>   if (ret) {
>   dev_err(indio_dev->dev.parent,
>   "failed to set adc clock rate\n");
> @@ -723,14 +727,15 @@ static int meson_sar_adc_init(struct iio_dev *indio_dev)
>  static void meson_sar_adc_set_bandgap(struct iio_dev *indio_dev, bool on_off)
>  {
>   struct meson_sar_adc_priv *priv = iio_priv(indio_dev);
> + const struct meson_sar_adc_param *param = priv->data->param;
>   u32 enable_mask;
>  
> - if (priv->data->bandgap_reg == 

Re: [PATCH 1/3] iio: adc: meson-saradc: squash and share the common adc platform data

2018-03-30 Thread Jonathan Cameron
On Mon, 26 Mar 2018 16:46:27 +0800
Yixun Lan  wrote:

> Extract and promote common adc platform data into a new structure,
> to make it better share the info between several SoCs,
> this will avoid duplicating the code all over the place,
> Save a few memory and make the code more maintainable.
> 
> Signed-off-by: Yixun Lan 
Applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to play with it.

Thanks,

Jonathan

> ---
>  drivers/iio/adc/meson_saradc.c | 75 
> +++---
>  1 file changed, 42 insertions(+), 33 deletions(-)
> 
> diff --git a/drivers/iio/adc/meson_saradc.c b/drivers/iio/adc/meson_saradc.c
> index 29fa7736d80c..799ed929ab99 100644
> --- a/drivers/iio/adc/meson_saradc.c
> +++ b/drivers/iio/adc/meson_saradc.c
> @@ -219,15 +219,19 @@ enum meson_sar_adc_chan7_mux_sel {
>   CHAN7_MUX_CH7_INPUT = 0x7,
>  };
>  
> -struct meson_sar_adc_data {
> +struct meson_sar_adc_param {
>   boolhas_bl30_integration;
>   unsigned long   clock_rate;
>   u32 bandgap_reg;
>   unsigned intresolution;
> - const char  *name;
>   const struct regmap_config  *regmap_config;
>  };
>  
> +struct meson_sar_adc_data {
> + const struct meson_sar_adc_param*param;
> + const char  *name;
> +};
> +
>  struct meson_sar_adc_priv {
>   struct regmap   *regmap;
>   struct regulator*vref;
> @@ -276,7 +280,7 @@ static int meson_sar_adc_calib_val(struct iio_dev 
> *indio_dev, int val)
>   /* use val_calib = scale * val_raw + offset calibration function */
>   tmp = div_s64((s64)val * priv->calibscale, MILLION) + priv->calibbias;
>  
> - return clamp(tmp, 0, (1 << priv->data->resolution) - 1);
> + return clamp(tmp, 0, (1 << priv->data->param->resolution) - 1);
>  }
>  
>  static int meson_sar_adc_wait_busy_clear(struct iio_dev *indio_dev)
> @@ -328,7 +332,7 @@ static int meson_sar_adc_read_raw_sample(struct iio_dev 
> *indio_dev,
>   }
>  
>   fifo_val = FIELD_GET(MESON_SAR_ADC_FIFO_RD_SAMPLE_VALUE_MASK, regval);
> - fifo_val &= GENMASK(priv->data->resolution - 1, 0);
> + fifo_val &= GENMASK(priv->data->param->resolution - 1, 0);
>   *val = meson_sar_adc_calib_val(indio_dev, fifo_val);
>  
>   return 0;
> @@ -447,7 +451,7 @@ static int meson_sar_adc_lock(struct iio_dev *indio_dev)
>  
>   mutex_lock(_dev->mlock);
>  
> - if (priv->data->has_bl30_integration) {
> + if (priv->data->param->has_bl30_integration) {
>   /* prevent BL30 from using the SAR ADC while we are using it */
>   regmap_update_bits(priv->regmap, MESON_SAR_ADC_DELAY,
>   MESON_SAR_ADC_DELAY_KERNEL_BUSY,
> @@ -473,7 +477,7 @@ static void meson_sar_adc_unlock(struct iio_dev 
> *indio_dev)
>  {
>   struct meson_sar_adc_priv *priv = iio_priv(indio_dev);
>  
> - if (priv->data->has_bl30_integration)
> + if (priv->data->param->has_bl30_integration)
>   /* allow BL30 to use the SAR ADC again */
>   regmap_update_bits(priv->regmap, MESON_SAR_ADC_DELAY,
>   MESON_SAR_ADC_DELAY_KERNEL_BUSY, 0);
> @@ -557,7 +561,7 @@ static int meson_sar_adc_iio_info_read_raw(struct iio_dev 
> *indio_dev,
>   }
>  
>   *val = ret / 1000;
> - *val2 = priv->data->resolution;
> + *val2 = priv->data->param->resolution;
>   return IIO_VAL_FRACTIONAL_LOG2;
>  
>   case IIO_CHAN_INFO_CALIBBIAS:
> @@ -630,7 +634,7 @@ static int meson_sar_adc_init(struct iio_dev *indio_dev)
>*/
>   meson_sar_adc_set_chan7_mux(indio_dev, CHAN7_MUX_CH7_INPUT);
>  
> - if (priv->data->has_bl30_integration) {
> + if (priv->data->param->has_bl30_integration) {
>   /*
>* leave sampling delay and the input clocks as configured by
>* BL30 to make sure BL30 gets the values it expects when
> @@ -710,7 +714,7 @@ static int meson_sar_adc_init(struct iio_dev *indio_dev)
>   return ret;
>   }
>  
> - ret = clk_set_rate(priv->adc_clk, priv->data->clock_rate);
> + ret = clk_set_rate(priv->adc_clk, priv->data->param->clock_rate);
>   if (ret) {
>   dev_err(indio_dev->dev.parent,
>   "failed to set adc clock rate\n");
> @@ -723,14 +727,15 @@ static int meson_sar_adc_init(struct iio_dev *indio_dev)
>  static void meson_sar_adc_set_bandgap(struct iio_dev *indio_dev, bool on_off)
>  {
>   struct meson_sar_adc_priv *priv = iio_priv(indio_dev);
> + const struct meson_sar_adc_param *param = priv->data->param;
>   u32 enable_mask;
>  
> - if (priv->data->bandgap_reg == MESON_SAR_ADC_REG11)
> + if (param->bandgap_reg == 

[PATCH 0/3] clk: uniphier: add support for PCIe, SATA and ethernet

2018-03-30 Thread Kunihiko Hayashi
Add clock lines for PCI-express and SATA controllers implemented on
UniPhier SoCs, and additional clock lines for ethernet controller on Pro4.

Kunihiko Hayashi (3):
  clk: uniphier: add PCIe clock control support
  clk: uniphier: add SATA clock control support
  clk: uniphier: add additional ethernet clock lines for Pro4

 drivers/clk/uniphier/clk-uniphier-sys.c | 12 
 1 file changed, 12 insertions(+)

-- 
2.7.4



[PATCH 0/3] clk: uniphier: add support for PCIe, SATA and ethernet

2018-03-30 Thread Kunihiko Hayashi
Add clock lines for PCI-express and SATA controllers implemented on
UniPhier SoCs, and additional clock lines for ethernet controller on Pro4.

Kunihiko Hayashi (3):
  clk: uniphier: add PCIe clock control support
  clk: uniphier: add SATA clock control support
  clk: uniphier: add additional ethernet clock lines for Pro4

 drivers/clk/uniphier/clk-uniphier-sys.c | 12 
 1 file changed, 12 insertions(+)

-- 
2.7.4



[PATCH 2/2] reset: uniphier: add SATA reset control support and change SATA-PHY ID

2018-03-30 Thread Kunihiko Hayashi
Add reset lines for SATA controller on UniPhier SoCs.
This adds support for Pro4 and PXs3 in addition to PXs2.

And this changes the ID of the reset line for SATA-PHY on PXs2.
Since some SoCs have two controller instances with a common PHY, this moves
the ID of SATA-PHY for consistency.

Signed-off-by: Kunihiko Hayashi 
---
 drivers/reset/reset-uniphier.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/reset/reset-uniphier.c b/drivers/reset/reset-uniphier.c
index 55ae0f1..90e6caf 100644
--- a/drivers/reset/reset-uniphier.c
+++ b/drivers/reset/reset-uniphier.c
@@ -63,6 +63,9 @@ static const struct uniphier_reset_data 
uniphier_pro4_sys_reset_data[] = {
UNIPHIER_RESETX(12, 0x2000, 6), /* GIO (Ether, SATA, USB3) */
UNIPHIER_RESETX(14, 0x2000, 17),/* USB30 */
UNIPHIER_RESETX(15, 0x2004, 17),/* USB31 */
+   UNIPHIER_RESETX(28, 0x2000, 18),/* SATA0 */
+   UNIPHIER_RESETX(29, 0x2004, 18),/* SATA1 */
+   UNIPHIER_RESETX(30, 0x2000, 19),/* SATA-PHY */
UNIPHIER_RESETX(40, 0x2000, 13),/* AIO */
UNIPHIER_RESET_END,
 };
@@ -90,7 +93,7 @@ static const struct uniphier_reset_data 
uniphier_pxs2_sys_reset_data[] = {
UNIPHIER_RESETX(20, 0x2014, 5), /* USB31-PHY0 */
UNIPHIER_RESETX(21, 0x2014, 1), /* USB31-PHY1 */
UNIPHIER_RESETX(28, 0x2014, 12),/* SATA */
-   UNIPHIER_RESET(29, 0x2014, 8),  /* SATA-PHY (active high) */
+   UNIPHIER_RESET(30, 0x2014, 8),  /* SATA-PHY (active high) */
UNIPHIER_RESETX(40, 0x2000, 13),/* AIO */
UNIPHIER_RESET_END,
 };
@@ -137,6 +140,9 @@ static const struct uniphier_reset_data 
uniphier_pxs3_sys_reset_data[] = {
UNIPHIER_RESETX(20, 0x200c, 17),/* USB31-PHY0 */
UNIPHIER_RESETX(21, 0x200c, 19),/* USB31-PHY1 */
UNIPHIER_RESETX(24, 0x200c, 3), /* PCIe */
+   UNIPHIER_RESETX(28, 0x200c, 7), /* SATA0 */
+   UNIPHIER_RESETX(29, 0x200c, 8), /* SATA1 */
+   UNIPHIER_RESETX(30, 0x200c, 21),/* SATA-PHY */
UNIPHIER_RESET_END,
 };
 
-- 
2.7.4



[PATCH 2/2] reset: uniphier: add SATA reset control support and change SATA-PHY ID

2018-03-30 Thread Kunihiko Hayashi
Add reset lines for SATA controller on UniPhier SoCs.
This adds support for Pro4 and PXs3 in addition to PXs2.

And this changes the ID of the reset line for SATA-PHY on PXs2.
Since some SoCs have two controller instances with a common PHY, this moves
the ID of SATA-PHY for consistency.

Signed-off-by: Kunihiko Hayashi 
---
 drivers/reset/reset-uniphier.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/reset/reset-uniphier.c b/drivers/reset/reset-uniphier.c
index 55ae0f1..90e6caf 100644
--- a/drivers/reset/reset-uniphier.c
+++ b/drivers/reset/reset-uniphier.c
@@ -63,6 +63,9 @@ static const struct uniphier_reset_data 
uniphier_pro4_sys_reset_data[] = {
UNIPHIER_RESETX(12, 0x2000, 6), /* GIO (Ether, SATA, USB3) */
UNIPHIER_RESETX(14, 0x2000, 17),/* USB30 */
UNIPHIER_RESETX(15, 0x2004, 17),/* USB31 */
+   UNIPHIER_RESETX(28, 0x2000, 18),/* SATA0 */
+   UNIPHIER_RESETX(29, 0x2004, 18),/* SATA1 */
+   UNIPHIER_RESETX(30, 0x2000, 19),/* SATA-PHY */
UNIPHIER_RESETX(40, 0x2000, 13),/* AIO */
UNIPHIER_RESET_END,
 };
@@ -90,7 +93,7 @@ static const struct uniphier_reset_data 
uniphier_pxs2_sys_reset_data[] = {
UNIPHIER_RESETX(20, 0x2014, 5), /* USB31-PHY0 */
UNIPHIER_RESETX(21, 0x2014, 1), /* USB31-PHY1 */
UNIPHIER_RESETX(28, 0x2014, 12),/* SATA */
-   UNIPHIER_RESET(29, 0x2014, 8),  /* SATA-PHY (active high) */
+   UNIPHIER_RESET(30, 0x2014, 8),  /* SATA-PHY (active high) */
UNIPHIER_RESETX(40, 0x2000, 13),/* AIO */
UNIPHIER_RESET_END,
 };
@@ -137,6 +140,9 @@ static const struct uniphier_reset_data 
uniphier_pxs3_sys_reset_data[] = {
UNIPHIER_RESETX(20, 0x200c, 17),/* USB31-PHY0 */
UNIPHIER_RESETX(21, 0x200c, 19),/* USB31-PHY1 */
UNIPHIER_RESETX(24, 0x200c, 3), /* PCIe */
+   UNIPHIER_RESETX(28, 0x200c, 7), /* SATA0 */
+   UNIPHIER_RESETX(29, 0x200c, 8), /* SATA1 */
+   UNIPHIER_RESETX(30, 0x200c, 21),/* SATA-PHY */
UNIPHIER_RESET_END,
 };
 
-- 
2.7.4



[PATCH 1/2] reset: uniphier: add PCIe reset control support

2018-03-30 Thread Kunihiko Hayashi
Add reset lines for PCIe controller on UniPhier SoCs. This adds support for
Pro5, LD20 and PXs3.

Signed-off-by: Kunihiko Hayashi 
---
 drivers/reset/reset-uniphier.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/reset/reset-uniphier.c b/drivers/reset/reset-uniphier.c
index 360e06b..55ae0f1 100644
--- a/drivers/reset/reset-uniphier.c
+++ b/drivers/reset/reset-uniphier.c
@@ -73,6 +73,7 @@ static const struct uniphier_reset_data 
uniphier_pro5_sys_reset_data[] = {
UNIPHIER_RESETX(12, 0x2000, 6), /* GIO (PCIe, USB3) */
UNIPHIER_RESETX(14, 0x2000, 17),/* USB30 */
UNIPHIER_RESETX(15, 0x2004, 17),/* USB31 */
+   UNIPHIER_RESETX(24, 0x2008, 2), /* PCIe */
UNIPHIER_RESETX(40, 0x2000, 13),/* AIO */
UNIPHIER_RESET_END,
 };
@@ -115,6 +116,7 @@ static const struct uniphier_reset_data 
uniphier_ld20_sys_reset_data[] = {
UNIPHIER_RESETX(17, 0x200c, 13),/* USB30-PHY1 */
UNIPHIER_RESETX(18, 0x200c, 14),/* USB30-PHY2 */
UNIPHIER_RESETX(19, 0x200c, 15),/* USB30-PHY3 */
+   UNIPHIER_RESETX(24, 0x200c, 4), /* PCIe */
UNIPHIER_RESETX(40, 0x2008, 0), /* AIO */
UNIPHIER_RESETX(41, 0x2008, 1), /* EVEA */
UNIPHIER_RESETX(42, 0x2010, 2), /* EXIV */
@@ -134,6 +136,7 @@ static const struct uniphier_reset_data 
uniphier_pxs3_sys_reset_data[] = {
UNIPHIER_RESETX(18, 0x200c, 20),/* USB30-PHY2 */
UNIPHIER_RESETX(20, 0x200c, 17),/* USB31-PHY0 */
UNIPHIER_RESETX(21, 0x200c, 19),/* USB31-PHY1 */
+   UNIPHIER_RESETX(24, 0x200c, 3), /* PCIe */
UNIPHIER_RESET_END,
 };
 
-- 
2.7.4



[PATCH 1/2] reset: uniphier: add PCIe reset control support

2018-03-30 Thread Kunihiko Hayashi
Add reset lines for PCIe controller on UniPhier SoCs. This adds support for
Pro5, LD20 and PXs3.

Signed-off-by: Kunihiko Hayashi 
---
 drivers/reset/reset-uniphier.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/reset/reset-uniphier.c b/drivers/reset/reset-uniphier.c
index 360e06b..55ae0f1 100644
--- a/drivers/reset/reset-uniphier.c
+++ b/drivers/reset/reset-uniphier.c
@@ -73,6 +73,7 @@ static const struct uniphier_reset_data 
uniphier_pro5_sys_reset_data[] = {
UNIPHIER_RESETX(12, 0x2000, 6), /* GIO (PCIe, USB3) */
UNIPHIER_RESETX(14, 0x2000, 17),/* USB30 */
UNIPHIER_RESETX(15, 0x2004, 17),/* USB31 */
+   UNIPHIER_RESETX(24, 0x2008, 2), /* PCIe */
UNIPHIER_RESETX(40, 0x2000, 13),/* AIO */
UNIPHIER_RESET_END,
 };
@@ -115,6 +116,7 @@ static const struct uniphier_reset_data 
uniphier_ld20_sys_reset_data[] = {
UNIPHIER_RESETX(17, 0x200c, 13),/* USB30-PHY1 */
UNIPHIER_RESETX(18, 0x200c, 14),/* USB30-PHY2 */
UNIPHIER_RESETX(19, 0x200c, 15),/* USB30-PHY3 */
+   UNIPHIER_RESETX(24, 0x200c, 4), /* PCIe */
UNIPHIER_RESETX(40, 0x2008, 0), /* AIO */
UNIPHIER_RESETX(41, 0x2008, 1), /* EVEA */
UNIPHIER_RESETX(42, 0x2010, 2), /* EXIV */
@@ -134,6 +136,7 @@ static const struct uniphier_reset_data 
uniphier_pxs3_sys_reset_data[] = {
UNIPHIER_RESETX(18, 0x200c, 20),/* USB30-PHY2 */
UNIPHIER_RESETX(20, 0x200c, 17),/* USB31-PHY0 */
UNIPHIER_RESETX(21, 0x200c, 19),/* USB31-PHY1 */
+   UNIPHIER_RESETX(24, 0x200c, 3), /* PCIe */
UNIPHIER_RESET_END,
 };
 
-- 
2.7.4



[PATCH 1/3] clk: uniphier: add PCIe clock control support

2018-03-30 Thread Kunihiko Hayashi
Add clock control for PCIe controller on UniPhier SoCs. This adds
support for Pro5, LD20 and PXs3.

Signed-off-by: Kunihiko Hayashi 
---
 drivers/clk/uniphier/clk-uniphier-sys.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/clk/uniphier/clk-uniphier-sys.c 
b/drivers/clk/uniphier/clk-uniphier-sys.c
index fa7f2f3..d539c82 100644
--- a/drivers/clk/uniphier/clk-uniphier-sys.c
+++ b/drivers/clk/uniphier/clk-uniphier-sys.c
@@ -141,6 +141,7 @@ const struct uniphier_clk_data uniphier_pro5_sys_clk_data[] 
= {
UNIPHIER_PRO4_SYS_CLK_GIO(12),  /* PCIe, USB3 */
UNIPHIER_PRO4_SYS_CLK_USB3(14, 0),
UNIPHIER_PRO4_SYS_CLK_USB3(15, 1),
+   UNIPHIER_CLK_GATE("pcie", 24, NULL, 0x2108, 2),
UNIPHIER_PRO5_SYS_CLK_AIO(40),
{ /* sentinel */ }
 };
@@ -216,6 +217,7 @@ const struct uniphier_clk_data uniphier_ld20_sys_clk_data[] 
= {
UNIPHIER_CLK_GATE("usb30", 14, NULL, 0x210c, 14),
UNIPHIER_CLK_GATE("usb30-phy0", 16, NULL, 0x210c, 12),
UNIPHIER_CLK_GATE("usb30-phy1", 17, NULL, 0x210c, 13),
+   UNIPHIER_CLK_GATE("pcie", 24, NULL, 0x210c, 4),
UNIPHIER_LD11_SYS_CLK_AIO(40),
UNIPHIER_LD11_SYS_CLK_EVEA(41),
UNIPHIER_LD11_SYS_CLK_EXIV(42),
@@ -254,6 +256,7 @@ const struct uniphier_clk_data uniphier_pxs3_sys_clk_data[] 
= {
UNIPHIER_CLK_GATE("usb30-phy2", 18, NULL, 0x210c, 20),
UNIPHIER_CLK_GATE("usb31-phy0", 20, NULL, 0x210c, 17),
UNIPHIER_CLK_GATE("usb31-phy1", 21, NULL, 0x210c, 19),
+   UNIPHIER_CLK_GATE("pcie", 24, NULL, 0x210c, 3),
/* CPU gears */
UNIPHIER_CLK_DIV4("cpll", 2, 3, 4, 8),
UNIPHIER_CLK_DIV4("spll", 2, 3, 4, 8),
-- 
2.7.4



[PATCH 1/3] clk: uniphier: add PCIe clock control support

2018-03-30 Thread Kunihiko Hayashi
Add clock control for PCIe controller on UniPhier SoCs. This adds
support for Pro5, LD20 and PXs3.

Signed-off-by: Kunihiko Hayashi 
---
 drivers/clk/uniphier/clk-uniphier-sys.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/clk/uniphier/clk-uniphier-sys.c 
b/drivers/clk/uniphier/clk-uniphier-sys.c
index fa7f2f3..d539c82 100644
--- a/drivers/clk/uniphier/clk-uniphier-sys.c
+++ b/drivers/clk/uniphier/clk-uniphier-sys.c
@@ -141,6 +141,7 @@ const struct uniphier_clk_data uniphier_pro5_sys_clk_data[] 
= {
UNIPHIER_PRO4_SYS_CLK_GIO(12),  /* PCIe, USB3 */
UNIPHIER_PRO4_SYS_CLK_USB3(14, 0),
UNIPHIER_PRO4_SYS_CLK_USB3(15, 1),
+   UNIPHIER_CLK_GATE("pcie", 24, NULL, 0x2108, 2),
UNIPHIER_PRO5_SYS_CLK_AIO(40),
{ /* sentinel */ }
 };
@@ -216,6 +217,7 @@ const struct uniphier_clk_data uniphier_ld20_sys_clk_data[] 
= {
UNIPHIER_CLK_GATE("usb30", 14, NULL, 0x210c, 14),
UNIPHIER_CLK_GATE("usb30-phy0", 16, NULL, 0x210c, 12),
UNIPHIER_CLK_GATE("usb30-phy1", 17, NULL, 0x210c, 13),
+   UNIPHIER_CLK_GATE("pcie", 24, NULL, 0x210c, 4),
UNIPHIER_LD11_SYS_CLK_AIO(40),
UNIPHIER_LD11_SYS_CLK_EVEA(41),
UNIPHIER_LD11_SYS_CLK_EXIV(42),
@@ -254,6 +256,7 @@ const struct uniphier_clk_data uniphier_pxs3_sys_clk_data[] 
= {
UNIPHIER_CLK_GATE("usb30-phy2", 18, NULL, 0x210c, 20),
UNIPHIER_CLK_GATE("usb31-phy0", 20, NULL, 0x210c, 17),
UNIPHIER_CLK_GATE("usb31-phy1", 21, NULL, 0x210c, 19),
+   UNIPHIER_CLK_GATE("pcie", 24, NULL, 0x210c, 3),
/* CPU gears */
UNIPHIER_CLK_DIV4("cpll", 2, 3, 4, 8),
UNIPHIER_CLK_DIV4("spll", 2, 3, 4, 8),
-- 
2.7.4



[PATCH 0/2] reset: uniphier: add support for PCIe and SATA

2018-03-30 Thread Kunihiko Hayashi
add reset lines for PCI-express and SATA controllers implemented on
UniPhier SoCs.

Kunihiko Hayashi (2):
  reset: uniphier: add PCIe reset control support
  reset: uniphier: add SATA reset control support and change SATA-PHY ID

 drivers/reset/reset-uniphier.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

-- 
2.7.4



[PATCH 0/2] reset: uniphier: add support for PCIe and SATA

2018-03-30 Thread Kunihiko Hayashi
add reset lines for PCI-express and SATA controllers implemented on
UniPhier SoCs.

Kunihiko Hayashi (2):
  reset: uniphier: add PCIe reset control support
  reset: uniphier: add SATA reset control support and change SATA-PHY ID

 drivers/reset/reset-uniphier.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

-- 
2.7.4



[PATCH 3/3] clk: uniphier: add additional ethernet clock lines for Pro4

2018-03-30 Thread Kunihiko Hayashi
Pro4 SoC has clock lines for Giga-bit feature and ethernet phy,
and these are mandatory to activate the ethernet controller. This adds
support for the clock lines.

Signed-off-by: Kunihiko Hayashi 
---
 drivers/clk/uniphier/clk-uniphier-sys.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/clk/uniphier/clk-uniphier-sys.c 
b/drivers/clk/uniphier/clk-uniphier-sys.c
index 7d66dfb..ebc78ab2 100644
--- a/drivers/clk/uniphier/clk-uniphier-sys.c
+++ b/drivers/clk/uniphier/clk-uniphier-sys.c
@@ -102,13 +102,16 @@ const struct uniphier_clk_data 
uniphier_pro4_sys_clk_data[] = {
UNIPHIER_CLK_FACTOR("upll", -1, "ref", 288, 25),/* 288 MHz */
UNIPHIER_CLK_FACTOR("a2pll", -1, "upll", 256, 125), /* 589.824 MHz 
*/
UNIPHIER_CLK_FACTOR("vpll27a", -1, "ref", 270, 25), /* 270 MHz */
+   UNIPHIER_CLK_FACTOR("gpll", -1, "ref", 10, 1),  /* 250 MHz */
UNIPHIER_CLK_FACTOR("uart", 0, "a2pll", 1, 8),
UNIPHIER_CLK_FACTOR("i2c", 1, "spll", 1, 32),
UNIPHIER_LD4_SYS_CLK_NAND(2),
UNIPHIER_LD4_SYS_CLK_SD,
UNIPHIER_CLK_FACTOR("usb2", -1, "upll", 1, 12),
UNIPHIER_PRO4_SYS_CLK_ETHER(6),
+   UNIPHIER_CLK_GATE("ether-gb", 7, "gpll", 0x2104, 5),
UNIPHIER_LD4_SYS_CLK_STDMAC(8), /* HSC, MIO, RLE */
+   UNIPHIER_CLK_GATE("ether-phy", 10, "ref", 0x2260, 0),
UNIPHIER_PRO4_SYS_CLK_GIO(12),  /* Ether, SATA, USB3 */
UNIPHIER_PRO4_SYS_CLK_USB3(14, 0),
UNIPHIER_PRO4_SYS_CLK_USB3(15, 1),
-- 
2.7.4



[PATCH 2/3] clk: uniphier: add SATA clock control support

2018-03-30 Thread Kunihiko Hayashi
Add clock control for SATA controller on UniPhier SoCs. This adds
support for PXs2, LD20 and PXs3.

Signed-off-by: Kunihiko Hayashi 
---
 drivers/clk/uniphier/clk-uniphier-sys.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/clk/uniphier/clk-uniphier-sys.c 
b/drivers/clk/uniphier/clk-uniphier-sys.c
index d539c82..7d66dfb 100644
--- a/drivers/clk/uniphier/clk-uniphier-sys.c
+++ b/drivers/clk/uniphier/clk-uniphier-sys.c
@@ -112,6 +112,8 @@ const struct uniphier_clk_data uniphier_pro4_sys_clk_data[] 
= {
UNIPHIER_PRO4_SYS_CLK_GIO(12),  /* Ether, SATA, USB3 */
UNIPHIER_PRO4_SYS_CLK_USB3(14, 0),
UNIPHIER_PRO4_SYS_CLK_USB3(15, 1),
+   UNIPHIER_CLK_GATE("sata0", 28, NULL, 0x2104, 18),
+   UNIPHIER_CLK_GATE("sata1", 29, NULL, 0x2104, 19),
UNIPHIER_PRO4_SYS_CLK_AIO(40),
{ /* sentinel */ }
 };
@@ -160,6 +162,7 @@ const struct uniphier_clk_data uniphier_pxs2_sys_clk_data[] 
= {
/* The document mentions 0x2104 bit 18, but not functional */
UNIPHIER_CLK_GATE("usb30-phy", 16, NULL, 0x2104, 19),
UNIPHIER_CLK_GATE("usb31-phy", 20, NULL, 0x2104, 20),
+   UNIPHIER_CLK_GATE("sata0", 28, NULL, 0x2104, 22),
UNIPHIER_PRO5_SYS_CLK_AIO(40),
{ /* sentinel */ }
 };
@@ -257,6 +260,9 @@ const struct uniphier_clk_data uniphier_pxs3_sys_clk_data[] 
= {
UNIPHIER_CLK_GATE("usb31-phy0", 20, NULL, 0x210c, 17),
UNIPHIER_CLK_GATE("usb31-phy1", 21, NULL, 0x210c, 19),
UNIPHIER_CLK_GATE("pcie", 24, NULL, 0x210c, 3),
+   UNIPHIER_CLK_GATE("sata0", 28, NULL, 0x210c, 7),
+   UNIPHIER_CLK_GATE("sata1", 29, NULL, 0x210c, 8),
+   UNIPHIER_CLK_GATE("sata-phy", 30, NULL, 0x210c, 21),
/* CPU gears */
UNIPHIER_CLK_DIV4("cpll", 2, 3, 4, 8),
UNIPHIER_CLK_DIV4("spll", 2, 3, 4, 8),
-- 
2.7.4



<    4   5   6   7   8   9   10   11   12   13   >