Re: [PATCH v5 3/7] phy: Add set_mode callback

[Kishon Vijay Abraham I]

Hi,

On Tuesday 10 May 2016 05:09 AM, David Lechner wrote:
> The initial use for this is for PHYs that have a mode related to USB OTG.
> There are several SoCs (e.g. TI OMAP and DA8xx) that have a mode setting
> in the USB PHY to override OTG VBUS and ID signals.
> 
> Of course, the enum can be expaned in the future to include modes for
> other types of PHYs as well.
> 
> Suggested-by: Kishon Vijay Abraham I 
> Signed-off-by: David Lechner 

This patch is required for both phy driver and the usb driver. I can create a
immutable branch with only this patch and both me and Bin Liu can merge it in
our next branch.

Thanks
Kishon

> ---
>  drivers/phy/phy-core.c  | 15 +++
>  include/linux/phy/phy.h | 17 +
>  2 files changed, 32 insertions(+)
> 
> diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
> index e7e574d..fe0344c 100644
> --- a/drivers/phy/phy-core.c
> +++ b/drivers/phy/phy-core.c
> @@ -342,6 +342,21 @@ int phy_power_off(struct phy *phy)
>  }
>  EXPORT_SYMBOL_GPL(phy_power_off);
>  
> +int phy_set_mode(struct phy *phy, enum phy_mode mode)
> +{
> + int ret;
> +
> + if (!phy || !phy->ops->set_mode)
> + return 0;
> +
> + mutex_lock(>mutex);
> + ret = phy->ops->set_mode(phy, mode);
> + mutex_unlock(>mutex);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(phy_set_mode);
> +
>  /**
>   * _of_phy_get() - lookup and obtain a reference to a phy by phandle
>   * @np: device_node for which to get the phy
> diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
> index 8cf05e3..4248ade 100644
> --- a/include/linux/phy/phy.h
> +++ b/include/linux/phy/phy.h
> @@ -22,12 +22,20 @@
>  
>  struct phy;
>  
> +enum phy_mode {
> + PHY_MODE_INVALID,
> + PHY_MODE_USB_HOST,
> + PHY_MODE_USB_DEVICE,
> + PHY_MODE_USB_OTG,
> +};
> +
>  /**
>   * struct phy_ops - set of function pointers for performing phy operations
>   * @init: operation to be performed for initializing phy
>   * @exit: operation to be performed while exiting
>   * @power_on: powering on the phy
>   * @power_off: powering off the phy
> + * @set_mode: set the mode of the phy
>   * @owner: the module owner containing the ops
>   */
>  struct phy_ops {
> @@ -35,6 +43,7 @@ struct phy_ops {
>   int (*exit)(struct phy *phy);
>   int (*power_on)(struct phy *phy);
>   int (*power_off)(struct phy *phy);
> + int (*set_mode)(struct phy *phy, enum phy_mode mode);
>   struct module *owner;
>  };
>  
> @@ -119,6 +128,7 @@ int phy_init(struct phy *phy);
>  int phy_exit(struct phy *phy);
>  int phy_power_on(struct phy *phy);
>  int phy_power_off(struct phy *phy);
> +int phy_set_mode(struct phy *phy, enum phy_mode mode);
>  static inline int phy_get_bus_width(struct phy *phy)
>  {
>   return phy->attrs.bus_width;
> @@ -224,6 +234,13 @@ static inline int phy_power_off(struct phy *phy)
>   return -ENOSYS;
>  }
>  
> +static inline int phy_set_mode(struct phy *phy, enum phy_mode mode)
> +{
> + if (!phy)
> + return 0;
> + return -ENOSYS;
> +}
> +
>  static inline int phy_get_bus_width(struct phy *phy)
>  {
>   return -ENOSYS;
> 

Re: [PATCH v5 3/7] phy: Add set_mode callback

[Kishon Vijay Abraham I]

Hi,

On Tuesday 10 May 2016 05:09 AM, David Lechner wrote:
> The initial use for this is for PHYs that have a mode related to USB OTG.
> There are several SoCs (e.g. TI OMAP and DA8xx) that have a mode setting
> in the USB PHY to override OTG VBUS and ID signals.
> 
> Of course, the enum can be expaned in the future to include modes for
> other types of PHYs as well.
> 
> Suggested-by: Kishon Vijay Abraham I 
> Signed-off-by: David Lechner 

This patch is required for both phy driver and the usb driver. I can create a
immutable branch with only this patch and both me and Bin Liu can merge it in
our next branch.

Thanks
Kishon

> ---
>  drivers/phy/phy-core.c  | 15 +++
>  include/linux/phy/phy.h | 17 +
>  2 files changed, 32 insertions(+)
> 
> diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
> index e7e574d..fe0344c 100644
> --- a/drivers/phy/phy-core.c
> +++ b/drivers/phy/phy-core.c
> @@ -342,6 +342,21 @@ int phy_power_off(struct phy *phy)
>  }
>  EXPORT_SYMBOL_GPL(phy_power_off);
>  
> +int phy_set_mode(struct phy *phy, enum phy_mode mode)
> +{
> + int ret;
> +
> + if (!phy || !phy->ops->set_mode)
> + return 0;
> +
> + mutex_lock(>mutex);
> + ret = phy->ops->set_mode(phy, mode);
> + mutex_unlock(>mutex);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(phy_set_mode);
> +
>  /**
>   * _of_phy_get() - lookup and obtain a reference to a phy by phandle
>   * @np: device_node for which to get the phy
> diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
> index 8cf05e3..4248ade 100644
> --- a/include/linux/phy/phy.h
> +++ b/include/linux/phy/phy.h
> @@ -22,12 +22,20 @@
>  
>  struct phy;
>  
> +enum phy_mode {
> + PHY_MODE_INVALID,
> + PHY_MODE_USB_HOST,
> + PHY_MODE_USB_DEVICE,
> + PHY_MODE_USB_OTG,
> +};
> +
>  /**
>   * struct phy_ops - set of function pointers for performing phy operations
>   * @init: operation to be performed for initializing phy
>   * @exit: operation to be performed while exiting
>   * @power_on: powering on the phy
>   * @power_off: powering off the phy
> + * @set_mode: set the mode of the phy
>   * @owner: the module owner containing the ops
>   */
>  struct phy_ops {
> @@ -35,6 +43,7 @@ struct phy_ops {
>   int (*exit)(struct phy *phy);
>   int (*power_on)(struct phy *phy);
>   int (*power_off)(struct phy *phy);
> + int (*set_mode)(struct phy *phy, enum phy_mode mode);
>   struct module *owner;
>  };
>  
> @@ -119,6 +128,7 @@ int phy_init(struct phy *phy);
>  int phy_exit(struct phy *phy);
>  int phy_power_on(struct phy *phy);
>  int phy_power_off(struct phy *phy);
> +int phy_set_mode(struct phy *phy, enum phy_mode mode);
>  static inline int phy_get_bus_width(struct phy *phy)
>  {
>   return phy->attrs.bus_width;
> @@ -224,6 +234,13 @@ static inline int phy_power_off(struct phy *phy)
>   return -ENOSYS;
>  }
>  
> +static inline int phy_set_mode(struct phy *phy, enum phy_mode mode)
> +{
> + if (!phy)
> + return 0;
> + return -ENOSYS;
> +}
> +
>  static inline int phy_get_bus_width(struct phy *phy)
>  {
>   return -ENOSYS;
> 

Re: [PATCH v3 5/8] scripts: add Linux .cocciconfig for coccinelle

[Julia Lawall]

On Wed, 22 Jun 2016, Luis R. Rodriguez wrote:

> On Tue, Jun 21, 2016 at 11:12:54PM +0200, Julia Lawall wrote:
> > On Tue, 21 Jun 2016, Nicolas Palix (LIG) wrote:
> > 
> > > Le 21/06/16 à 21:21, Luis R. Rodriguez a écrit :
> > > > Help Coccinelle when used against Linux with a set of sensible defaults
> > > > options for Linux. This hints to coccinelle git can be used for 'git 
> > > > grep'
> > > > queries over coccigrep. A timeout of 200 seconds should suffice for now.
> > > > 
> > > > If you use idutils you can override for 'make coccicheck' by using the
> > > > SPFLAGS option as follows:
> > > > 
> > > > First build the index, for example:
> > > > mkid -s
> > > > 
> > > > Pick the cocci file you wnat to work with:
> > > > export COCCI=scripts/coccinelle/misc/irqf_oneshot.cocci
> > > > 
> > > > Then run coccicheck:
> > > > $ make coccicheck V=1 MODE=report SPFLAGS="--use-idutils ID"
> > > > 
> > > > Coccinelle supports reading .cocciconfig from different directories,
> > > > the later one overriding the previous reads in the following order:
> > > > 
> > > >  o Your current user's home directory is processed first
> > > >  o Your directory from which spatch is called is processed next
> > > >  o The directory provided with the --dir option is processed last, if 
> > > > used
> > > > 
> > > > Signed-off-by: Luis R. Rodriguez 
> > > Acked-by: Nicolas Palix 
> > 
> > Hmm, I can see at least some advantages to encouraging people to do it the 
> > Coccinelle way, with the Coccinelle script rather than mkid directly.  
> > Then, if we need some other features specific to Coccinelle, we can just 
> > add them.
> 
> I can simply document that if users are used to using their own
> target output file, and if they wanted it to be used by coccinelle
> simply symlinking .id-utils.index to it would enable coccinelle
> to pick it up by default.
> 
> If that is done, would the new .cocciconfig not override though?

I don't understand.

julia

Re: [PATCH v3 5/8] scripts: add Linux .cocciconfig for coccinelle

[Julia Lawall]

On Wed, 22 Jun 2016, Luis R. Rodriguez wrote:

> On Tue, Jun 21, 2016 at 11:12:54PM +0200, Julia Lawall wrote:
> > On Tue, 21 Jun 2016, Nicolas Palix (LIG) wrote:
> > 
> > > Le 21/06/16 à 21:21, Luis R. Rodriguez a écrit :
> > > > Help Coccinelle when used against Linux with a set of sensible defaults
> > > > options for Linux. This hints to coccinelle git can be used for 'git 
> > > > grep'
> > > > queries over coccigrep. A timeout of 200 seconds should suffice for now.
> > > > 
> > > > If you use idutils you can override for 'make coccicheck' by using the
> > > > SPFLAGS option as follows:
> > > > 
> > > > First build the index, for example:
> > > > mkid -s
> > > > 
> > > > Pick the cocci file you wnat to work with:
> > > > export COCCI=scripts/coccinelle/misc/irqf_oneshot.cocci
> > > > 
> > > > Then run coccicheck:
> > > > $ make coccicheck V=1 MODE=report SPFLAGS="--use-idutils ID"
> > > > 
> > > > Coccinelle supports reading .cocciconfig from different directories,
> > > > the later one overriding the previous reads in the following order:
> > > > 
> > > >  o Your current user's home directory is processed first
> > > >  o Your directory from which spatch is called is processed next
> > > >  o The directory provided with the --dir option is processed last, if 
> > > > used
> > > > 
> > > > Signed-off-by: Luis R. Rodriguez 
> > > Acked-by: Nicolas Palix 
> > 
> > Hmm, I can see at least some advantages to encouraging people to do it the 
> > Coccinelle way, with the Coccinelle script rather than mkid directly.  
> > Then, if we need some other features specific to Coccinelle, we can just 
> > add them.
> 
> I can simply document that if users are used to using their own
> target output file, and if they wanted it to be used by coccinelle
> simply symlinking .id-utils.index to it would enable coccinelle
> to pick it up by default.
> 
> If that is done, would the new .cocciconfig not override though?

I don't understand.

julia

Re: [PATCH 4/5] mfd: qcom-rpm: Add support for pm8018 RPM Regulator

[Bjorn Andersson]

On Fri 17 Jun 03:22 PDT 2016, Neil Armstrong wrote:

[..]
> diff --git a/drivers/mfd/qcom_rpm.c b/drivers/mfd/qcom_rpm.c
[..]
> +
> +static const struct qcom_rpm_data mdm9615_template = {
> + .version = 3,
> + .resource_table = mdm9615_rpm_resource_table,
> + .n_resources = ARRAY_SIZE(mdm9615_rpm_resource_table),
> +};

Please see:
https://patchwork.kernel.org/patch/9177159/

You should set the new .sel_size to 4 here, please either rebase ontop
of Linus patch or send an update after both are merged.

> +
>  static const struct of_device_id qcom_rpm_of_match[] = {
>   { .compatible = "qcom,rpm-apq8064", .data = _template },
>   { .compatible = "qcom,rpm-msm8660", .data = _template },
>   { .compatible = "qcom,rpm-msm8960", .data = _template },
>   { .compatible = "qcom,rpm-ipq8064", .data = _template },
> + { .compatible = "qcom,rpm-mdm9615", .data = _template },
>   { }
>  };
>  MODULE_DEVICE_TABLE(of, qcom_rpm_of_match);
> diff --git a/include/dt-bindings/mfd/qcom-rpm.h 
> b/include/dt-bindings/mfd/qcom-rpm.h
> index 13a9d4b..db85912 100644
> --- a/include/dt-bindings/mfd/qcom-rpm.h
> +++ b/include/dt-bindings/mfd/qcom-rpm.h
> @@ -148,6 +148,29 @@
>  #define QCOM_RPM_SMB208_S2a  138
>  #define QCOM_RPM_SMB208_S2b  139
>  
> +#define QCOM_RPM_PM8018_SMPS1200

These numbers are a logical identifier and as such you shouldn't skip
140-199.

> +#define QCOM_RPM_PM8018_SMPS2201
> +#define QCOM_RPM_PM8018_SMPS3202
> +#define QCOM_RPM_PM8018_SMPS4203
> +#define QCOM_RPM_PM8018_SMPS5204
> +#define QCOM_RPM_PM8018_LDO1 205
> +#define QCOM_RPM_PM8018_LDO2 206
> +#define QCOM_RPM_PM8018_LDO3 207
> +#define QCOM_RPM_PM8018_LDO4 208
> +#define QCOM_RPM_PM8018_LDO5 209
> +#define QCOM_RPM_PM8018_LDO6 210
> +#define QCOM_RPM_PM8018_LDO7 211
> +#define QCOM_RPM_PM8018_LDO8 212
> +#define QCOM_RPM_PM8018_LDO9 213
> +#define QCOM_RPM_PM8018_LDO10214
> +#define QCOM_RPM_PM8018_LDO11215
> +#define QCOM_RPM_PM8018_LDO12216
> +#define QCOM_RPM_PM8018_LDO13217
> +#define QCOM_RPM_PM8018_LDO14218
> +#define QCOM_RPM_PM8018_LVS1 219
> +#define QCOM_RPM_NCP 220

We already have PM8921_NCP and PM8058_NCP, so better make this
QCOM_RPM_PM8018_NCP for consistency.

> +#define QCOM_RPM_VOLTAGE_CORNER  221
> +

Other then these details
Acked-by: Bjorn Andersson 

Regards,
Bjorn

Re: [PATCH 4/5] mfd: qcom-rpm: Add support for pm8018 RPM Regulator

[Bjorn Andersson]

On Fri 17 Jun 03:22 PDT 2016, Neil Armstrong wrote:

[..]
> diff --git a/drivers/mfd/qcom_rpm.c b/drivers/mfd/qcom_rpm.c
[..]
> +
> +static const struct qcom_rpm_data mdm9615_template = {
> + .version = 3,
> + .resource_table = mdm9615_rpm_resource_table,
> + .n_resources = ARRAY_SIZE(mdm9615_rpm_resource_table),
> +};

Please see:
https://patchwork.kernel.org/patch/9177159/

You should set the new .sel_size to 4 here, please either rebase ontop
of Linus patch or send an update after both are merged.

> +
>  static const struct of_device_id qcom_rpm_of_match[] = {
>   { .compatible = "qcom,rpm-apq8064", .data = _template },
>   { .compatible = "qcom,rpm-msm8660", .data = _template },
>   { .compatible = "qcom,rpm-msm8960", .data = _template },
>   { .compatible = "qcom,rpm-ipq8064", .data = _template },
> + { .compatible = "qcom,rpm-mdm9615", .data = _template },
>   { }
>  };
>  MODULE_DEVICE_TABLE(of, qcom_rpm_of_match);
> diff --git a/include/dt-bindings/mfd/qcom-rpm.h 
> b/include/dt-bindings/mfd/qcom-rpm.h
> index 13a9d4b..db85912 100644
> --- a/include/dt-bindings/mfd/qcom-rpm.h
> +++ b/include/dt-bindings/mfd/qcom-rpm.h
> @@ -148,6 +148,29 @@
>  #define QCOM_RPM_SMB208_S2a  138
>  #define QCOM_RPM_SMB208_S2b  139
>  
> +#define QCOM_RPM_PM8018_SMPS1200

These numbers are a logical identifier and as such you shouldn't skip
140-199.

> +#define QCOM_RPM_PM8018_SMPS2201
> +#define QCOM_RPM_PM8018_SMPS3202
> +#define QCOM_RPM_PM8018_SMPS4203
> +#define QCOM_RPM_PM8018_SMPS5204
> +#define QCOM_RPM_PM8018_LDO1 205
> +#define QCOM_RPM_PM8018_LDO2 206
> +#define QCOM_RPM_PM8018_LDO3 207
> +#define QCOM_RPM_PM8018_LDO4 208
> +#define QCOM_RPM_PM8018_LDO5 209
> +#define QCOM_RPM_PM8018_LDO6 210
> +#define QCOM_RPM_PM8018_LDO7 211
> +#define QCOM_RPM_PM8018_LDO8 212
> +#define QCOM_RPM_PM8018_LDO9 213
> +#define QCOM_RPM_PM8018_LDO10214
> +#define QCOM_RPM_PM8018_LDO11215
> +#define QCOM_RPM_PM8018_LDO12216
> +#define QCOM_RPM_PM8018_LDO13217
> +#define QCOM_RPM_PM8018_LDO14218
> +#define QCOM_RPM_PM8018_LVS1 219
> +#define QCOM_RPM_NCP 220

We already have PM8921_NCP and PM8058_NCP, so better make this
QCOM_RPM_PM8018_NCP for consistency.

> +#define QCOM_RPM_VOLTAGE_CORNER  221
> +

Other then these details
Acked-by: Bjorn Andersson 

Regards,
Bjorn

Re: [PATCH v8 2/3] CMDQ: Mediatek CMDQ driver

[Horng-Shyang Liao]

On Tue, 2016-06-21 at 15:41 +0200, Matthias Brugger wrote:
> 
> On 21/06/16 07:52, Horng-Shyang Liao wrote:
> > On Fri, 2016-06-17 at 17:57 +0200, Matthias Brugger wrote:
> >>
> >> On 17/06/16 10:28, Horng-Shyang Liao wrote:
> >>> Hi Matthias,
> >>>
> >>> On Tue, 2016-06-14 at 20:07 +0800, Horng-Shyang Liao wrote:
>  Hi Matthias,
> 
>  On Tue, 2016-06-14 at 12:17 +0200, Matthias Brugger wrote:
> >
> > On 14/06/16 09:44, Horng-Shyang Liao wrote:
> >> Hi Matthias,
> >>
> >> On Wed, 2016-06-08 at 17:35 +0200, Matthias Brugger wrote:
> >>>
> >>> On 08/06/16 14:25, Horng-Shyang Liao wrote:
>  Hi Matthias,
> 
>  On Wed, 2016-06-08 at 12:45 +0200, Matthias Brugger wrote:
> >
> > On 08/06/16 07:40, Horng-Shyang Liao wrote:
> >> Hi Matthias,
> >>
> >> On Tue, 2016-06-07 at 18:59 +0200, Matthias Brugger wrote:
> >>>
> >>> On 03/06/16 15:11, Matthias Brugger wrote:
> 
> 
> >>> [...]
> >>>
> > +
> > +smp_mb(); /* modify jump before enable 
> > thread */
> > +}
> > +
> > +cmdq_thread_writel(thread, task->pa_base +
> > task->command_size,
> > +   CMDQ_THR_END_ADDR);
> > +cmdq_thread_resume(thread);
> > +}
> > +list_move_tail(>list_entry, 
> > >task_busy_list);
> > +spin_unlock_irqrestore(>exec_lock, flags);
> > +}
> > +
> > +static void cmdq_handle_error_done(struct cmdq *cmdq,
> > +   struct cmdq_thread *thread, u32 
> > irq_flag)
> > +{
> > +struct cmdq_task *task, *tmp, *curr_task = NULL;
> > +u32 curr_pa;
> > +struct cmdq_cb_data cmdq_cb_data;
> > +bool err;
> > +
> > +if (irq_flag & CMDQ_THR_IRQ_ERROR)
> > +err = true;
> > +else if (irq_flag & CMDQ_THR_IRQ_DONE)
> > +err = false;
> > +else
> > +return;
> > +
> > +curr_pa = cmdq_thread_readl(thread, 
> > CMDQ_THR_CURR_ADDR);
> > +
> > +list_for_each_entry_safe(task, tmp, 
> > >task_busy_list,
> > + list_entry) {
> > +if (curr_pa >= task->pa_base &&
> > +curr_pa < (task->pa_base + 
> > task->command_size))
> 
>  What are you checking here? It seems as if you make some 
>  implcit
>  assumptions about pa_base and the order of execution of
>  commands in the
>  thread. Is it save to do so? Does dma_alloc_coherent 
>  give any
>  guarantees
>  about dma_handle?
> >>>
> >>> 1. Check what is the current running task in this GCE 
> >>> thread.
> >>> 2. Yes.
> >>> 3. Yes, CMDQ doesn't use iommu, so physical address is 
> >>> continuous.
> >>>
> >>
> >> Yes, physical addresses might be continous, but AFAIK 
> >> there is no
> >> guarantee that the dma_handle address is steadily growing, 
> >> when
> >> calling
> >> dma_alloc_coherent. And if I understand the code 
> >> correctly, you
> >> use this
> >> assumption to decide if the task picked from 
> >> task_busy_list is
> >> currently
> >> executing. So I think this mecanism is not working.
> >
> > I don't use dma_handle address, and just use physical 
> > addresses.
> > From CPU's point of view, tasks are linked by the 
> > busy list.
> > From GCE's point of view, tasks are linked by the 
> > JUMP command.
> >
> >> In which cases does the HW thread raise an interrupt.
> >> In case of error. When does CMDQ_THR_IRQ_DONE get raised?
> >
> > GCE will raise interrupt if any task is done or error.
> > 

linux-next: Tree for Jun 22

[Stephen Rothwell]

Hi all,

Changes since 20160621:

The drm-intel tree gained a conflict against the drm-intel-fixes tree.

The drm-misc tree gained a conflict against the arm tree.

The akpm-current tree gained conflicts against the arm64 and kspp trees.

Non-merge commits (relative to Linus' tree): 4878
 4742 files changed, 218375 insertions(+), 91120 deletions(-)



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

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

Below is a summary of the state of the merge.

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

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

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

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

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (67016f6cdfd0 Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs)
Merging fixes/master (5edb56491d48 Linux 4.7-rc3)
Merging kbuild-current/rc-fixes (b36fad65d61f kbuild: Initialize exported 
variables)
Merging arc-current/for-curr (5edb56491d48 Linux 4.7-rc3)
Merging arm-current/fixes (56530f5d2ddc ARM: 8579/1: mm: Fix definition of 
pmd_mknotpresent)
Merging m68k-current/for-linus (9a6462763b17 m68k/mvme16x: Include generic 
)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging powerpc-fixes/fixes (8550e2fa34f0 powerpc/mm/hash: Use the correct PPP 
mask when updating HPTE)
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (6b15d6650c53 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging net/master (ab522fd68bc7 Merge branch 'qed-fixes')
Merging ipsec/master (d6af1a31cc72 vti: Add pmtu handling to vti_xmit.)
Merging ipvs/master (50219538ffc0 vmxnet3: segCnt can be 1 for LRO packets)
Merging wireless-drivers/master (034fdd4a17ff Merge ath-current from ath.git)
Merging mac80211/master (3d5fdff46c4b wext: Fix 32 bit iwpriv compatibility 
issue with 64 bit Kernel)
Merging sound-current/for-linus (8198868f0a28 ALSA: hdac_regmap - fix the 
register access for runtime PM)
Merging pci-current/for-linus (ef0dab4aae14 PCI: Fix unaligned accesses in VC 
code)
Merging driver-core.current/driver-core-linus (e80dac114c63 Merge tag 
'usb-4.7-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb)
Merging tty.current/tty-linus (33688abb2802 Linux 4.7-rc4)
Merging usb.current/usb-linus (33688abb2802 Linux 4.7-rc4)
Merging usb-gadget-fixes/fixes (50c763f8c1ba usb: dwc3: Set the ClearPendIN bit 
on Clear Stall EP command)
Merging usb-serial-fixes/usb-linus (33688abb2802 Linux 4.7-rc4)
Merging usb-chipidea-fixes/ci-for-usb-stable (ea1d39a31d3b usb: common: 
otg-fsm: add license to usb-otg-fsm)
Merging staging.current/staging-linus (33688abb2802 Linux 4.7-rc4)
Merging char-misc.current/char-misc-linus (e80dac114c63 Merge tag 'usb-4.7-rc4' 
of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb)
Merging input-current/for-linus (30172936eefb MAINTAINERS: add Pali Rohár as 
reviewer of ALPS PS/2 touchpad driver)
Merging crypto-current/master (19ced623db2f crypto: ux500 - memmove the right 
size)
Merging ide/master (1993b176a822 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide)
Merging rr-fixes/fixes (8244062ef1e5 modules: fix longstanding /proc/kallsyms 
vs module insertion race.)
Merging vfio-fixes/for-linus (ce7585f3c4d7 vfio/pci: Allow VPD short read)
Merging kselftest-fixes/fixes (f80eb4289491 selftests/exec: Makefile is a 
run-time dependency, add it to the install list)
Merging backlight-fixes/for-backlight-fixes (68feaca0b13e backlight: pwm: 
Handle EPROBE_DE

Re: [PATCH v8 2/3] CMDQ: Mediatek CMDQ driver

[Horng-Shyang Liao]

On Tue, 2016-06-21 at 15:41 +0200, Matthias Brugger wrote:
> 
> On 21/06/16 07:52, Horng-Shyang Liao wrote:
> > On Fri, 2016-06-17 at 17:57 +0200, Matthias Brugger wrote:
> >>
> >> On 17/06/16 10:28, Horng-Shyang Liao wrote:
> >>> Hi Matthias,
> >>>
> >>> On Tue, 2016-06-14 at 20:07 +0800, Horng-Shyang Liao wrote:
>  Hi Matthias,
> 
>  On Tue, 2016-06-14 at 12:17 +0200, Matthias Brugger wrote:
> >
> > On 14/06/16 09:44, Horng-Shyang Liao wrote:
> >> Hi Matthias,
> >>
> >> On Wed, 2016-06-08 at 17:35 +0200, Matthias Brugger wrote:
> >>>
> >>> On 08/06/16 14:25, Horng-Shyang Liao wrote:
>  Hi Matthias,
> 
>  On Wed, 2016-06-08 at 12:45 +0200, Matthias Brugger wrote:
> >
> > On 08/06/16 07:40, Horng-Shyang Liao wrote:
> >> Hi Matthias,
> >>
> >> On Tue, 2016-06-07 at 18:59 +0200, Matthias Brugger wrote:
> >>>
> >>> On 03/06/16 15:11, Matthias Brugger wrote:
> 
> 
> >>> [...]
> >>>
> > +
> > +smp_mb(); /* modify jump before enable 
> > thread */
> > +}
> > +
> > +cmdq_thread_writel(thread, task->pa_base +
> > task->command_size,
> > +   CMDQ_THR_END_ADDR);
> > +cmdq_thread_resume(thread);
> > +}
> > +list_move_tail(>list_entry, 
> > >task_busy_list);
> > +spin_unlock_irqrestore(>exec_lock, flags);
> > +}
> > +
> > +static void cmdq_handle_error_done(struct cmdq *cmdq,
> > +   struct cmdq_thread *thread, u32 
> > irq_flag)
> > +{
> > +struct cmdq_task *task, *tmp, *curr_task = NULL;
> > +u32 curr_pa;
> > +struct cmdq_cb_data cmdq_cb_data;
> > +bool err;
> > +
> > +if (irq_flag & CMDQ_THR_IRQ_ERROR)
> > +err = true;
> > +else if (irq_flag & CMDQ_THR_IRQ_DONE)
> > +err = false;
> > +else
> > +return;
> > +
> > +curr_pa = cmdq_thread_readl(thread, 
> > CMDQ_THR_CURR_ADDR);
> > +
> > +list_for_each_entry_safe(task, tmp, 
> > >task_busy_list,
> > + list_entry) {
> > +if (curr_pa >= task->pa_base &&
> > +curr_pa < (task->pa_base + 
> > task->command_size))
> 
>  What are you checking here? It seems as if you make some 
>  implcit
>  assumptions about pa_base and the order of execution of
>  commands in the
>  thread. Is it save to do so? Does dma_alloc_coherent 
>  give any
>  guarantees
>  about dma_handle?
> >>>
> >>> 1. Check what is the current running task in this GCE 
> >>> thread.
> >>> 2. Yes.
> >>> 3. Yes, CMDQ doesn't use iommu, so physical address is 
> >>> continuous.
> >>>
> >>
> >> Yes, physical addresses might be continous, but AFAIK 
> >> there is no
> >> guarantee that the dma_handle address is steadily growing, 
> >> when
> >> calling
> >> dma_alloc_coherent. And if I understand the code 
> >> correctly, you
> >> use this
> >> assumption to decide if the task picked from 
> >> task_busy_list is
> >> currently
> >> executing. So I think this mecanism is not working.
> >
> > I don't use dma_handle address, and just use physical 
> > addresses.
> > From CPU's point of view, tasks are linked by the 
> > busy list.
> > From GCE's point of view, tasks are linked by the 
> > JUMP command.
> >
> >> In which cases does the HW thread raise an interrupt.
> >> In case of error. When does CMDQ_THR_IRQ_DONE get raised?
> >
> > GCE will raise interrupt if any task is done or error.
> > 

linux-next: Tree for Jun 22

[Stephen Rothwell]

Hi all,

Changes since 20160621:

The drm-intel tree gained a conflict against the drm-intel-fixes tree.

The drm-misc tree gained a conflict against the arm tree.

The akpm-current tree gained conflicts against the arm64 and kspp trees.

Non-merge commits (relative to Linus' tree): 4878
 4742 files changed, 218375 insertions(+), 91120 deletions(-)



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

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

Below is a summary of the state of the merge.

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

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

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

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

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (67016f6cdfd0 Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs)
Merging fixes/master (5edb56491d48 Linux 4.7-rc3)
Merging kbuild-current/rc-fixes (b36fad65d61f kbuild: Initialize exported 
variables)
Merging arc-current/for-curr (5edb56491d48 Linux 4.7-rc3)
Merging arm-current/fixes (56530f5d2ddc ARM: 8579/1: mm: Fix definition of 
pmd_mknotpresent)
Merging m68k-current/for-linus (9a6462763b17 m68k/mvme16x: Include generic 
)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging powerpc-fixes/fixes (8550e2fa34f0 powerpc/mm/hash: Use the correct PPP 
mask when updating HPTE)
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (6b15d6650c53 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging net/master (ab522fd68bc7 Merge branch 'qed-fixes')
Merging ipsec/master (d6af1a31cc72 vti: Add pmtu handling to vti_xmit.)
Merging ipvs/master (50219538ffc0 vmxnet3: segCnt can be 1 for LRO packets)
Merging wireless-drivers/master (034fdd4a17ff Merge ath-current from ath.git)
Merging mac80211/master (3d5fdff46c4b wext: Fix 32 bit iwpriv compatibility 
issue with 64 bit Kernel)
Merging sound-current/for-linus (8198868f0a28 ALSA: hdac_regmap - fix the 
register access for runtime PM)
Merging pci-current/for-linus (ef0dab4aae14 PCI: Fix unaligned accesses in VC 
code)
Merging driver-core.current/driver-core-linus (e80dac114c63 Merge tag 
'usb-4.7-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb)
Merging tty.current/tty-linus (33688abb2802 Linux 4.7-rc4)
Merging usb.current/usb-linus (33688abb2802 Linux 4.7-rc4)
Merging usb-gadget-fixes/fixes (50c763f8c1ba usb: dwc3: Set the ClearPendIN bit 
on Clear Stall EP command)
Merging usb-serial-fixes/usb-linus (33688abb2802 Linux 4.7-rc4)
Merging usb-chipidea-fixes/ci-for-usb-stable (ea1d39a31d3b usb: common: 
otg-fsm: add license to usb-otg-fsm)
Merging staging.current/staging-linus (33688abb2802 Linux 4.7-rc4)
Merging char-misc.current/char-misc-linus (e80dac114c63 Merge tag 'usb-4.7-rc4' 
of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb)
Merging input-current/for-linus (30172936eefb MAINTAINERS: add Pali Rohár as 
reviewer of ALPS PS/2 touchpad driver)
Merging crypto-current/master (19ced623db2f crypto: ux500 - memmove the right 
size)
Merging ide/master (1993b176a822 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide)
Merging rr-fixes/fixes (8244062ef1e5 modules: fix longstanding /proc/kallsyms 
vs module insertion race.)
Merging vfio-fixes/for-linus (ce7585f3c4d7 vfio/pci: Allow VPD short read)
Merging kselftest-fixes/fixes (f80eb4289491 selftests/exec: Makefile is a 
run-time dependency, add it to the install list)
Merging backlight-fixes/for-backlight-fixes (68feaca0b13e backlight: pwm: 
Handle EPROBE_DE

Re: [PATCH kernfs/for-4.7-fixes] kernfs: don't depend on d_find_any_alias() when generating notifications

[Greg Kroah-Hartman]

On Tue, Jun 21, 2016 at 11:24:47AM -0400, Tejun Heo wrote:
> On Fri, Jun 17, 2016 at 05:51:17PM -0400, Tejun Heo wrote:
> > kernfs_notify_workfn() sends out file modified events for the
> > scheduled kernfs_nodes.  Because the modifications aren't from
> > userland, it doesn't have the matching file struct at hand and can't
> > use fsnotify_modify().  Instead, it looked up the inode and then used
> > d_find_any_alias() to find the dentry and used fsnotify_parent() and
> > fsnotify() directly to generate notifications.
> > 
> > The assumption was that the relevant dentries would have been pinned
> > if there are listeners, which isn't true as inotify doesn't pin
> > dentries at all and watching the parent doesn't pin the child dentries
> > even for dnotify.  This led to, for example, inotify watchers not
> > getting notifications if the system is under memory pressure and the
> > matching dentries got reclaimed.  It can also be triggered through
> > /proc/sys/vm/drop_caches or a remount attempt which involves shrinking
> > dcache.
> > 
> > fsnotify_parent() only uses the dentry to access the parent inode,
> > which kernfs can do easily.  Update kernfs_notify_workfn() so that it
> > uses fsnotify() directly for both the parent and target inodes without
> > going through d_find_any_alias().  While at it, supply the target file
> > name to fsnotify() from kernfs_node->name.
> > 
> > Signed-off-by: Tejun Heo 
> > Reported-by: Evgeny Vereshchagin 
> > Fixes: d911d9874801 ("kernfs: make kernfs_notify() trigger inotify events 
> > too")
> > Cc: John McCutchan 
> > Cc: Robert Love 
> > Cc: Eric Paris 
> > Cc: sta...@vger.kernel.org # v3.16+
> > ---
> > Hello,
> > 
> > I'm not sure this is the best way to deal with this but it at least
> > works fine.  If there's a better, please let me know.  If this
> > approach is okay, in the future, maybe we want to implement a helper
> > on fsnotify side to handle notification generation from back-end side?
> 
> Greg, can you please pick this one up?

Will do, thanks.

greg k-h

Re: [PATCH kernfs/for-4.7-fixes] kernfs: don't depend on d_find_any_alias() when generating notifications

[Greg Kroah-Hartman]

On Tue, Jun 21, 2016 at 11:24:47AM -0400, Tejun Heo wrote:
> On Fri, Jun 17, 2016 at 05:51:17PM -0400, Tejun Heo wrote:
> > kernfs_notify_workfn() sends out file modified events for the
> > scheduled kernfs_nodes.  Because the modifications aren't from
> > userland, it doesn't have the matching file struct at hand and can't
> > use fsnotify_modify().  Instead, it looked up the inode and then used
> > d_find_any_alias() to find the dentry and used fsnotify_parent() and
> > fsnotify() directly to generate notifications.
> > 
> > The assumption was that the relevant dentries would have been pinned
> > if there are listeners, which isn't true as inotify doesn't pin
> > dentries at all and watching the parent doesn't pin the child dentries
> > even for dnotify.  This led to, for example, inotify watchers not
> > getting notifications if the system is under memory pressure and the
> > matching dentries got reclaimed.  It can also be triggered through
> > /proc/sys/vm/drop_caches or a remount attempt which involves shrinking
> > dcache.
> > 
> > fsnotify_parent() only uses the dentry to access the parent inode,
> > which kernfs can do easily.  Update kernfs_notify_workfn() so that it
> > uses fsnotify() directly for both the parent and target inodes without
> > going through d_find_any_alias().  While at it, supply the target file
> > name to fsnotify() from kernfs_node->name.
> > 
> > Signed-off-by: Tejun Heo 
> > Reported-by: Evgeny Vereshchagin 
> > Fixes: d911d9874801 ("kernfs: make kernfs_notify() trigger inotify events 
> > too")
> > Cc: John McCutchan 
> > Cc: Robert Love 
> > Cc: Eric Paris 
> > Cc: sta...@vger.kernel.org # v3.16+
> > ---
> > Hello,
> > 
> > I'm not sure this is the best way to deal with this but it at least
> > works fine.  If there's a better, please let me know.  If this
> > approach is okay, in the future, maybe we want to implement a helper
> > on fsnotify side to handle notification generation from back-end side?
> 
> Greg, can you please pick this one up?

Will do, thanks.

greg k-h

Re: [PATCH v4 5/5] ARM: dts: mt2701: add iommu/smi dtsi node for mt2701

[Eddie Huang]

On Tue, 2016-06-21 at 17:57 +0800, Joerg Roedel wrote:
> On Wed, Jun 08, 2016 at 05:51:01PM +0800, honghui.zh...@mediatek.com wrote:
> > From: Honghui Zhang 
> > 
> > Add the dtsi node of iommu and smi for mt2701.
> > 
> > Signed-off-by: Honghui Zhang 
> > ---
> >  arch/arm/boot/dts/mt2701.dtsi | 51 
> > +++
> >  1 file changed, 51 insertions(+)
> 
> Okay, I pushed my arm/mediatek branch to my tree at
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
> 
> Please base the patch on that branch and re-send.
> 

I think it is better let Mediatek SoC maintainer Matthias to accept dtsi
patch like other drivers. This can avoid dtsi conflict. As I
remember,last time MT8173 IOMMU dtsi patch accepted in iommu tree and
mt8173.dtsi had conflict with arm soc tree at the merge window. Honghui
should resend this patch to Matthias, and elaborate your dependency with
clock and power domain dtsi, then Matthias know the merge sequence. 

Eddie
Thanks

Re: [PATCH v4 5/5] ARM: dts: mt2701: add iommu/smi dtsi node for mt2701

[Eddie Huang]

On Tue, 2016-06-21 at 17:57 +0800, Joerg Roedel wrote:
> On Wed, Jun 08, 2016 at 05:51:01PM +0800, honghui.zh...@mediatek.com wrote:
> > From: Honghui Zhang 
> > 
> > Add the dtsi node of iommu and smi for mt2701.
> > 
> > Signed-off-by: Honghui Zhang 
> > ---
> >  arch/arm/boot/dts/mt2701.dtsi | 51 
> > +++
> >  1 file changed, 51 insertions(+)
> 
> Okay, I pushed my arm/mediatek branch to my tree at
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
> 
> Please base the patch on that branch and re-send.
> 

I think it is better let Mediatek SoC maintainer Matthias to accept dtsi
patch like other drivers. This can avoid dtsi conflict. As I
remember,last time MT8173 IOMMU dtsi patch accepted in iommu tree and
mt8173.dtsi had conflict with arm soc tree at the merge window. Honghui
should resend this patch to Matthias, and elaborate your dependency with
clock and power domain dtsi, then Matthias know the merge sequence. 

Eddie
Thanks

[PATCH] ocfs2: disable BUG assertions in reading blocks

[Gang He]

According to some high-load testing, these two BUG assertions
were encountered, this led system panic. Actually, there were
some discussions about removing these two BUG() assertions, it
would not bring any side effect.
Then, I did the the following changes,
1) use the existing macro CATCH_BH_JBD_RACES to wrap BUG() in
the ocfs2_read_blocks_sync function like before.
2) disable the macro CATCH_BH_JBD_RACES in Makefile by default.

Signed-off-by: Gang He 
---
 fs/ocfs2/Makefile | 2 --
 fs/ocfs2/buffer_head_io.c | 5 +
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/fs/ocfs2/Makefile b/fs/ocfs2/Makefile
index e27e652..4342c7e 100644
--- a/fs/ocfs2/Makefile
+++ b/fs/ocfs2/Makefile
@@ -1,7 +1,5 @@
 ccflags-y := -Ifs/ocfs2
 
-ccflags-y += -DCATCH_BH_JBD_RACES
-
 obj-$(CONFIG_OCFS2_FS) +=  \
ocfs2.o \
ocfs2_stackglue.o
diff --git a/fs/ocfs2/buffer_head_io.c b/fs/ocfs2/buffer_head_io.c
index fe50ded..498641e 100644
--- a/fs/ocfs2/buffer_head_io.c
+++ b/fs/ocfs2/buffer_head_io.c
@@ -139,11 +139,16 @@ int ocfs2_read_blocks_sync(struct ocfs2_super *osb, u64 
block,
 
lock_buffer(bh);
if (buffer_jbd(bh)) {
+#ifdef CATCH_BH_JBD_RACES
mlog(ML_ERROR,
 "block %llu had the JBD bit set "
 "while I was in lock_buffer!",
 (unsigned long long)bh->b_blocknr);
BUG();
+#else
+   unlock_buffer(bh);
+   continue;
+#endif
}
 
clear_buffer_uptodate(bh);
-- 
1.8.5.6

[PATCH] ocfs2: disable BUG assertions in reading blocks

[Gang He]

According to some high-load testing, these two BUG assertions
were encountered, this led system panic. Actually, there were
some discussions about removing these two BUG() assertions, it
would not bring any side effect.
Then, I did the the following changes,
1) use the existing macro CATCH_BH_JBD_RACES to wrap BUG() in
the ocfs2_read_blocks_sync function like before.
2) disable the macro CATCH_BH_JBD_RACES in Makefile by default.

Signed-off-by: Gang He 
---
 fs/ocfs2/Makefile | 2 --
 fs/ocfs2/buffer_head_io.c | 5 +
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/fs/ocfs2/Makefile b/fs/ocfs2/Makefile
index e27e652..4342c7e 100644
--- a/fs/ocfs2/Makefile
+++ b/fs/ocfs2/Makefile
@@ -1,7 +1,5 @@
 ccflags-y := -Ifs/ocfs2
 
-ccflags-y += -DCATCH_BH_JBD_RACES
-
 obj-$(CONFIG_OCFS2_FS) +=  \
ocfs2.o \
ocfs2_stackglue.o
diff --git a/fs/ocfs2/buffer_head_io.c b/fs/ocfs2/buffer_head_io.c
index fe50ded..498641e 100644
--- a/fs/ocfs2/buffer_head_io.c
+++ b/fs/ocfs2/buffer_head_io.c
@@ -139,11 +139,16 @@ int ocfs2_read_blocks_sync(struct ocfs2_super *osb, u64 
block,
 
lock_buffer(bh);
if (buffer_jbd(bh)) {
+#ifdef CATCH_BH_JBD_RACES
mlog(ML_ERROR,
 "block %llu had the JBD bit set "
 "while I was in lock_buffer!",
 (unsigned long long)bh->b_blocknr);
BUG();
+#else
+   unlock_buffer(bh);
+   continue;
+#endif
}
 
clear_buffer_uptodate(bh);
-- 
1.8.5.6

Re: [PATCH 2/5] input: pmic8xxx-pwrkey: Add support for pm8018 pwrkey

[Dmitry Torokhov]

On Tue, Jun 21, 2016 at 10:25 PM, Bjorn Andersson
 wrote:
> On Fri 17 Jun 03:22 PDT 2016, Neil Armstrong wrote:
>
>> In order to support pwrkey for Qualcomm MDM9615 SoC, add support
>> for the pm8018 pwrkey in pmic8xxx-pwrkey.
>>
>> Signed-off-by: Neil Armstrong 
>
> Reviewed-by: Bjorn Andersson 

But why? What does this new compat string gives us if the behavior is
exactly the same as 8921?

Thanks.

-- 
Dmitry

Re: [PATCH 2/5] input: pmic8xxx-pwrkey: Add support for pm8018 pwrkey

[Dmitry Torokhov]

On Tue, Jun 21, 2016 at 10:25 PM, Bjorn Andersson
 wrote:
> On Fri 17 Jun 03:22 PDT 2016, Neil Armstrong wrote:
>
>> In order to support pwrkey for Qualcomm MDM9615 SoC, add support
>> for the pm8018 pwrkey in pmic8xxx-pwrkey.
>>
>> Signed-off-by: Neil Armstrong 
>
> Reviewed-by: Bjorn Andersson 

But why? What does this new compat string gives us if the behavior is
exactly the same as 8921?

Thanks.

-- 
Dmitry

[PATCH] hfs: Change structure initialisation to C99 style

[Amitoj Kaur Chawla]

To allow for structure randomisation, replace the in order
struct initialisation style with explicit field style.
Also, remove an unnecessary initialisation since NULL values do not
need to be explicitly initialised.

The Coccinelle semantic patch used to make this change is as follows:

@decl@
identifier i1,fld;
type T;
field list[n] fs;
@@

struct i1 {
 fs
 T fld;
 ...};

@@
identifier decl.i1,i2,decl.fld;
expression e;
position bad.p, bad.fix;
@@

struct i1 i2@p = { ...,
+ .fld = e
- e@fix
 ,...};

Signed-off-by: Amitoj Kaur Chawla 
---
 fs/hfs/inode.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/hfs/inode.c b/fs/hfs/inode.c
index cb1e5fa..29fc0ea 100644
--- a/fs/hfs/inode.c
+++ b/fs/hfs/inode.c
@@ -380,7 +380,7 @@ static int hfs_read_inode(struct inode *inode, void *data)
  */
 struct inode *hfs_iget(struct super_block *sb, struct hfs_cat_key *key, 
hfs_cat_rec *rec)
 {
-   struct hfs_iget_data data = { key, rec };
+   struct hfs_iget_data data = { .key = key, .rec = rec };
struct inode *inode;
u32 cnid;
 
@@ -527,7 +527,7 @@ static struct dentry *hfs_file_lookup(struct inode *dir, 
struct dentry *dentry,
fd.search_key->cat = HFS_I(dir)->cat_key;
res = hfs_brec_read(, , sizeof(rec));
if (!res) {
-   struct hfs_iget_data idata = { NULL,  };
+   struct hfs_iget_data idata = { .rec =  };
hfs_read_inode(inode, );
}
hfs_find_exit();
-- 
1.9.1

[PATCH] hfs: Change structure initialisation to C99 style

[Amitoj Kaur Chawla]

To allow for structure randomisation, replace the in order
struct initialisation style with explicit field style.
Also, remove an unnecessary initialisation since NULL values do not
need to be explicitly initialised.

The Coccinelle semantic patch used to make this change is as follows:

@decl@
identifier i1,fld;
type T;
field list[n] fs;
@@

struct i1 {
 fs
 T fld;
 ...};

@@
identifier decl.i1,i2,decl.fld;
expression e;
position bad.p, bad.fix;
@@

struct i1 i2@p = { ...,
+ .fld = e
- e@fix
 ,...};

Signed-off-by: Amitoj Kaur Chawla 
---
 fs/hfs/inode.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/hfs/inode.c b/fs/hfs/inode.c
index cb1e5fa..29fc0ea 100644
--- a/fs/hfs/inode.c
+++ b/fs/hfs/inode.c
@@ -380,7 +380,7 @@ static int hfs_read_inode(struct inode *inode, void *data)
  */
 struct inode *hfs_iget(struct super_block *sb, struct hfs_cat_key *key, 
hfs_cat_rec *rec)
 {
-   struct hfs_iget_data data = { key, rec };
+   struct hfs_iget_data data = { .key = key, .rec = rec };
struct inode *inode;
u32 cnid;
 
@@ -527,7 +527,7 @@ static struct dentry *hfs_file_lookup(struct inode *dir, 
struct dentry *dentry,
fd.search_key->cat = HFS_I(dir)->cat_key;
res = hfs_brec_read(, , sizeof(rec));
if (!res) {
-   struct hfs_iget_data idata = { NULL,  };
+   struct hfs_iget_data idata = { .rec =  };
hfs_read_inode(inode, );
}
hfs_find_exit();
-- 
1.9.1

Re: [PATCH] ppc: Fix BPF JIT for ABIv2

[Michael Ellerman]

On Tue, 2016-06-21 at 14:28 +0530, Naveen N. Rao wrote:
> On 2016/06/20 03:56PM, Thadeu Lima de Souza Cascardo wrote:
> > On Sun, Jun 19, 2016 at 11:19:14PM +0530, Naveen N. Rao wrote:
> > > On 2016/06/17 10:00AM, Thadeu Lima de Souza Cascardo wrote:
> > > > 
> > > > Hi, Michael and Naveen.
> > > > 
> > > > I noticed independently that there is a problem with BPF JIT and ABIv2, 
> > > > and
> > > > worked out the patch below before I noticed Naveen's patchset and the 
> > > > latest
> > > > changes in ppc tree for a better way to check for ABI versions.
> > > > 
> > > > However, since the issue described below affect mainline and stable 
> > > > kernels,
> > > > would you consider applying it before merging your two patchsets, so 
> > > > that we can
> > > > more easily backport the fix?
> > > 
> > > Hi Cascardo,
> > > Given that this has been broken on ABIv2 since forever, I didn't bother 
> > > fixing it. But, I can see why this would be a good thing to have for 
> > > -stable and existing distros. However, while your patch below may fix 
> > > the crash you're seeing on ppc64le, it is not sufficient -- you'll need 
> > > changes in bpf_jit_asm.S as well.
> > 
> > Hi, Naveen.
> > 
> > Any tips on how to exercise possible issues there? Or what changes you think
> > would be sufficient?
> 
> The calling convention is different with ABIv2 and so we'll need changes 
> in bpf_slow_path_common() and sk_negative_common().
> 
> However, rather than enabling classic JIT for ppc64le, are we better off 
> just disabling it?
> 
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -128,7 +128,7 @@ config PPC
> select IRQ_FORCED_THREADING
> select HAVE_RCU_TABLE_FREE if SMP
> select HAVE_SYSCALL_TRACEPOINTS
> -   select HAVE_CBPF_JIT
> +   select HAVE_CBPF_JIT if CPU_BIG_ENDIAN
> select HAVE_ARCH_JUMP_LABEL
> select ARCH_HAVE_NMI_SAFE_CMPXCHG
> select ARCH_HAS_GCOV_PROFILE_ALL
> 
> 
> Michael,
> Let me know your thoughts on whether you intend to take this patch or 
> Cascardo's patch for -stable before the eBPF patches. I can redo my 
> patches accordingly.

Can one of you send me a proper version of this patch, with change log and
sign-off etc.

cheers

Re: [PATCH] ppc: Fix BPF JIT for ABIv2

[Michael Ellerman]

On Tue, 2016-06-21 at 14:28 +0530, Naveen N. Rao wrote:
> On 2016/06/20 03:56PM, Thadeu Lima de Souza Cascardo wrote:
> > On Sun, Jun 19, 2016 at 11:19:14PM +0530, Naveen N. Rao wrote:
> > > On 2016/06/17 10:00AM, Thadeu Lima de Souza Cascardo wrote:
> > > > 
> > > > Hi, Michael and Naveen.
> > > > 
> > > > I noticed independently that there is a problem with BPF JIT and ABIv2, 
> > > > and
> > > > worked out the patch below before I noticed Naveen's patchset and the 
> > > > latest
> > > > changes in ppc tree for a better way to check for ABI versions.
> > > > 
> > > > However, since the issue described below affect mainline and stable 
> > > > kernels,
> > > > would you consider applying it before merging your two patchsets, so 
> > > > that we can
> > > > more easily backport the fix?
> > > 
> > > Hi Cascardo,
> > > Given that this has been broken on ABIv2 since forever, I didn't bother 
> > > fixing it. But, I can see why this would be a good thing to have for 
> > > -stable and existing distros. However, while your patch below may fix 
> > > the crash you're seeing on ppc64le, it is not sufficient -- you'll need 
> > > changes in bpf_jit_asm.S as well.
> > 
> > Hi, Naveen.
> > 
> > Any tips on how to exercise possible issues there? Or what changes you think
> > would be sufficient?
> 
> The calling convention is different with ABIv2 and so we'll need changes 
> in bpf_slow_path_common() and sk_negative_common().
> 
> However, rather than enabling classic JIT for ppc64le, are we better off 
> just disabling it?
> 
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -128,7 +128,7 @@ config PPC
> select IRQ_FORCED_THREADING
> select HAVE_RCU_TABLE_FREE if SMP
> select HAVE_SYSCALL_TRACEPOINTS
> -   select HAVE_CBPF_JIT
> +   select HAVE_CBPF_JIT if CPU_BIG_ENDIAN
> select HAVE_ARCH_JUMP_LABEL
> select ARCH_HAVE_NMI_SAFE_CMPXCHG
> select ARCH_HAS_GCOV_PROFILE_ALL
> 
> 
> Michael,
> Let me know your thoughts on whether you intend to take this patch or 
> Cascardo's patch for -stable before the eBPF patches. I can redo my 
> patches accordingly.

Can one of you send me a proper version of this patch, with change log and
sign-off etc.

cheers

Re: [PATCH] ARM: AM33xx: PRM: Remove wrongly defined RSTST offset for PER Domain

[Keerthy]

On Wednesday 22 June 2016 03:55 AM, Suman Anna wrote:

Hi Keerthy,

On 06/21/2016 05:08 AM, Keerthy wrote:

As per the TRM: http://www.ti.com/lit/ug/spruh73m/spruh73m.pdf
offset 0x4 is reserved for PRM_PER. Hence removing the wrongly
defined address offset.


Thanks for the patch.  These macros are not used anywhere, so it should
be safe to remove these. I have tested this patch with an off-tree PRUSS
driver releasing the reset, it works as expected without throwing any
issues.

That said, the current omap_hwmod code assumes default rstst_offs and
st_shift and tries to still write some value into the RSTCTRL register
in am33xx_prm_deassert_hardreset(), but it didn't have any side-affects
though on AM33xx. This is what affected the AM437x due to incorrect
RSTST offset value. That behavior is independent of this patch though.

Tested-by: Suman Anna 


Thanks for testing!



regards
Suman


Signed-off-by: Keerthy 
---
  arch/arm/mach-omap2/prm33xx.h | 2 --
  1 file changed, 2 deletions(-)

diff --git a/arch/arm/mach-omap2/prm33xx.h b/arch/arm/mach-omap2/prm33xx.h
index 2bc4ec5..66302c6 100644
--- a/arch/arm/mach-omap2/prm33xx.h
+++ b/arch/arm/mach-omap2/prm33xx.h
@@ -52,8 +52,6 @@
  /* PRM.PER_PRM register offsets */
  #define AM33XX_RM_PER_RSTCTRL_OFFSET  0x
  #define AM33XX_RM_PER_RSTCTRL 
AM33XX_PRM_REGADDR(AM33XX_PRM_PER_MOD, 0x)
-#define AM33XX_RM_PER_RSTST_OFFSET 0x0004
-#define AM33XX_RM_PER_RSTST
AM33XX_PRM_REGADDR(AM33XX_PRM_PER_MOD, 0x0004)
  #define AM33XX_PM_PER_PWRSTST_OFFSET  0x0008
  #define AM33XX_PM_PER_PWRSTST 
AM33XX_PRM_REGADDR(AM33XX_PRM_PER_MOD, 0x0008)
  #define AM33XX_PM_PER_PWRSTCTRL_OFFSET0x000c

Re: [PATCH] ARM: AM33xx: PRM: Remove wrongly defined RSTST offset for PER Domain

[Keerthy]

On Wednesday 22 June 2016 03:55 AM, Suman Anna wrote:

Hi Keerthy,

On 06/21/2016 05:08 AM, Keerthy wrote:

As per the TRM: http://www.ti.com/lit/ug/spruh73m/spruh73m.pdf
offset 0x4 is reserved for PRM_PER. Hence removing the wrongly
defined address offset.


Thanks for the patch.  These macros are not used anywhere, so it should
be safe to remove these. I have tested this patch with an off-tree PRUSS
driver releasing the reset, it works as expected without throwing any
issues.

That said, the current omap_hwmod code assumes default rstst_offs and
st_shift and tries to still write some value into the RSTCTRL register
in am33xx_prm_deassert_hardreset(), but it didn't have any side-affects
though on AM33xx. This is what affected the AM437x due to incorrect
RSTST offset value. That behavior is independent of this patch though.

Tested-by: Suman Anna 


Thanks for testing!



regards
Suman


Signed-off-by: Keerthy 
---
  arch/arm/mach-omap2/prm33xx.h | 2 --
  1 file changed, 2 deletions(-)

diff --git a/arch/arm/mach-omap2/prm33xx.h b/arch/arm/mach-omap2/prm33xx.h
index 2bc4ec5..66302c6 100644
--- a/arch/arm/mach-omap2/prm33xx.h
+++ b/arch/arm/mach-omap2/prm33xx.h
@@ -52,8 +52,6 @@
  /* PRM.PER_PRM register offsets */
  #define AM33XX_RM_PER_RSTCTRL_OFFSET  0x
  #define AM33XX_RM_PER_RSTCTRL 
AM33XX_PRM_REGADDR(AM33XX_PRM_PER_MOD, 0x)
-#define AM33XX_RM_PER_RSTST_OFFSET 0x0004
-#define AM33XX_RM_PER_RSTST
AM33XX_PRM_REGADDR(AM33XX_PRM_PER_MOD, 0x0004)
  #define AM33XX_PM_PER_PWRSTST_OFFSET  0x0008
  #define AM33XX_PM_PER_PWRSTST 
AM33XX_PRM_REGADDR(AM33XX_PRM_PER_MOD, 0x0008)
  #define AM33XX_PM_PER_PWRSTCTRL_OFFSET0x000c

linux-next: build warnings after merge of the kspp tree

[Stephen Rothwell]

Hi Kees,

After merging the kspp tree, today's linux-next build (i386 defconfig)
produced these warning:

x86_64-linux-gcc: warning: '-mcpu=' is deprecated; use '-mtune=' or '-march=' 
instead

(over 2000 of these)

Introduced (maybe) by commit

  e2135c84d5d2 ("kbuild: no gcc-plugins during cc-option tests")

-- 
Cheers,
Stephen Rothwell

linux-next: build warnings after merge of the kspp tree

[Stephen Rothwell]

Hi Kees,

After merging the kspp tree, today's linux-next build (i386 defconfig)
produced these warning:

x86_64-linux-gcc: warning: '-mcpu=' is deprecated; use '-mtune=' or '-march=' 
instead

(over 2000 of these)

Introduced (maybe) by commit

  e2135c84d5d2 ("kbuild: no gcc-plugins during cc-option tests")

-- 
Cheers,
Stephen Rothwell

Re: [PATCH 2/5] input: pmic8xxx-pwrkey: Add support for pm8018 pwrkey

[Bjorn Andersson]

On Fri 17 Jun 03:22 PDT 2016, Neil Armstrong wrote:

> In order to support pwrkey for Qualcomm MDM9615 SoC, add support
> for the pm8018 pwrkey in pmic8xxx-pwrkey.
> 
> Signed-off-by: Neil Armstrong 

Reviewed-by: Bjorn Andersson 

Regards,
Bjorn

linux-next: manual merge of the akpm-current tree with the kspp tree

[Stephen Rothwell]

Hi Andrew,

Today's linux-next merge of the akpm-current tree got a conflict in:

  mm/page_alloc.c

between commit:

  0df42965deb7 ("latent_entropy: Add the extra_latent_entropy kernel parameter")

from the kspp tree and commit:

  6f4f5445297d ("mm: charge/uncharge kmemcg from generic page allocator paths")

from the akpm-current tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc mm/page_alloc.c
index 02c7a0e6e66a,180f5afc5a1f..
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@@ -63,7 -63,7 +63,8 @@@
  #include 
  #include 
  #include 
 +#include 
+ #include 
  
  #include 
  #include 

Re: [PATCH v3 3/8] coccicheck: enable parmap support

[Julia Lawall]

On Wed, 22 Jun 2016, Luis R. Rodriguez wrote:

> On Tue, Jun 21, 2016 at 11:44:09PM +0200, Julia Lawall wrote:
> > 
> > 
> > On Tue, 21 Jun 2016, Luis R. Rodriguez wrote:
> > 
> > > On Tue, Jun 21, 2016 at 11:32:11PM +0200, Julia Lawall wrote:
> > > > 
> > > > 
> > > > On Tue, 21 Jun 2016, Luis R. Rodriguez wrote:
> > > > 
> > > > > On Tue, Jun 21, 2016 at 11:00:53PM +0200, Nicolas Palix (LIG) wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > Le 21/06/16 à 22:43, Julia Lawall a écrit :
> > > > > > >
> > > > > > >
> > > > > > >On Tue, 21 Jun 2016, Luis R. Rodriguez wrote:
> > > > > > >
> > > > > > >>On Tue, Jun 21, 2016 at 10:17:38PM +0200, Julia Lawall wrote:
> > > > > > >>>
> > > > > > >>>
> > > > > > >>>On Tue, 21 Jun 2016, Luis R. Rodriguez wrote:
> > > > > > >>>
> > > > > > Coccinelle has had parmap support since 1.0.2, this means
> > > > > > it supports --jobs, enabling built-in multithreaded 
> > > > > > functionality,
> > > > > > instead of needing one to script it out. Just look for --jobs
> > > > > > in the help output to determine if this is supported.
> > > > > > 
> > > > > > Also enable the load balancing to be dynamic, so that if a
> > > > > > thread finishes early we keep feeding it.
> > > > > > 
> > > > > > Note: now that we have all things handled for us, redirect 
> > > > > > stderr to
> > > > > > stdout as well to capture any possible errors or warnings 
> > > > > > issued by
> > > > > > coccinelle.
> > > > > > 
> > > > > > If --jobs is not supported we fallback to the old mechanism.
> > > > > > This also now accepts DEBUG_FILE= to specify where you want
> > > > > > stderr to be redirected to, by default we redirect stderr to
> > > > > > /dev/null.
> > > > > > >>>
> > > > > > >>>Why do you want to do something different for standard error in 
> > > > > > >>>the parmap
> > > > > > >>>and nonparmap case?
> > > > > > >>
> > > > > > >>We should just deprecate non-parmap later.
> > > > > > >
> > > > > > >that's not really getting at the point.  I like the DEBUG_FILE= 
> > > > > > >solution.
> > > > > > >I don't like merging stderr and stdout.  So you've put what to my 
> > > > > > >mind is
> > > > > > >the good solution only in the deprecated case (to my understanding 
> > > > > > >of
> > > > > > >the commit message).
> > > > > > 
> > > > > > I agree. You're not just "enabling parmap support". You're
> > > > > > also changing how messages to stderr are handled.
> > > > > > Maybe add the DEBUG_FILE mechanism in a separate patch for both
> > > > > > modes (parmap and non-parmap).
> > > > > 
> > > > > I'd prefer to just rip out non-parmap support and bump coccinelle
> > > > > requiremetns to at least 1.0.3, thoughts?
> > > > 
> > > > There are already too many changes in this patch series.
> > > > 
> > > > Also, I don't know what the 0-day people would find convenient.
> > > 
> > > I'd really prefer to not deal with supporting DEBUG_FILE  for non-parmap
> > > case due to the way parallelism is supported there, it uses wait(1) to
> > > wait on the shell, and for spawning this nasty thing:
> > > 
> > > eval "$@ --max $NPROC --index $i &"
> > > 
> > > Specially since we are likely to be able to deprecate this sooner
> > > rather than later I see little point in adding DEBUG_FILE into this
> > > mess.
> > 
> > Sorry, I didn't realize there was parallelism without parmap. 
> 
> Yea :( so is the change OK as-is then, only I need to update the commit log?
> 
> > My thought 
> > was that if someone is running Coccinelle on only one core, then why force 
> > them to use parmap.
> 
> Oh but that's different feedback. Sure, but why should that be an issue ?
> It would seem that coccinelle would just do the right thing with -j 1 used.
> 
> > Coccinelle could of course be updated to not use 
> > parmap when the number of cores is 1.
> 
> :) Single CPU systems are probably odd bests these days, either way I can
> update the script to avoid parmap if number of cpus is 1 since I'm respinning.

Some semantic patches have to be run single core, eg due to the use of 
finalize.  Perhaps there would be some reason to run them single core, if 
one had the same nmber of semantic patches as cores.  This was more 
relevant before dynamic load balancing though.  Single core is also better 
when using an option that takes a lot of include files and when using 
--include-headers-for-types.  Then one has maximal sharing of include file 
information across the treatment of the different C files.  In contrast, 
chunksize 1 is worst.  In that case, there is no effective caching of 
parsed header files, because Coccinelle has no shared memory.

Actually, it would be probably good to raise the default chunksize a bit 
for the latter reason.  It would depend on which files get assigned to 
which chunks though how much benefit it might have.

julia

Re: [PATCH 2/5] input: pmic8xxx-pwrkey: Add support for pm8018 pwrkey

[Bjorn Andersson]

On Fri 17 Jun 03:22 PDT 2016, Neil Armstrong wrote:

> In order to support pwrkey for Qualcomm MDM9615 SoC, add support
> for the pm8018 pwrkey in pmic8xxx-pwrkey.
> 
> Signed-off-by: Neil Armstrong 

Reviewed-by: Bjorn Andersson 

Regards,
Bjorn

linux-next: manual merge of the akpm-current tree with the kspp tree

[Stephen Rothwell]

Hi Andrew,

Today's linux-next merge of the akpm-current tree got a conflict in:

  mm/page_alloc.c

between commit:

  0df42965deb7 ("latent_entropy: Add the extra_latent_entropy kernel parameter")

from the kspp tree and commit:

  6f4f5445297d ("mm: charge/uncharge kmemcg from generic page allocator paths")

from the akpm-current tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc mm/page_alloc.c
index 02c7a0e6e66a,180f5afc5a1f..
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@@ -63,7 -63,7 +63,8 @@@
  #include 
  #include 
  #include 
 +#include 
+ #include 
  
  #include 
  #include 

Re: [PATCH v3 3/8] coccicheck: enable parmap support

[Julia Lawall]

On Wed, 22 Jun 2016, Luis R. Rodriguez wrote:

> On Tue, Jun 21, 2016 at 11:44:09PM +0200, Julia Lawall wrote:
> > 
> > 
> > On Tue, 21 Jun 2016, Luis R. Rodriguez wrote:
> > 
> > > On Tue, Jun 21, 2016 at 11:32:11PM +0200, Julia Lawall wrote:
> > > > 
> > > > 
> > > > On Tue, 21 Jun 2016, Luis R. Rodriguez wrote:
> > > > 
> > > > > On Tue, Jun 21, 2016 at 11:00:53PM +0200, Nicolas Palix (LIG) wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > Le 21/06/16 à 22:43, Julia Lawall a écrit :
> > > > > > >
> > > > > > >
> > > > > > >On Tue, 21 Jun 2016, Luis R. Rodriguez wrote:
> > > > > > >
> > > > > > >>On Tue, Jun 21, 2016 at 10:17:38PM +0200, Julia Lawall wrote:
> > > > > > >>>
> > > > > > >>>
> > > > > > >>>On Tue, 21 Jun 2016, Luis R. Rodriguez wrote:
> > > > > > >>>
> > > > > > Coccinelle has had parmap support since 1.0.2, this means
> > > > > > it supports --jobs, enabling built-in multithreaded 
> > > > > > functionality,
> > > > > > instead of needing one to script it out. Just look for --jobs
> > > > > > in the help output to determine if this is supported.
> > > > > > 
> > > > > > Also enable the load balancing to be dynamic, so that if a
> > > > > > thread finishes early we keep feeding it.
> > > > > > 
> > > > > > Note: now that we have all things handled for us, redirect 
> > > > > > stderr to
> > > > > > stdout as well to capture any possible errors or warnings 
> > > > > > issued by
> > > > > > coccinelle.
> > > > > > 
> > > > > > If --jobs is not supported we fallback to the old mechanism.
> > > > > > This also now accepts DEBUG_FILE= to specify where you want
> > > > > > stderr to be redirected to, by default we redirect stderr to
> > > > > > /dev/null.
> > > > > > >>>
> > > > > > >>>Why do you want to do something different for standard error in 
> > > > > > >>>the parmap
> > > > > > >>>and nonparmap case?
> > > > > > >>
> > > > > > >>We should just deprecate non-parmap later.
> > > > > > >
> > > > > > >that's not really getting at the point.  I like the DEBUG_FILE= 
> > > > > > >solution.
> > > > > > >I don't like merging stderr and stdout.  So you've put what to my 
> > > > > > >mind is
> > > > > > >the good solution only in the deprecated case (to my understanding 
> > > > > > >of
> > > > > > >the commit message).
> > > > > > 
> > > > > > I agree. You're not just "enabling parmap support". You're
> > > > > > also changing how messages to stderr are handled.
> > > > > > Maybe add the DEBUG_FILE mechanism in a separate patch for both
> > > > > > modes (parmap and non-parmap).
> > > > > 
> > > > > I'd prefer to just rip out non-parmap support and bump coccinelle
> > > > > requiremetns to at least 1.0.3, thoughts?
> > > > 
> > > > There are already too many changes in this patch series.
> > > > 
> > > > Also, I don't know what the 0-day people would find convenient.
> > > 
> > > I'd really prefer to not deal with supporting DEBUG_FILE  for non-parmap
> > > case due to the way parallelism is supported there, it uses wait(1) to
> > > wait on the shell, and for spawning this nasty thing:
> > > 
> > > eval "$@ --max $NPROC --index $i &"
> > > 
> > > Specially since we are likely to be able to deprecate this sooner
> > > rather than later I see little point in adding DEBUG_FILE into this
> > > mess.
> > 
> > Sorry, I didn't realize there was parallelism without parmap. 
> 
> Yea :( so is the change OK as-is then, only I need to update the commit log?
> 
> > My thought 
> > was that if someone is running Coccinelle on only one core, then why force 
> > them to use parmap.
> 
> Oh but that's different feedback. Sure, but why should that be an issue ?
> It would seem that coccinelle would just do the right thing with -j 1 used.
> 
> > Coccinelle could of course be updated to not use 
> > parmap when the number of cores is 1.
> 
> :) Single CPU systems are probably odd bests these days, either way I can
> update the script to avoid parmap if number of cpus is 1 since I'm respinning.

Some semantic patches have to be run single core, eg due to the use of 
finalize.  Perhaps there would be some reason to run them single core, if 
one had the same nmber of semantic patches as cores.  This was more 
relevant before dynamic load balancing though.  Single core is also better 
when using an option that takes a lot of include files and when using 
--include-headers-for-types.  Then one has maximal sharing of include file 
information across the treatment of the different C files.  In contrast, 
chunksize 1 is worst.  In that case, there is no effective caching of 
parsed header files, because Coccinelle has no shared memory.

Actually, it would be probably good to raise the default chunksize a bit 
for the latter reason.  It would depend on which files get assigned to 
which chunks though how much benefit it might have.

julia

Re: [PATCH] ppc: Fix BPF JIT for ABIv2

[Michael Ellerman]

On Fri, 2016-06-17 at 10:00 -0300, Thadeu Lima de Souza Cascardo wrote:
> From a984dc02b6317a1d3a3c2302385adba5227be5bd Mon Sep 17 00:00:00 2001
> From: Thadeu Lima de Souza Cascardo 
> Date: Wed, 15 Jun 2016 13:22:12 -0300
> Subject: [PATCH] ppc: Fix BPF JIT for ABIv2
> 
> ABIv2 used for ppc64le does not use function descriptors. Without this patch,
> whenever BPF JIT is enabled, we get a crash as below.
> 
...

> diff --git a/arch/powerpc/net/bpf_jit.h b/arch/powerpc/net/bpf_jit.h
> index 889fd19..28b89ed 100644
> --- a/arch/powerpc/net/bpf_jit.h
> +++ b/arch/powerpc/net/bpf_jit.h
> @@ -70,7 +70,7 @@ DECLARE_LOAD_FUNC(sk_load_half);
>  DECLARE_LOAD_FUNC(sk_load_byte);
>  DECLARE_LOAD_FUNC(sk_load_byte_msh);
>  
> -#ifdef CONFIG_PPC64
> +#if defined(CONFIG_PPC64) && (!defined(_CALL_ELF) || _CALL_ELF != 2)
>  #define FUNCTION_DESCR_SIZE  24
>  #else
>  #define FUNCTION_DESCR_SIZE  0
> diff --git a/arch/powerpc/net/bpf_jit_comp.c b/arch/powerpc/net/bpf_jit_comp.c
> index 2d66a84..035b887 100644
> --- a/arch/powerpc/net/bpf_jit_comp.c
> +++ b/arch/powerpc/net/bpf_jit_comp.c
> @@ -664,7 +664,7 @@ void bpf_jit_compile(struct bpf_prog *fp)
>  
>   if (image) {
>   bpf_flush_icache(code_base, code_base + (proglen/4));
> -#ifdef CONFIG_PPC64
> +#if defined(CONFIG_PPC64) && (!defined(_CALL_ELF) || _CALL_ELF != 2)
>   /* Function descriptor nastiness: Address + TOC */
>   ((u64 *)image)[0] = (u64)code_base;
>   ((u64 *)image)[1] = local_paca->kernel_toc;


Confirmed that even with this patch we still crash:

  # echo 1 > /proc/sys/net/core/bpf_jit_enable
  # modprobe test_bpf
  BPF filter opcode 0020 (@3) unsupported
  BPF filter opcode 0020 (@2) unsupported
  BPF filter opcode 0020 (@0) unsupported
  Unable to handle kernel paging request for data at address 0xd54f65e8
  Faulting instruction address: 0xc08765f8
  cpu 0x0: Vector: 300 (Data Access) at [c34f3480]
  pc: c08765f8: skb_copy_bits+0x158/0x330
  lr: c008fb7c: bpf_slow_path_byte+0x28/0x54
  sp: c34f3700
 msr: 80010280b033
 dar: d54f65e8
   dsisr: 4000
current = 0xc001f857d8d0
paca= 0xc7b8 softe: 0irq_happened: 0x01
  pid   = 2993, comm = modprobe
  Linux version 4.7.0-rc3-00055-g9497a1c1c5b4-dirty 
(mich...@ka3.ozlabs.ibm.com) () #30 SMP Wed Jun 22 15:06:58 AEST 2016
  enter ? for help
  [c34f3770] c008fb7c bpf_slow_path_byte+0x28/0x54
  [c34f37e0] d7bb004c
  [c34f3900] d5331668 test_bpf_init+0x5fc/0x7f8 [test_bpf]
  [c34f3a30] c000b628 do_one_initcall+0x68/0x1d0
  [c34f3af0] c09beb24 do_init_module+0x90/0x240
  [c34f3b80] c01642bc load_module+0x206c/0x22f0
  [c34f3d30] c01648b0 SyS_finit_module+0x120/0x180
  [c34f3e30] c0009260 system_call+0x38/0x108
  --- Exception: c01 (System Call) at 3fff7ffa2db4


cheers

Re: [PATCH] ppc: Fix BPF JIT for ABIv2

[Michael Ellerman]

On Fri, 2016-06-17 at 10:00 -0300, Thadeu Lima de Souza Cascardo wrote:
> From a984dc02b6317a1d3a3c2302385adba5227be5bd Mon Sep 17 00:00:00 2001
> From: Thadeu Lima de Souza Cascardo 
> Date: Wed, 15 Jun 2016 13:22:12 -0300
> Subject: [PATCH] ppc: Fix BPF JIT for ABIv2
> 
> ABIv2 used for ppc64le does not use function descriptors. Without this patch,
> whenever BPF JIT is enabled, we get a crash as below.
> 
...

> diff --git a/arch/powerpc/net/bpf_jit.h b/arch/powerpc/net/bpf_jit.h
> index 889fd19..28b89ed 100644
> --- a/arch/powerpc/net/bpf_jit.h
> +++ b/arch/powerpc/net/bpf_jit.h
> @@ -70,7 +70,7 @@ DECLARE_LOAD_FUNC(sk_load_half);
>  DECLARE_LOAD_FUNC(sk_load_byte);
>  DECLARE_LOAD_FUNC(sk_load_byte_msh);
>  
> -#ifdef CONFIG_PPC64
> +#if defined(CONFIG_PPC64) && (!defined(_CALL_ELF) || _CALL_ELF != 2)
>  #define FUNCTION_DESCR_SIZE  24
>  #else
>  #define FUNCTION_DESCR_SIZE  0
> diff --git a/arch/powerpc/net/bpf_jit_comp.c b/arch/powerpc/net/bpf_jit_comp.c
> index 2d66a84..035b887 100644
> --- a/arch/powerpc/net/bpf_jit_comp.c
> +++ b/arch/powerpc/net/bpf_jit_comp.c
> @@ -664,7 +664,7 @@ void bpf_jit_compile(struct bpf_prog *fp)
>  
>   if (image) {
>   bpf_flush_icache(code_base, code_base + (proglen/4));
> -#ifdef CONFIG_PPC64
> +#if defined(CONFIG_PPC64) && (!defined(_CALL_ELF) || _CALL_ELF != 2)
>   /* Function descriptor nastiness: Address + TOC */
>   ((u64 *)image)[0] = (u64)code_base;
>   ((u64 *)image)[1] = local_paca->kernel_toc;


Confirmed that even with this patch we still crash:

  # echo 1 > /proc/sys/net/core/bpf_jit_enable
  # modprobe test_bpf
  BPF filter opcode 0020 (@3) unsupported
  BPF filter opcode 0020 (@2) unsupported
  BPF filter opcode 0020 (@0) unsupported
  Unable to handle kernel paging request for data at address 0xd54f65e8
  Faulting instruction address: 0xc08765f8
  cpu 0x0: Vector: 300 (Data Access) at [c34f3480]
  pc: c08765f8: skb_copy_bits+0x158/0x330
  lr: c008fb7c: bpf_slow_path_byte+0x28/0x54
  sp: c34f3700
 msr: 80010280b033
 dar: d54f65e8
   dsisr: 4000
current = 0xc001f857d8d0
paca= 0xc7b8 softe: 0irq_happened: 0x01
  pid   = 2993, comm = modprobe
  Linux version 4.7.0-rc3-00055-g9497a1c1c5b4-dirty 
(mich...@ka3.ozlabs.ibm.com) () #30 SMP Wed Jun 22 15:06:58 AEST 2016
  enter ? for help
  [c34f3770] c008fb7c bpf_slow_path_byte+0x28/0x54
  [c34f37e0] d7bb004c
  [c34f3900] d5331668 test_bpf_init+0x5fc/0x7f8 [test_bpf]
  [c34f3a30] c000b628 do_one_initcall+0x68/0x1d0
  [c34f3af0] c09beb24 do_init_module+0x90/0x240
  [c34f3b80] c01642bc load_module+0x206c/0x22f0
  [c34f3d30] c01648b0 SyS_finit_module+0x120/0x180
  [c34f3e30] c0009260 system_call+0x38/0x108
  --- Exception: c01 (System Call) at 3fff7ffa2db4


cheers

Re: [PATCH 3/5] rtc: rtc-pm8xxx: Add support for pm8018 rtc

[Bjorn Andersson]

On Fri 17 Jun 03:22 PDT 2016, Neil Armstrong wrote:

> In order to support RTC on Qualcomm MDM9615 SoC, add support for
> the pm8018 rtc in rtc-pm8xxx driver.
> 
> Signed-off-by: Neil Armstrong 
> ---
>  Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt |  1 +
>  drivers/rtc/rtc-pm8xxx.c  | 11 +++
>  2 files changed, 12 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt 
> b/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt
> index f24f334..37a088f 100644
> --- a/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt
> +++ b/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt
> @@ -62,6 +62,7 @@ The below bindings specify the set of valid subnodes.
>   "qcom,pm8058-rtc"
>   "qcom,pm8921-rtc"
>   "qcom,pm8941-rtc"
> + "qcom,pm8018-rtc"

Would be nice if we kept this sorted, but the patch looks good.

Reviewed-by: Bjorn Andersson 

Regards,
Bjorn

Re: [PATCH 1/2] workqueue: Move wq_update_unbound_numa() to the beginning of CPU_ONLINE

[Gautham R Shenoy]

On Tue, Jun 21, 2016 at 09:47:19PM +0200, Peter Zijlstra wrote:
> On Tue, Jun 21, 2016 at 03:43:56PM -0400, Tejun Heo wrote:
> > On Tue, Jun 21, 2016 at 09:37:09PM +0200, Peter Zijlstra wrote:
> > > Hurm.. So I've applied it, just to get this issue sorted, but I'm not
> > > entirely sure I like it.
> > > 
> > > I think I prefer ego's version because that makes it harder to get stuff
> > > to run on !active,online cpus. I think we really want to be careful what
> > > gets to run during that state.
> > 
> > The original patch just did set_cpus_allowed one more time late enough
> > so that the target kthread (in most cases) doesn't have to go through
> > fallback rq selection afterwards.  I don't know what the long term
> > solution is but CPU_ONLINE callbacks should be able to bind kthreads
> > to the new CPU one way or the other.
> 
> Fair enough; clearly I need to stare harder. In any case, patch is on
> its way to sched/urgent.

Thanks Tejun, Peter!
> 

--
Regards
gautham.

Re: [PATCH v4 0/5] /dev/random - a new approach

[Stephan Mueller]

Am Dienstag, 21. Juni 2016, 15:31:07 schrieb Austin S. Hemmelgarn:

Hi Austin,

> > Little data, interesting statement for results on 200+ systems including
> > all major CPU arches all showing information leading in the same
> > directions.
> Let me try rephrasing this to make it a bit clearer:
> 1. You have lots of data on server systems.
> 2. You have a significant amount of data on desktop/workstation type
> systems.
> 3. You have very little data on embedded systems.
> 
> and here are your arguments:
> A. This works well on server systems.
> B. This works well on desktop systems.
> C. This works well on embedded systems.
> 
> Arguments A and B are substantiated directly by points 1 and 2.
> Argument C is not substantiated thoroughly because of point 3.
> My complaint is about argument C given point 3.

Then let me rephrase what I try to say: my RNG rests on the intrinsic 
functionality of CPUs. When I show that such intrinsic behavior is present in 
various architectures I show that there is a common ground for the basis of 
the RNG.

I tested on all CPUs of all large scale architectures (including the 
architectures that are commonly used for embedded devices) and demonstrated 
that the fundamental phenomenon the RNG rests on is present in all 
architectures.

I do not care about the form factor of the test system server, desktop or 
embedded systems nor do I care about the number of attached devices -- the 
form factor and number of attached devices is the differentiator of what you 
call embedded vs server vs desktop.

Heck, I have written a test that executes the RNG on bare metal (without OS 
and with only a keyboard as device present -- i.e no interrupts are received 
apart from a keyboard), which demonstrates that the phenomenon is present.

Furthermore, chapter 6 of my document analyzes the root cause of the RNG and 
here you see clearly that it has nothing to do with the size of the CPU or its 
attached devices or the size of RAM.

The massive number of x86 tests shall demonstrate the common theme I see: the 
newer the CPU the larger the phenomenon is the RNG rests on.

I use different OSes (including microkernel systems) for testing to 
demonstrate that the OS does not materially change the test results.
> 
> I'm not saying you have insufficient data to support argument A or B,
> only that you have insufficient data to support argument C.

And I think that this statement is not correct. But I would always welcome 
more testing.
> 
> Android barely counts as an embedded system anymore, as many Android

Then read F.28ff -- these are truly embedded systems (i.e. the routers that I 
have on my desk)

> phones can outperform most inexpensive desktop and laptop systems, and
> even some rather expensive laptops.  This leaves the only systems that
> can be assumed without further information to be representative of
> embedded boards to be the ones running Genode, and possibly the MIPS
> systems, which is a total of about 10 results out of hundreds for
> servers and desktops/workstations.


Ciao
Stephan

Re: [PATCH 1/2] workqueue: Move wq_update_unbound_numa() to the beginning of CPU_ONLINE

[Gautham R Shenoy]

On Tue, Jun 21, 2016 at 09:47:19PM +0200, Peter Zijlstra wrote:
> On Tue, Jun 21, 2016 at 03:43:56PM -0400, Tejun Heo wrote:
> > On Tue, Jun 21, 2016 at 09:37:09PM +0200, Peter Zijlstra wrote:
> > > Hurm.. So I've applied it, just to get this issue sorted, but I'm not
> > > entirely sure I like it.
> > > 
> > > I think I prefer ego's version because that makes it harder to get stuff
> > > to run on !active,online cpus. I think we really want to be careful what
> > > gets to run during that state.
> > 
> > The original patch just did set_cpus_allowed one more time late enough
> > so that the target kthread (in most cases) doesn't have to go through
> > fallback rq selection afterwards.  I don't know what the long term
> > solution is but CPU_ONLINE callbacks should be able to bind kthreads
> > to the new CPU one way or the other.
> 
> Fair enough; clearly I need to stare harder. In any case, patch is on
> its way to sched/urgent.

Thanks Tejun, Peter!
> 

--
Regards
gautham.

Re: [PATCH v4 0/5] /dev/random - a new approach

[Stephan Mueller]

Am Dienstag, 21. Juni 2016, 15:31:07 schrieb Austin S. Hemmelgarn:

Hi Austin,

> > Little data, interesting statement for results on 200+ systems including
> > all major CPU arches all showing information leading in the same
> > directions.
> Let me try rephrasing this to make it a bit clearer:
> 1. You have lots of data on server systems.
> 2. You have a significant amount of data on desktop/workstation type
> systems.
> 3. You have very little data on embedded systems.
> 
> and here are your arguments:
> A. This works well on server systems.
> B. This works well on desktop systems.
> C. This works well on embedded systems.
> 
> Arguments A and B are substantiated directly by points 1 and 2.
> Argument C is not substantiated thoroughly because of point 3.
> My complaint is about argument C given point 3.

Then let me rephrase what I try to say: my RNG rests on the intrinsic 
functionality of CPUs. When I show that such intrinsic behavior is present in 
various architectures I show that there is a common ground for the basis of 
the RNG.

I tested on all CPUs of all large scale architectures (including the 
architectures that are commonly used for embedded devices) and demonstrated 
that the fundamental phenomenon the RNG rests on is present in all 
architectures.

I do not care about the form factor of the test system server, desktop or 
embedded systems nor do I care about the number of attached devices -- the 
form factor and number of attached devices is the differentiator of what you 
call embedded vs server vs desktop.

Heck, I have written a test that executes the RNG on bare metal (without OS 
and with only a keyboard as device present -- i.e no interrupts are received 
apart from a keyboard), which demonstrates that the phenomenon is present.

Furthermore, chapter 6 of my document analyzes the root cause of the RNG and 
here you see clearly that it has nothing to do with the size of the CPU or its 
attached devices or the size of RAM.

The massive number of x86 tests shall demonstrate the common theme I see: the 
newer the CPU the larger the phenomenon is the RNG rests on.

I use different OSes (including microkernel systems) for testing to 
demonstrate that the OS does not materially change the test results.
> 
> I'm not saying you have insufficient data to support argument A or B,
> only that you have insufficient data to support argument C.

And I think that this statement is not correct. But I would always welcome 
more testing.
> 
> Android barely counts as an embedded system anymore, as many Android

Then read F.28ff -- these are truly embedded systems (i.e. the routers that I 
have on my desk)

> phones can outperform most inexpensive desktop and laptop systems, and
> even some rather expensive laptops.  This leaves the only systems that
> can be assumed without further information to be representative of
> embedded boards to be the ones running Genode, and possibly the MIPS
> systems, which is a total of about 10 results out of hundreds for
> servers and desktops/workstations.


Ciao
Stephan

Re: [PATCH 3/5] rtc: rtc-pm8xxx: Add support for pm8018 rtc

[Bjorn Andersson]

On Fri 17 Jun 03:22 PDT 2016, Neil Armstrong wrote:

> In order to support RTC on Qualcomm MDM9615 SoC, add support for
> the pm8018 rtc in rtc-pm8xxx driver.
> 
> Signed-off-by: Neil Armstrong 
> ---
>  Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt |  1 +
>  drivers/rtc/rtc-pm8xxx.c  | 11 +++
>  2 files changed, 12 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt 
> b/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt
> index f24f334..37a088f 100644
> --- a/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt
> +++ b/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt
> @@ -62,6 +62,7 @@ The below bindings specify the set of valid subnodes.
>   "qcom,pm8058-rtc"
>   "qcom,pm8921-rtc"
>   "qcom,pm8941-rtc"
> + "qcom,pm8018-rtc"

Would be nice if we kept this sorted, but the patch looks good.

Reviewed-by: Bjorn Andersson 

Regards,
Bjorn

[PATCHv2 1/1] thermal: core: call thermal_zone_device_update() after mode update

[Eduardo Valentin]

Because several drivers do the following pattern:
.set_mode()
   ...
   local_data->mode = new_mode;
   thermal_zone_device_update(tz);

makes sense to simply do the thermal_zone_device_update()
in thermal core, after setting the new mode.

Also, this patch also remove deadlocks on drivers that
call thermal_zone_device_update() on .set_mode(),
as .set_mode()  is now called always with tz->lock held.

Cc: "Rafael J. Wysocki" 
Cc: Len Brown 
Cc: linux-a...@vger.kernel.org
Cc: "Lee, Chun-Yi" 
Cc: Darren Hart 
Cc: Zhang Rui 
Cc: Keerthy 
Cc: linux-kernel@vger.kernel.org
Cc: linux-o...@vger.kernel.org
Cc: platform-driver-...@vger.kernel.org
Cc: linux...@vger.kernel.org
Signed-off-by: Eduardo Valentin 
---
Please ignore last version.

V1-> V2:
Cleaned the patch and remove unrelated changes.
---

 drivers/acpi/thermal.c | 2 --
 drivers/platform/x86/acerhdf.c | 1 -
 drivers/thermal/imx_thermal.c  | 1 -
 drivers/thermal/of-thermal.c   | 1 -
 drivers/thermal/thermal_sysfs.c| 1 +
 drivers/thermal/ti-soc-thermal/ti-thermal-common.c | 1 -
 6 files changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/acpi/thermal.c b/drivers/acpi/thermal.c
index 82707f9..8582b88 100644
--- a/drivers/acpi/thermal.c
+++ b/drivers/acpi/thermal.c
@@ -519,8 +519,6 @@ static void acpi_thermal_check(void *data)
 
if (!tz->tz_enabled)
return;
-
-   thermal_zone_device_update(tz->thermal_zone);
 }
 
 /* sys I/F for generic thermal sysfs support */
diff --git a/drivers/platform/x86/acerhdf.c b/drivers/platform/x86/acerhdf.c
index 460fa67..aee33ba 100644
--- a/drivers/platform/x86/acerhdf.c
+++ b/drivers/platform/x86/acerhdf.c
@@ -405,7 +405,6 @@ static inline void acerhdf_enable_kernelmode(void)
kernelmode = 1;
 
thz_dev->polling_delay = interval*1000;
-   thermal_zone_device_update(thz_dev);
pr_notice("kernel mode fan control ON\n");
 }
 
diff --git a/drivers/thermal/imx_thermal.c b/drivers/thermal/imx_thermal.c
index c5547bd..a413eb6 100644
--- a/drivers/thermal/imx_thermal.c
+++ b/drivers/thermal/imx_thermal.c
@@ -246,7 +246,6 @@ static int imx_set_mode(struct thermal_zone_device *tz,
}
 
data->mode = mode;
-   thermal_zone_device_update(tz);
 
return 0;
 }
diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
index b8e509c..4602e2e 100644
--- a/drivers/thermal/of-thermal.c
+++ b/drivers/thermal/of-thermal.c
@@ -292,7 +292,6 @@ static int of_thermal_set_mode(struct thermal_zone_device 
*tz,
mutex_unlock(>lock);
 
data->mode = mode;
-   thermal_zone_device_update(tz);
 
return 0;
 }
diff --git a/drivers/thermal/thermal_sysfs.c b/drivers/thermal/thermal_sysfs.c
index 743df50..3d0dc30 100644
--- a/drivers/thermal/thermal_sysfs.c
+++ b/drivers/thermal/thermal_sysfs.c
@@ -100,6 +100,7 @@ mode_store(struct device *dev, struct device_attribute 
*attr,
mutex_lock(>lock);
result = tz->ops->set_mode(tz, mode);
mutex_unlock(>lock);
+   thermal_zone_device_update(tz);
 
if (result)
return result;
diff --git a/drivers/thermal/ti-soc-thermal/ti-thermal-common.c 
b/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
index 15c0a9a..9a5a3a3 100644
--- a/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
+++ b/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
@@ -205,7 +205,6 @@ static int ti_thermal_set_mode(struct thermal_zone_device 
*thermal,
data->mode = mode;
ti_bandgap_write_update_interval(bgp, data->sensor_id,
data->ti_thermal->polling_delay);
-   thermal_zone_device_update(data->ti_thermal);
dev_dbg(>device, "thermal polling set for duration=%d msec\n",
data->ti_thermal->polling_delay);
 
-- 
2.1.4

[PATCHv2 1/1] thermal: core: call thermal_zone_device_update() after mode update

[Eduardo Valentin]

Because several drivers do the following pattern:
.set_mode()
   ...
   local_data->mode = new_mode;
   thermal_zone_device_update(tz);

makes sense to simply do the thermal_zone_device_update()
in thermal core, after setting the new mode.

Also, this patch also remove deadlocks on drivers that
call thermal_zone_device_update() on .set_mode(),
as .set_mode()  is now called always with tz->lock held.

Cc: "Rafael J. Wysocki" 
Cc: Len Brown 
Cc: linux-a...@vger.kernel.org
Cc: "Lee, Chun-Yi" 
Cc: Darren Hart 
Cc: Zhang Rui 
Cc: Keerthy 
Cc: linux-kernel@vger.kernel.org
Cc: linux-o...@vger.kernel.org
Cc: platform-driver-...@vger.kernel.org
Cc: linux...@vger.kernel.org
Signed-off-by: Eduardo Valentin 
---
Please ignore last version.

V1-> V2:
Cleaned the patch and remove unrelated changes.
---

 drivers/acpi/thermal.c | 2 --
 drivers/platform/x86/acerhdf.c | 1 -
 drivers/thermal/imx_thermal.c  | 1 -
 drivers/thermal/of-thermal.c   | 1 -
 drivers/thermal/thermal_sysfs.c| 1 +
 drivers/thermal/ti-soc-thermal/ti-thermal-common.c | 1 -
 6 files changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/acpi/thermal.c b/drivers/acpi/thermal.c
index 82707f9..8582b88 100644
--- a/drivers/acpi/thermal.c
+++ b/drivers/acpi/thermal.c
@@ -519,8 +519,6 @@ static void acpi_thermal_check(void *data)
 
if (!tz->tz_enabled)
return;
-
-   thermal_zone_device_update(tz->thermal_zone);
 }
 
 /* sys I/F for generic thermal sysfs support */
diff --git a/drivers/platform/x86/acerhdf.c b/drivers/platform/x86/acerhdf.c
index 460fa67..aee33ba 100644
--- a/drivers/platform/x86/acerhdf.c
+++ b/drivers/platform/x86/acerhdf.c
@@ -405,7 +405,6 @@ static inline void acerhdf_enable_kernelmode(void)
kernelmode = 1;
 
thz_dev->polling_delay = interval*1000;
-   thermal_zone_device_update(thz_dev);
pr_notice("kernel mode fan control ON\n");
 }
 
diff --git a/drivers/thermal/imx_thermal.c b/drivers/thermal/imx_thermal.c
index c5547bd..a413eb6 100644
--- a/drivers/thermal/imx_thermal.c
+++ b/drivers/thermal/imx_thermal.c
@@ -246,7 +246,6 @@ static int imx_set_mode(struct thermal_zone_device *tz,
}
 
data->mode = mode;
-   thermal_zone_device_update(tz);
 
return 0;
 }
diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
index b8e509c..4602e2e 100644
--- a/drivers/thermal/of-thermal.c
+++ b/drivers/thermal/of-thermal.c
@@ -292,7 +292,6 @@ static int of_thermal_set_mode(struct thermal_zone_device 
*tz,
mutex_unlock(>lock);
 
data->mode = mode;
-   thermal_zone_device_update(tz);
 
return 0;
 }
diff --git a/drivers/thermal/thermal_sysfs.c b/drivers/thermal/thermal_sysfs.c
index 743df50..3d0dc30 100644
--- a/drivers/thermal/thermal_sysfs.c
+++ b/drivers/thermal/thermal_sysfs.c
@@ -100,6 +100,7 @@ mode_store(struct device *dev, struct device_attribute 
*attr,
mutex_lock(>lock);
result = tz->ops->set_mode(tz, mode);
mutex_unlock(>lock);
+   thermal_zone_device_update(tz);
 
if (result)
return result;
diff --git a/drivers/thermal/ti-soc-thermal/ti-thermal-common.c 
b/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
index 15c0a9a..9a5a3a3 100644
--- a/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
+++ b/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
@@ -205,7 +205,6 @@ static int ti_thermal_set_mode(struct thermal_zone_device 
*thermal,
data->mode = mode;
ti_bandgap_write_update_interval(bgp, data->sensor_id,
data->ti_thermal->polling_delay);
-   thermal_zone_device_update(data->ti_thermal);
dev_dbg(>device, "thermal polling set for duration=%d msec\n",
data->ti_thermal->polling_delay);
 
-- 
2.1.4

Re: [PATCH] torture: use ktime_t consistently

[Paul E. McKenney]

On Wed, Jun 22, 2016 at 10:00:24AM +0800, Boqun Feng wrote:
> Hi Paul,
> 
> On Tue, Jun 21, 2016 at 11:39:46AM -0700, Paul E. McKenney wrote:
> > On Mon, Jun 20, 2016 at 09:29:56PM +0200, Arnd Bergmann wrote:
> > > On Monday, June 20, 2016 11:37:57 AM CEST Paul E. McKenney wrote:
> > > > On Mon, Jun 20, 2016 at 08:29:48PM +0200, Arnd Bergmann wrote:
> > > > > On Monday, June 20, 2016 11:21:05 AM CEST Paul E. McKenney wrote:
> > > > > > On Mon, Jun 20, 2016 at 05:56:40PM +0200, Arnd Bergmann wrote:
> > > > > >  
> > > > > > @@ -446,9 +447,9 @@ EXPORT_SYMBOL_GPL(torture_shuffle_cleanup);
> > > > > >   * Variables for auto-shutdown.  This allows "lights out" torture 
> > > > > > runs
> > > > > >   * to be fully scripted.
> > > > > >   */
> > > > > > -static int shutdown_secs;  /* desired test duration in 
> > > > > > seconds. */
> > > > > > +static ktime_t shutdown_ms;/* desired test 
> > > > > > duration in seconds. */
> > > > > 
> > > > > the variable name is a bit odd.
> > > > 
> > > > The comment is certainly now wrong, good catch!
> > > > 
> > > > If there was an s_to_ktime(), I would have kept the old name, but I 
> > > > could
> > > > not find one.  Possibly due to me being blind...
> > > 
> > > I used "ktime_set(ssecs, 0)", which is almost what you want. Given that
> > > the majority of users of ktime_set() actually pass a zero nanoseconds 
> > > portion,
> > > it would probably be nice to add secs_to_ktime() as well.
> > 
> > And there are quite a few that pass in zero for the seconds portion, and
> > many that pass in zero for both.
> > 
> > For the moment, I switched to ktime_set(), as you suggested.
> > 
> > > > > > @@ -511,10 +513,10 @@ int torture_shutdown_init(int ssecs, void 
> > > > > > (*cleanup)(void))
> > > > > >  {
> > > > > > int ret = 0;
> > > > > >  
> > > > > > -   shutdown_secs = ssecs;
> > > > > > torture_shutdown_hook = cleanup;
> > > > > > -   if (shutdown_secs > 0) {
> > > > > > -   shutdown_time = jiffies + shutdown_secs * HZ;
> > > > > > +   if (ssecs > 0) {
> > > > > > +   shutdown_ms = ms_to_ktime(ssecs * 1000ULL);
> > > > > > +   shutdown_time = ktime_add(ktime_get(), shutdown_ms);
> > > > > > ret = torture_create_kthread(torture_shutdown, NULL,
> > > > > >  shutdown_task);
> > > > > 
> > > > > and I picked ktime_set(ssecs, 0) instead of ms_to_ktime(ssecs * 
> > > > > 1000ULL), but
> > > > > both differences are just cosmetic and should end up in exactly the
> > > > > same object code that I suggested. Unless we both made the same 
> > > > > mistake,
> > > > > your version should be good too.
> > > > 
> > > > Thank you for looking it over!  My I apply your Acked-by:, Reviewed-by:,
> > > > or some such?
> > > 
> > > I had not looked over the original changes before, but have done that now,
> > > please add my 
> > > 
> > > Acked-by: Arnd Bergmann 
> > 
> > Thank you!
> > 
> > > I found one small detail that you could change: instead of using
> > > HRTIMER_MODE_REL, you could actually use HRTIME_MODE_ABS and just
> > > pass the end time instead of computing the difference every time.
> > > 
> > > You still need to take the difference for printing, but you could
> > > do that in place then:
> > > 
> > >if (verbose)
> > >  pr_alert("%s" TORTURE_FLAG
> > >   "torture_shutdown task: %llu ms remaining\n",
> > >   torture_type, ktime_ms_delta(shutdown_time, 
> > > ktime_get()));
> > 
> > Good point!  I did this, but used ktime_snap instead of ktime_get().
> > I have to capture ktime_snap anyway for the loop termination condition.
> > Updated commit below.
> > 
> > Thanx, Paul
> > 
> > 
> > 
> > commit 0a387a5b8718feace7aadd847937fdc336567a36
> > Author: Paul E. McKenney 
> > Date:   Sat Jun 18 07:45:43 2016 -0700
> > 
> > torture: Convert torture_shutdown() to hrtimer
> > 
> > Upcoming changes to the timer wheel introduce significant inaccuracy
> > and possibly also an ultimate limit on timeout duration.  This is
> > a problem for the current implementation of torture_shutdown() because
> > (1) shutdown times are user-specified, and can therefore be quite
> > long, and (2) the torture scripting will kill a test instance that
> > runs for more than a few minutes longer than scheduled.  This commit
> > therefore converts the torture_shutdown() timed waits to an hrtimer.
> > 
> > Signed-off-by: Paul E. McKenney 
> > Acked-by: Arnd Bergmann 
> > 
> > diff --git a/kernel/torture.c b/kernel/torture.c
> > index 75961b3decfe..08f45621394a 100644
> > --- a/kernel/torture.c
> > +++ b/kernel/torture.c
> > @@ -43,6 +43,7 @@
> >  #include 
> >  #include 
> >  

Re: [PATCH] torture: use ktime_t consistently

[Paul E. McKenney]

On Wed, Jun 22, 2016 at 10:00:24AM +0800, Boqun Feng wrote:
> Hi Paul,
> 
> On Tue, Jun 21, 2016 at 11:39:46AM -0700, Paul E. McKenney wrote:
> > On Mon, Jun 20, 2016 at 09:29:56PM +0200, Arnd Bergmann wrote:
> > > On Monday, June 20, 2016 11:37:57 AM CEST Paul E. McKenney wrote:
> > > > On Mon, Jun 20, 2016 at 08:29:48PM +0200, Arnd Bergmann wrote:
> > > > > On Monday, June 20, 2016 11:21:05 AM CEST Paul E. McKenney wrote:
> > > > > > On Mon, Jun 20, 2016 at 05:56:40PM +0200, Arnd Bergmann wrote:
> > > > > >  
> > > > > > @@ -446,9 +447,9 @@ EXPORT_SYMBOL_GPL(torture_shuffle_cleanup);
> > > > > >   * Variables for auto-shutdown.  This allows "lights out" torture 
> > > > > > runs
> > > > > >   * to be fully scripted.
> > > > > >   */
> > > > > > -static int shutdown_secs;  /* desired test duration in 
> > > > > > seconds. */
> > > > > > +static ktime_t shutdown_ms;/* desired test 
> > > > > > duration in seconds. */
> > > > > 
> > > > > the variable name is a bit odd.
> > > > 
> > > > The comment is certainly now wrong, good catch!
> > > > 
> > > > If there was an s_to_ktime(), I would have kept the old name, but I 
> > > > could
> > > > not find one.  Possibly due to me being blind...
> > > 
> > > I used "ktime_set(ssecs, 0)", which is almost what you want. Given that
> > > the majority of users of ktime_set() actually pass a zero nanoseconds 
> > > portion,
> > > it would probably be nice to add secs_to_ktime() as well.
> > 
> > And there are quite a few that pass in zero for the seconds portion, and
> > many that pass in zero for both.
> > 
> > For the moment, I switched to ktime_set(), as you suggested.
> > 
> > > > > > @@ -511,10 +513,10 @@ int torture_shutdown_init(int ssecs, void 
> > > > > > (*cleanup)(void))
> > > > > >  {
> > > > > > int ret = 0;
> > > > > >  
> > > > > > -   shutdown_secs = ssecs;
> > > > > > torture_shutdown_hook = cleanup;
> > > > > > -   if (shutdown_secs > 0) {
> > > > > > -   shutdown_time = jiffies + shutdown_secs * HZ;
> > > > > > +   if (ssecs > 0) {
> > > > > > +   shutdown_ms = ms_to_ktime(ssecs * 1000ULL);
> > > > > > +   shutdown_time = ktime_add(ktime_get(), shutdown_ms);
> > > > > > ret = torture_create_kthread(torture_shutdown, NULL,
> > > > > >  shutdown_task);
> > > > > 
> > > > > and I picked ktime_set(ssecs, 0) instead of ms_to_ktime(ssecs * 
> > > > > 1000ULL), but
> > > > > both differences are just cosmetic and should end up in exactly the
> > > > > same object code that I suggested. Unless we both made the same 
> > > > > mistake,
> > > > > your version should be good too.
> > > > 
> > > > Thank you for looking it over!  My I apply your Acked-by:, Reviewed-by:,
> > > > or some such?
> > > 
> > > I had not looked over the original changes before, but have done that now,
> > > please add my 
> > > 
> > > Acked-by: Arnd Bergmann 
> > 
> > Thank you!
> > 
> > > I found one small detail that you could change: instead of using
> > > HRTIMER_MODE_REL, you could actually use HRTIME_MODE_ABS and just
> > > pass the end time instead of computing the difference every time.
> > > 
> > > You still need to take the difference for printing, but you could
> > > do that in place then:
> > > 
> > >if (verbose)
> > >  pr_alert("%s" TORTURE_FLAG
> > >   "torture_shutdown task: %llu ms remaining\n",
> > >   torture_type, ktime_ms_delta(shutdown_time, 
> > > ktime_get()));
> > 
> > Good point!  I did this, but used ktime_snap instead of ktime_get().
> > I have to capture ktime_snap anyway for the loop termination condition.
> > Updated commit below.
> > 
> > Thanx, Paul
> > 
> > 
> > 
> > commit 0a387a5b8718feace7aadd847937fdc336567a36
> > Author: Paul E. McKenney 
> > Date:   Sat Jun 18 07:45:43 2016 -0700
> > 
> > torture: Convert torture_shutdown() to hrtimer
> > 
> > Upcoming changes to the timer wheel introduce significant inaccuracy
> > and possibly also an ultimate limit on timeout duration.  This is
> > a problem for the current implementation of torture_shutdown() because
> > (1) shutdown times are user-specified, and can therefore be quite
> > long, and (2) the torture scripting will kill a test instance that
> > runs for more than a few minutes longer than scheduled.  This commit
> > therefore converts the torture_shutdown() timed waits to an hrtimer.
> > 
> > Signed-off-by: Paul E. McKenney 
> > Acked-by: Arnd Bergmann 
> > 
> > diff --git a/kernel/torture.c b/kernel/torture.c
> > index 75961b3decfe..08f45621394a 100644
> > --- a/kernel/torture.c
> > +++ b/kernel/torture.c
> > @@ -43,6 +43,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  
> > @@ -446,9 +447,9 @@ 

Re: [PATCH v6 07/11] powerpc/powernv: set power_save func after the idle states are initialized

[Michael Neuling]

On Wed, 2016-06-22 at 11:54 +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2016-06-08 at 11:54 -0500, Shreyas B. Prabhu wrote:
> > 
> > pnv_init_idle_states discovers supported idle states from the
> > device tree and does the required initialization. Set power_save
> > function pointer only after this initialization is done
> > 
> > Reviewed-by: Gautham R. Shenoy 
> > Signed-off-by: Shreyas B. Prabhu 
> Acked-by: Benjamin Herrenschmidt 
> 
> Please merge that one as-is now, no need to wait for the rest, as
> otherwise pwoer9 crashes at boot. It doesn't need to wait for the
> rest of the series.

Acked-by: Michael Neuling 

For the same reason. Without this we need powersave=off on the cmdline on
POWER9.

Mikey

> 
> Cheers,
> Ben.
> 
> > 
> > ---
> > - No changes since v1
> > 
> >  arch/powerpc/platforms/powernv/idle.c  | 3 +++
> >  arch/powerpc/platforms/powernv/setup.c | 2 +-
> >  2 files changed, 4 insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/powerpc/platforms/powernv/idle.c
> > b/arch/powerpc/platforms/powernv/idle.c
> > index fcc8b68..fbb09fb 100644
> > --- a/arch/powerpc/platforms/powernv/idle.c
> > +++ b/arch/powerpc/platforms/powernv/idle.c
> > @@ -285,6 +285,9 @@ static int __init pnv_init_idle_states(void)
> >     }
> >  
> >     pnv_alloc_idle_core_states();
> > +
> > +   if (supported_cpuidle_states & OPAL_PM_NAP_ENABLED)
> > +   ppc_md.power_save = power7_idle;
> >  out_free:
> >     kfree(flags);
> >  out:
> > diff --git a/arch/powerpc/platforms/powernv/setup.c
> > b/arch/powerpc/platforms/powernv/setup.c
> > index ee6430b..8492bbb 100644
> > --- a/arch/powerpc/platforms/powernv/setup.c
> > +++ b/arch/powerpc/platforms/powernv/setup.c
> > @@ -315,7 +315,7 @@ define_machine(powernv) {
> >     .get_proc_freq  = pnv_get_proc_freq,
> >     .progress   = pnv_progress,
> >     .machine_shutdown   = pnv_shutdown,
> > -   .power_save = power7_idle,
> > +   .power_save = NULL,
> >     .calibrate_decr = generic_calibrate_decr,
> >  #ifdef CONFIG_KEXEC
> >     .kexec_cpu_down = pnv_kexec_cpu_down,

Re: [PATCH v6 07/11] powerpc/powernv: set power_save func after the idle states are initialized

[Michael Neuling]

On Wed, 2016-06-22 at 11:54 +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2016-06-08 at 11:54 -0500, Shreyas B. Prabhu wrote:
> > 
> > pnv_init_idle_states discovers supported idle states from the
> > device tree and does the required initialization. Set power_save
> > function pointer only after this initialization is done
> > 
> > Reviewed-by: Gautham R. Shenoy 
> > Signed-off-by: Shreyas B. Prabhu 
> Acked-by: Benjamin Herrenschmidt 
> 
> Please merge that one as-is now, no need to wait for the rest, as
> otherwise pwoer9 crashes at boot. It doesn't need to wait for the
> rest of the series.

Acked-by: Michael Neuling 

For the same reason. Without this we need powersave=off on the cmdline on
POWER9.

Mikey

> 
> Cheers,
> Ben.
> 
> > 
> > ---
> > - No changes since v1
> > 
> >  arch/powerpc/platforms/powernv/idle.c  | 3 +++
> >  arch/powerpc/platforms/powernv/setup.c | 2 +-
> >  2 files changed, 4 insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/powerpc/platforms/powernv/idle.c
> > b/arch/powerpc/platforms/powernv/idle.c
> > index fcc8b68..fbb09fb 100644
> > --- a/arch/powerpc/platforms/powernv/idle.c
> > +++ b/arch/powerpc/platforms/powernv/idle.c
> > @@ -285,6 +285,9 @@ static int __init pnv_init_idle_states(void)
> >     }
> >  
> >     pnv_alloc_idle_core_states();
> > +
> > +   if (supported_cpuidle_states & OPAL_PM_NAP_ENABLED)
> > +   ppc_md.power_save = power7_idle;
> >  out_free:
> >     kfree(flags);
> >  out:
> > diff --git a/arch/powerpc/platforms/powernv/setup.c
> > b/arch/powerpc/platforms/powernv/setup.c
> > index ee6430b..8492bbb 100644
> > --- a/arch/powerpc/platforms/powernv/setup.c
> > +++ b/arch/powerpc/platforms/powernv/setup.c
> > @@ -315,7 +315,7 @@ define_machine(powernv) {
> >     .get_proc_freq  = pnv_get_proc_freq,
> >     .progress   = pnv_progress,
> >     .machine_shutdown   = pnv_shutdown,
> > -   .power_save = power7_idle,
> > +   .power_save = NULL,
> >     .calibrate_decr = generic_calibrate_decr,
> >  #ifdef CONFIG_KEXEC
> >     .kexec_cpu_down = pnv_kexec_cpu_down,

[PATCH 1/1] thermal: core: call thermal_zone_device_update() after mode update

[Eduardo Valentin]

Because several drivers do the following pattern:
.set_mode()
   ...
   local_data->mode = new_mode;
   thermal_zone_device_update(tz);

makes sense to simply do the thermal_zone_device_update()
in thermal core, after setting the new mode.

Also, this patch also remove deadlocks on drivers that
call thermal_zone_device_update() on .set_mode(),
as .set_mode()  is now called always with tz->lock held.

Cc: "Rafael J. Wysocki" 
Cc: Len Brown 
Cc: linux-a...@vger.kernel.org
Cc: "Lee, Chun-Yi" 
Cc: Darren Hart 
Cc: Zhang Rui 
Cc: Keerthy 
Cc: linux-kernel@vger.kernel.org
Cc: linux-o...@vger.kernel.org
Cc: platform-driver-...@vger.kernel.org
Cc: linux...@vger.kernel.org
Signed-off-by: Eduardo Valentin 
---
Rui, Keerthy,

I think this patch should take care of the introduced deadlock.

Let me know if solves on your end.

BR,

Eduardo
---

 drivers/acpi/thermal.c |  2 --
 drivers/platform/x86/acerhdf.c |  1 -
 drivers/thermal/imx_thermal.c  |  1 -
 drivers/thermal/of-thermal.c   |  8 ++---
 drivers/thermal/thermal_core.c | 41 +-
 drivers/thermal/thermal_sysfs.c|  1 +
 drivers/thermal/ti-soc-thermal/ti-thermal-common.c |  1 -
 7 files changed, 36 insertions(+), 19 deletions(-)

diff --git a/drivers/acpi/thermal.c b/drivers/acpi/thermal.c
index 82707f9..8582b88 100644
--- a/drivers/acpi/thermal.c
+++ b/drivers/acpi/thermal.c
@@ -519,8 +519,6 @@ static void acpi_thermal_check(void *data)
 
if (!tz->tz_enabled)
return;
-
-   thermal_zone_device_update(tz->thermal_zone);
 }
 
 /* sys I/F for generic thermal sysfs support */
diff --git a/drivers/platform/x86/acerhdf.c b/drivers/platform/x86/acerhdf.c
index 460fa67..aee33ba 100644
--- a/drivers/platform/x86/acerhdf.c
+++ b/drivers/platform/x86/acerhdf.c
@@ -405,7 +405,6 @@ static inline void acerhdf_enable_kernelmode(void)
kernelmode = 1;
 
thz_dev->polling_delay = interval*1000;
-   thermal_zone_device_update(thz_dev);
pr_notice("kernel mode fan control ON\n");
 }
 
diff --git a/drivers/thermal/imx_thermal.c b/drivers/thermal/imx_thermal.c
index c5547bd..a413eb6 100644
--- a/drivers/thermal/imx_thermal.c
+++ b/drivers/thermal/imx_thermal.c
@@ -246,7 +246,6 @@ static int imx_set_mode(struct thermal_zone_device *tz,
}
 
data->mode = mode;
-   thermal_zone_device_update(tz);
 
return 0;
 }
diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
index b8e509c..b44c102 100644
--- a/drivers/thermal/of-thermal.c
+++ b/drivers/thermal/of-thermal.c
@@ -181,9 +181,6 @@ static int of_thermal_set_emul_temp(struct 
thermal_zone_device *tz,
 {
struct __thermal_zone *data = tz->devdata;
 
-   if (!data->ops || !data->ops->set_emul_temp)
-   return -EINVAL;
-
return data->ops->set_emul_temp(data->sensor_data, temp);
 }
 
@@ -292,7 +289,6 @@ static int of_thermal_set_mode(struct thermal_zone_device 
*tz,
mutex_unlock(>lock);
 
data->mode = mode;
-   thermal_zone_device_update(tz);
 
return 0;
 }
@@ -427,7 +423,9 @@ thermal_zone_of_add_sensor(struct device_node *zone,
 
tzd->ops->get_temp = of_thermal_get_temp;
tzd->ops->get_trend = of_thermal_get_trend;
-   tzd->ops->set_emul_temp = of_thermal_set_emul_temp;
+   if (ops->set_emul_temp)
+   tzd->ops->set_emul_temp = of_thermal_set_emul_temp;
+
mutex_unlock(>lock);
 
return tzd;
diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 09da955..bb1ede7 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -323,6 +323,21 @@ static void handle_non_critical_trips(struct 
thermal_zone_device *tz,
   def_governor->throttle(tz, trip);
 }
 
+static void thermal_zone_update_stats(struct thermal_zone_device *tz,
+ int last_trip, int cur_trip)
+{
+   unsigned long long cur_time = get_jiffies_64();
+   struct thermal_zone_stats *cur, *last;
+
+   cur = tz->stats_table[cur_trip];
+   last = tz->stats_table[last_trip];
+
+   cur->counter++;
+   cur->last_time = cur_time;
+
+   last->time_in += cur_time - last->last_time;
+}
+
 static void thermal_tripped_notify(struct thermal_zone_device *tz,
   int trip, enum thermal_trip_type trip_type,
   int trip_temp)
@@ -333,6 +348,7 @@ static void thermal_tripped_notify(struct 
thermal_zone_device *tz,
NULL };
int upper_trip_hyst, upper_trip_temp, trip_hyst = 0;
int ret = 0;
+   int cur_trip, last_trip;
 
snprintf(tuv_name, sizeof(tuv_name), "THERMAL_ZONE=%s", tz->type);

[PATCH 1/1] thermal: core: call thermal_zone_device_update() after mode update

[Eduardo Valentin]

Because several drivers do the following pattern:
.set_mode()
   ...
   local_data->mode = new_mode;
   thermal_zone_device_update(tz);

makes sense to simply do the thermal_zone_device_update()
in thermal core, after setting the new mode.

Also, this patch also remove deadlocks on drivers that
call thermal_zone_device_update() on .set_mode(),
as .set_mode()  is now called always with tz->lock held.

Cc: "Rafael J. Wysocki" 
Cc: Len Brown 
Cc: linux-a...@vger.kernel.org
Cc: "Lee, Chun-Yi" 
Cc: Darren Hart 
Cc: Zhang Rui 
Cc: Keerthy 
Cc: linux-kernel@vger.kernel.org
Cc: linux-o...@vger.kernel.org
Cc: platform-driver-...@vger.kernel.org
Cc: linux...@vger.kernel.org
Signed-off-by: Eduardo Valentin 
---
Rui, Keerthy,

I think this patch should take care of the introduced deadlock.

Let me know if solves on your end.

BR,

Eduardo
---

 drivers/acpi/thermal.c |  2 --
 drivers/platform/x86/acerhdf.c |  1 -
 drivers/thermal/imx_thermal.c  |  1 -
 drivers/thermal/of-thermal.c   |  8 ++---
 drivers/thermal/thermal_core.c | 41 +-
 drivers/thermal/thermal_sysfs.c|  1 +
 drivers/thermal/ti-soc-thermal/ti-thermal-common.c |  1 -
 7 files changed, 36 insertions(+), 19 deletions(-)

diff --git a/drivers/acpi/thermal.c b/drivers/acpi/thermal.c
index 82707f9..8582b88 100644
--- a/drivers/acpi/thermal.c
+++ b/drivers/acpi/thermal.c
@@ -519,8 +519,6 @@ static void acpi_thermal_check(void *data)
 
if (!tz->tz_enabled)
return;
-
-   thermal_zone_device_update(tz->thermal_zone);
 }
 
 /* sys I/F for generic thermal sysfs support */
diff --git a/drivers/platform/x86/acerhdf.c b/drivers/platform/x86/acerhdf.c
index 460fa67..aee33ba 100644
--- a/drivers/platform/x86/acerhdf.c
+++ b/drivers/platform/x86/acerhdf.c
@@ -405,7 +405,6 @@ static inline void acerhdf_enable_kernelmode(void)
kernelmode = 1;
 
thz_dev->polling_delay = interval*1000;
-   thermal_zone_device_update(thz_dev);
pr_notice("kernel mode fan control ON\n");
 }
 
diff --git a/drivers/thermal/imx_thermal.c b/drivers/thermal/imx_thermal.c
index c5547bd..a413eb6 100644
--- a/drivers/thermal/imx_thermal.c
+++ b/drivers/thermal/imx_thermal.c
@@ -246,7 +246,6 @@ static int imx_set_mode(struct thermal_zone_device *tz,
}
 
data->mode = mode;
-   thermal_zone_device_update(tz);
 
return 0;
 }
diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
index b8e509c..b44c102 100644
--- a/drivers/thermal/of-thermal.c
+++ b/drivers/thermal/of-thermal.c
@@ -181,9 +181,6 @@ static int of_thermal_set_emul_temp(struct 
thermal_zone_device *tz,
 {
struct __thermal_zone *data = tz->devdata;
 
-   if (!data->ops || !data->ops->set_emul_temp)
-   return -EINVAL;
-
return data->ops->set_emul_temp(data->sensor_data, temp);
 }
 
@@ -292,7 +289,6 @@ static int of_thermal_set_mode(struct thermal_zone_device 
*tz,
mutex_unlock(>lock);
 
data->mode = mode;
-   thermal_zone_device_update(tz);
 
return 0;
 }
@@ -427,7 +423,9 @@ thermal_zone_of_add_sensor(struct device_node *zone,
 
tzd->ops->get_temp = of_thermal_get_temp;
tzd->ops->get_trend = of_thermal_get_trend;
-   tzd->ops->set_emul_temp = of_thermal_set_emul_temp;
+   if (ops->set_emul_temp)
+   tzd->ops->set_emul_temp = of_thermal_set_emul_temp;
+
mutex_unlock(>lock);
 
return tzd;
diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 09da955..bb1ede7 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -323,6 +323,21 @@ static void handle_non_critical_trips(struct 
thermal_zone_device *tz,
   def_governor->throttle(tz, trip);
 }
 
+static void thermal_zone_update_stats(struct thermal_zone_device *tz,
+ int last_trip, int cur_trip)
+{
+   unsigned long long cur_time = get_jiffies_64();
+   struct thermal_zone_stats *cur, *last;
+
+   cur = tz->stats_table[cur_trip];
+   last = tz->stats_table[last_trip];
+
+   cur->counter++;
+   cur->last_time = cur_time;
+
+   last->time_in += cur_time - last->last_time;
+}
+
 static void thermal_tripped_notify(struct thermal_zone_device *tz,
   int trip, enum thermal_trip_type trip_type,
   int trip_temp)
@@ -333,6 +348,7 @@ static void thermal_tripped_notify(struct 
thermal_zone_device *tz,
NULL };
int upper_trip_hyst, upper_trip_temp, trip_hyst = 0;
int ret = 0;
+   int cur_trip, last_trip;
 
snprintf(tuv_name, sizeof(tuv_name), "THERMAL_ZONE=%s", tz->type);
snprintf(tuv_temp, sizeof(tuv_temp), "TEMP=%d", tz->temperature);
@@ -344,8 +360,11 @@ static void thermal_tripped_notify(struct 

Re: [PATCH 1/5] mfd: pm8921: Add support for pm8018

[Bjorn Andersson]

On Fri 17 Jun 03:22 PDT 2016, Neil Armstrong wrote:

> In order to support the Qualcomm MDM9615 PMIC, add support for the
> pm8018 in pm8921 mfd driver.
> 
> Signed-off-by: Neil Armstrong 

Reviewed-by: Bjorn Andersson 

Regards,
Bjorn

Re: [PATCH 1/5] mfd: pm8921: Add support for pm8018

[Bjorn Andersson]

On Fri 17 Jun 03:22 PDT 2016, Neil Armstrong wrote:

> In order to support the Qualcomm MDM9615 PMIC, add support for the
> pm8018 in pm8921 mfd driver.
> 
> Signed-off-by: Neil Armstrong 

Reviewed-by: Bjorn Andersson 

Regards,
Bjorn

Re: [PATCH v2 0/2] Correct iTCO Watchdog for Apollo Lake

[Yong, Jonathan]

On 06/17/2016 08:36, Yong, Jonathan wrote:

These patches fix the iTCO watchdog for Apollo Lake.
I changed the watchdog memory io to only use 4 bytes rather
the whole region, I'm not sure if that is the correct way.

The previous 0x30h offset in intel_pmc_ipc.c was for based
on the earlier BXT-M platform. Apollo Lake has it at 0x40h.

Let me know if the patches need changes.
Please CC me as I am not subscribed, thanks.

* Resent, typo in linux-kernel email address

Changes since v1:
* Watchdog NO_REBOOT bit off-by-one corrected.

Yong, Jonathan (2):
   watchdog: iTCO-wdt handle 5th variation for Apollo Lake
   x86: Fix Apollo Lake Watchdog address in PMC driver

  drivers/platform/x86/intel_pmc_ipc.c | 10 ++
  drivers/watchdog/iTCO_wdt.c  |  2 ++
  2 files changed, 8 insertions(+), 4 deletions(-)



Ping.

Re: [PATCH v2 0/2] Correct iTCO Watchdog for Apollo Lake

[Yong, Jonathan]

On 06/17/2016 08:36, Yong, Jonathan wrote:

These patches fix the iTCO watchdog for Apollo Lake.
I changed the watchdog memory io to only use 4 bytes rather
the whole region, I'm not sure if that is the correct way.

The previous 0x30h offset in intel_pmc_ipc.c was for based
on the earlier BXT-M platform. Apollo Lake has it at 0x40h.

Let me know if the patches need changes.
Please CC me as I am not subscribed, thanks.

* Resent, typo in linux-kernel email address

Changes since v1:
* Watchdog NO_REBOOT bit off-by-one corrected.

Yong, Jonathan (2):
   watchdog: iTCO-wdt handle 5th variation for Apollo Lake
   x86: Fix Apollo Lake Watchdog address in PMC driver

  drivers/platform/x86/intel_pmc_ipc.c | 10 ++
  drivers/watchdog/iTCO_wdt.c  |  2 ++
  2 files changed, 8 insertions(+), 4 deletions(-)



Ping.

Re: [PATCH v10 06/22] IB/hns: Add initial cmd operation

[Leon Romanovsky]

On Tue, Jun 21, 2016 at 09:01:57PM +0800, Wei Hu (Xavier) wrote:
> 
> 
> On 2016/6/21 19:28, Leon Romanovsky wrote:
> >On Tue, Jun 21, 2016 at 06:50:51PM +0800, Wei Hu (Xavier) wrote:
> >>
> >>On 2016/6/20 21:33, Leon Romanovsky wrote:
> >>>On Thu, Jun 16, 2016 at 10:35:14PM +0800, Lijun Ou wrote:
> This patch added the operation for cmd, and added some functions
> for initializing eq table and selecting cmd mode.
> 
> Signed-off-by: Wei Hu 
> Signed-off-by: Nenglong Zhao 
> Signed-off-by: Lijun Ou 
> ---
> PATCH v9/v8/v7/v6:
> - No change over the PATCH v5
> 
> PATCH v5:
> - The initial patch which was redesigned based on the second patch
>    in PATCH v4
> ---
> >>><...>
> >>>
> +#define CMD_MAX_NUM  32
> +
> +int hns_roce_cmd_init(struct hns_roce_dev *hr_dev)
> +{
> + struct device *dev = _dev->pdev->dev;
> +
> + mutex_init(_dev->cmd.hcr_mutex);
> + sema_init(_dev->cmd.poll_sem, 1);
> + hr_dev->cmd.use_events = 0;
> + hr_dev->cmd.toggle = 1;
> + hr_dev->cmd.max_cmds = CMD_MAX_NUM;
> >>><...>
> >>>
> + for (hr_cmd->token_mask = 1; hr_cmd->token_mask < hr_cmd->max_cmds;
> +  hr_cmd->token_mask <<= 1)
> + ;
> + --hr_cmd->token_mask;
> >>>It doesn't look that you dynamically change max_cmds supported.
> >>>Why do you need to calculate token_mask dynamically?
> >>Hi, Leon
> >>
> >> 1. The four lines above are in the function named
> >>hns_roce_cmd_use_events.
> >>  and now this function is only called once in hns_roce_probe.
> >> 2. In hns_roce_cmd_use_events,
> >> we use these 4 lines to achieve the value of hr_cmd->token_mask
> >>according to hr_cmd->max_cmds dynamically,
> >> then we only define one marco for hr_cmd->max_cmds as below:
> >>
> >>#define CMD_MAX_NUM 32
> >>
> >>And it looks more flexible.
> >It is called over engineering.
> >I would recommend to you to remove it.
> >
> >We don't need over complicated code which is executed
> >once with need to maintain with zero benefit.
> >
> >The other places need such simplification too.
> Hi, Leon
> 
> We will modify this place as below:
> In hns_roce_hw_v1.c(for hip06 soc) file:
> 
> void hns_roce_v1_profile(struct hns_roce_dev *hr_dev)
> {
> 
> caps->max_cmds = 32;
> 
> }
> 
> In hns_roce_cmd.c file:
> 
> int hns_roce_cmd_init(struct hns_roce_dev *hr_dev)
> {
>
>hr_dev->cmd.max_cmds = hr_dev->caps->max_cmds;
>   
>   }
> 
>Can you give more suggestions?

I would be happy to do it if I had enough time to review this code.

General suggestion will be to ask yourself, if value is going to be
changed during the runtime. In case the answer is no, there is no room
to additional logic which translate constant to different value which
will be other constant.

You should do it across all the patchset.

So, in this specific case, the proposed change is not enough, you are
not solving an issue, but hiding it.

Thanks

> 
> 
> Regards
> Wei Hu
> >>Regards
> >>Wei Hu
> >>
> >>
> >>
> 
> 


signature.asc
Description: Digital signature

Re: [PATCH v10 06/22] IB/hns: Add initial cmd operation

[Leon Romanovsky]

On Tue, Jun 21, 2016 at 09:01:57PM +0800, Wei Hu (Xavier) wrote:
> 
> 
> On 2016/6/21 19:28, Leon Romanovsky wrote:
> >On Tue, Jun 21, 2016 at 06:50:51PM +0800, Wei Hu (Xavier) wrote:
> >>
> >>On 2016/6/20 21:33, Leon Romanovsky wrote:
> >>>On Thu, Jun 16, 2016 at 10:35:14PM +0800, Lijun Ou wrote:
> This patch added the operation for cmd, and added some functions
> for initializing eq table and selecting cmd mode.
> 
> Signed-off-by: Wei Hu 
> Signed-off-by: Nenglong Zhao 
> Signed-off-by: Lijun Ou 
> ---
> PATCH v9/v8/v7/v6:
> - No change over the PATCH v5
> 
> PATCH v5:
> - The initial patch which was redesigned based on the second patch
>    in PATCH v4
> ---
> >>><...>
> >>>
> +#define CMD_MAX_NUM  32
> +
> +int hns_roce_cmd_init(struct hns_roce_dev *hr_dev)
> +{
> + struct device *dev = _dev->pdev->dev;
> +
> + mutex_init(_dev->cmd.hcr_mutex);
> + sema_init(_dev->cmd.poll_sem, 1);
> + hr_dev->cmd.use_events = 0;
> + hr_dev->cmd.toggle = 1;
> + hr_dev->cmd.max_cmds = CMD_MAX_NUM;
> >>><...>
> >>>
> + for (hr_cmd->token_mask = 1; hr_cmd->token_mask < hr_cmd->max_cmds;
> +  hr_cmd->token_mask <<= 1)
> + ;
> + --hr_cmd->token_mask;
> >>>It doesn't look that you dynamically change max_cmds supported.
> >>>Why do you need to calculate token_mask dynamically?
> >>Hi, Leon
> >>
> >> 1. The four lines above are in the function named
> >>hns_roce_cmd_use_events.
> >>  and now this function is only called once in hns_roce_probe.
> >> 2. In hns_roce_cmd_use_events,
> >> we use these 4 lines to achieve the value of hr_cmd->token_mask
> >>according to hr_cmd->max_cmds dynamically,
> >> then we only define one marco for hr_cmd->max_cmds as below:
> >>
> >>#define CMD_MAX_NUM 32
> >>
> >>And it looks more flexible.
> >It is called over engineering.
> >I would recommend to you to remove it.
> >
> >We don't need over complicated code which is executed
> >once with need to maintain with zero benefit.
> >
> >The other places need such simplification too.
> Hi, Leon
> 
> We will modify this place as below:
> In hns_roce_hw_v1.c(for hip06 soc) file:
> 
> void hns_roce_v1_profile(struct hns_roce_dev *hr_dev)
> {
> 
> caps->max_cmds = 32;
> 
> }
> 
> In hns_roce_cmd.c file:
> 
> int hns_roce_cmd_init(struct hns_roce_dev *hr_dev)
> {
>
>hr_dev->cmd.max_cmds = hr_dev->caps->max_cmds;
>   
>   }
> 
>Can you give more suggestions?

I would be happy to do it if I had enough time to review this code.

General suggestion will be to ask yourself, if value is going to be
changed during the runtime. In case the answer is no, there is no room
to additional logic which translate constant to different value which
will be other constant.

You should do it across all the patchset.

So, in this specific case, the proposed change is not enough, you are
not solving an issue, but hiding it.

Thanks

> 
> 
> Regards
> Wei Hu
> >>Regards
> >>Wei Hu
> >>
> >>
> >>
> 
> 


signature.asc
Description: Digital signature

linux-next: manual merge of the akpm-current tree with the arm64 tree

[Stephen Rothwell]

Hi Andrew,

Today's linux-next merge of the akpm-current tree got a conflict in:

  arch/arm64/mm/dma-mapping.c

between commit:

  b67a8b29df7e ("arm64: mm: only initialize swiotlb when necessary")

from the arm64 tree and commit:

  29af59a63ef1 ("arm64: dma-mapping: constify attrs passed to internal 
functions")

from the akpm-current tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/arm64/mm/dma-mapping.c
index 46a4157adc17,0ef620a34c4e..
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@@ -30,9 -29,7 +30,9 @@@
  
  #include 
  
 +static int swiotlb __read_mostly;
 +
- static pgprot_t __get_dma_pgprot(struct dma_attrs *attrs, pgprot_t prot,
+ static pgprot_t __get_dma_pgprot(const struct dma_attrs *attrs, pgprot_t prot,
 bool coherent)
  {
if (!coherent || dma_get_attr(DMA_ATTR_WRITE_COMBINE, attrs))

linux-next: manual merge of the akpm-current tree with the arm64 tree

[Stephen Rothwell]

Hi Andrew,

Today's linux-next merge of the akpm-current tree got a conflict in:

  arch/arm64/mm/dma-mapping.c

between commit:

  b67a8b29df7e ("arm64: mm: only initialize swiotlb when necessary")

from the arm64 tree and commit:

  29af59a63ef1 ("arm64: dma-mapping: constify attrs passed to internal 
functions")

from the akpm-current tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/arm64/mm/dma-mapping.c
index 46a4157adc17,0ef620a34c4e..
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@@ -30,9 -29,7 +30,9 @@@
  
  #include 
  
 +static int swiotlb __read_mostly;
 +
- static pgprot_t __get_dma_pgprot(struct dma_attrs *attrs, pgprot_t prot,
+ static pgprot_t __get_dma_pgprot(const struct dma_attrs *attrs, pgprot_t prot,
 bool coherent)
  {
if (!coherent || dma_get_attr(DMA_ATTR_WRITE_COMBINE, attrs))

Re: [PATCH v2 1/8] arm64: dts: db820c: add basic board support

[Bjorn Andersson]

On Tue 21 Jun 10:22 PDT 2016, Srinivas Kandagatla wrote:

[..]
> diff --git a/arch/arm64/boot/dts/qcom/apq8096-db820c.dts 
> b/arch/arm64/boot/dts/qcom/apq8096-db820c.dts
[..]
> +
> +/ {
> + model = "Qualcomm Technologies, Inc. DB820c";
> + compatible = "qcom,apq8096-sbc";

I'm still not buying the concept of this being the one and only
single-board-computer.

If this compatible fully and exclusively identifies this particular
board then dtbTool should be updated to follow the product name
"qcom,apq8096-db820c". If on the other hand this identifies a class of
single-board-computers, then the compatible should list both
"qcom,apq8096-dtb820c" and "qcom,apq8096-sbc".



Further more, the ePAPR defines this property as:
"Specifies a list of platform architectures with which this platform is
compatible. This property can be used by operating systems in selecting
platform specific code."

So I think we should follow the common pattern of having the least
significant entry being "qcom,apq8096".

> +};

Regards,
Bjorn

Re: [PATCH v2 1/8] arm64: dts: db820c: add basic board support

[Bjorn Andersson]

On Tue 21 Jun 10:22 PDT 2016, Srinivas Kandagatla wrote:

[..]
> diff --git a/arch/arm64/boot/dts/qcom/apq8096-db820c.dts 
> b/arch/arm64/boot/dts/qcom/apq8096-db820c.dts
[..]
> +
> +/ {
> + model = "Qualcomm Technologies, Inc. DB820c";
> + compatible = "qcom,apq8096-sbc";

I'm still not buying the concept of this being the one and only
single-board-computer.

If this compatible fully and exclusively identifies this particular
board then dtbTool should be updated to follow the product name
"qcom,apq8096-db820c". If on the other hand this identifies a class of
single-board-computers, then the compatible should list both
"qcom,apq8096-dtb820c" and "qcom,apq8096-sbc".



Further more, the ePAPR defines this property as:
"Specifies a list of platform architectures with which this platform is
compatible. This property can be used by operating systems in selecting
platform specific code."

So I think we should follow the common pattern of having the least
significant entry being "qcom,apq8096".

> +};

Regards,
Bjorn

Re: [PATCH 3/3] staging: lowmemorykiller: select the task with maximum rss to kill

[Ganesh Mahendran]

Hi, David:

On Tue, Jun 21, 2016 at 01:14:36PM -0700, David Rientjes wrote:
> On Tue, 21 Jun 2016, Ganesh Mahendran wrote:
> 
> > Current task selecting logic in LMK does not fully aware of the memory
> > pressure. It may select the task with maximum score adj, but with
> > least tasksize.
> > 
> > For example, if min_score_adj is 200, and there are 2 tasks in system:
> >task a: score adj 500, tasksize 200M
> >task b: score adj 1000, tasksize 1M
> > Current LMK logic will select *task b*. But now the system already have
> > much memory pressure.
> > 
> > We should select the task with maximum task from all the tasks which
> > score adj >= min_score_adj.
> > 
> 
> Unfortunately, I'm not sure that we can get away with this although I 
> agree that it is a better result (kill a large process, avoid lowmem or 
> oom for longer).

Yes, from our testing with this patch applied, system works more smoothly,
and user have better experience.

> 
> It changes the kill order for systems that have already fine-tuned their 
> oom_score_adj settings and can regress because of this change.  If systems 
> really want task b to be killed above, this breaks and they have no 
> immediate way of fixing it.

I think the processes with score_adj >= min_score_adj are all acceptable
if we kill them. In android products, LMK does the main job to free memory
when system is hard to shrink file/anon pages. If LMK does not free enough 
memory,
the system will be very slow before OOM is triggered. During this period, user 
will
have bad experience.

So LMK need to work effectivly to let system running smoothly, as user 
experience
is very important for android system.

Thanks.

Re: [PATCH 3/3] staging: lowmemorykiller: select the task with maximum rss to kill

[Ganesh Mahendran]

Hi, David:

On Tue, Jun 21, 2016 at 01:14:36PM -0700, David Rientjes wrote:
> On Tue, 21 Jun 2016, Ganesh Mahendran wrote:
> 
> > Current task selecting logic in LMK does not fully aware of the memory
> > pressure. It may select the task with maximum score adj, but with
> > least tasksize.
> > 
> > For example, if min_score_adj is 200, and there are 2 tasks in system:
> >task a: score adj 500, tasksize 200M
> >task b: score adj 1000, tasksize 1M
> > Current LMK logic will select *task b*. But now the system already have
> > much memory pressure.
> > 
> > We should select the task with maximum task from all the tasks which
> > score adj >= min_score_adj.
> > 
> 
> Unfortunately, I'm not sure that we can get away with this although I 
> agree that it is a better result (kill a large process, avoid lowmem or 
> oom for longer).

Yes, from our testing with this patch applied, system works more smoothly,
and user have better experience.

> 
> It changes the kill order for systems that have already fine-tuned their 
> oom_score_adj settings and can regress because of this change.  If systems 
> really want task b to be killed above, this breaks and they have no 
> immediate way of fixing it.

I think the processes with score_adj >= min_score_adj are all acceptable
if we kill them. In android products, LMK does the main job to free memory
when system is hard to shrink file/anon pages. If LMK does not free enough 
memory,
the system will be very slow before OOM is triggered. During this period, user 
will
have bad experience.

So LMK need to work effectivly to let system running smoothly, as user 
experience
is very important for android system.

Thanks.

Re: [PATCH v13 01/16] PCI: Let pci_mmap_page_range() take resource address

[Yinghai Lu]

On Sat, Jun 18, 2016 at 5:17 AM, Bjorn Helgaas  wrote:
> On Fri, Jun 17, 2016 at 07:24:46PM -0700, Yinghai Lu wrote:
>> In 8c05cd08a7 ("PCI: fix offset check for sysfs mmapped files"), try
>> to check exposed value with resource start/end in proc mmap path.
>>
>> |start = vma->vm_pgoff;
>> |size = ((pci_resource_len(pdev, resno) - 1) >> PAGE_SHIFT) + 1;
>> |pci_start = (mmap_api == PCI_MMAP_PROCFS) ?
>> |pci_resource_start(pdev, resno) >> PAGE_SHIFT : 0;
>> |if (start >= pci_start && start < pci_start + size &&
>> |start + nr <= pci_start + size)
>>
>> That breaks sparc that exposed value is BAR value, and need to be offseted
>> to resource address.
>
> I asked this same question of the v12 patch, but I don't think you
> answered it:
>
> I'm not quite sure what you're saying here.  Are you saying that sparc
> is currently broken, and this patch fixes it?  If so, what exactly is
> broken?  Can you give a small example of an mmap that is currently
> broken?

Yes, for sparc that path (proc mmap) is broken, but only according to
code checking.

The reason for the problem is not discovered is that seem all users
(other than x86) are not
use proc_mmap ?

vma->vm_pgoff is that code segment is User/BAR value >> PAGE_SHIFT.
pci_start is resource->start >> PAGE_SHIFT.

For sparc, resource start is different from BAR start aka pci bus address.
pci bus address add offset to be the resource start.

Thanks

Yinghai

Re: [PATCH v13 01/16] PCI: Let pci_mmap_page_range() take resource address

[Yinghai Lu]

On Sat, Jun 18, 2016 at 5:17 AM, Bjorn Helgaas  wrote:
> On Fri, Jun 17, 2016 at 07:24:46PM -0700, Yinghai Lu wrote:
>> In 8c05cd08a7 ("PCI: fix offset check for sysfs mmapped files"), try
>> to check exposed value with resource start/end in proc mmap path.
>>
>> |start = vma->vm_pgoff;
>> |size = ((pci_resource_len(pdev, resno) - 1) >> PAGE_SHIFT) + 1;
>> |pci_start = (mmap_api == PCI_MMAP_PROCFS) ?
>> |pci_resource_start(pdev, resno) >> PAGE_SHIFT : 0;
>> |if (start >= pci_start && start < pci_start + size &&
>> |start + nr <= pci_start + size)
>>
>> That breaks sparc that exposed value is BAR value, and need to be offseted
>> to resource address.
>
> I asked this same question of the v12 patch, but I don't think you
> answered it:
>
> I'm not quite sure what you're saying here.  Are you saying that sparc
> is currently broken, and this patch fixes it?  If so, what exactly is
> broken?  Can you give a small example of an mmap that is currently
> broken?

Yes, for sparc that path (proc mmap) is broken, but only according to
code checking.

The reason for the problem is not discovered is that seem all users
(other than x86) are not
use proc_mmap ?

vma->vm_pgoff is that code segment is User/BAR value >> PAGE_SHIFT.
pci_start is resource->start >> PAGE_SHIFT.

For sparc, resource start is different from BAR start aka pci bus address.
pci bus address add offset to be the resource start.

Thanks

Yinghai

Re: [RFC PATCH v2 1/9] mailbox: Add Amlogic Meson Message-Handling-Unit

[Jassi Brar]

On Tue, Jun 21, 2016 at 3:32 PM, Neil Armstrong  wrote:
> Add Amlogic Meson SoCs Message-Handling-Unit as mailbox controller
> with 2 independent channels/links to communicate with a remote processor.
>
> Signed-off-by: Neil Armstrong 

.

> +++ b/drivers/mailbox/meson_mhu.c
> @@ -0,0 +1,199 @@
> +/*
> + * Copyright (C) 2016 BayLibre SAS.
> + * Author: Neil Armstrong 
> + * Heavily based on meson_mhu.c from :
> + * Copyright (C) 2013-2015 Fujitsu Semiconductor Ltd.
> + * Copyright (C) 2015 Linaro Ltd.
> + * Author: Jassi Brar 

.
> +
> +#define INTR_SET_OFS   0x0
> +#define INTR_STAT_OFS  0x4
> +#define INTR_CLR_OFS   0x8
> +
> +#define MHU_LP_OFFSET  0x10
> +#define MHU_HP_OFFSET  0x1c
> +
> +#define TX_REG_OFFSET  0x24
> +
It seems only some register offsets have changed from arm_mhu. So
maybe just adapt the arm_mhu driver to look for IP variant and assign
corresponding offsets to set,stat,clr registers.

Cheers.

Re: [RFC PATCH v2 1/9] mailbox: Add Amlogic Meson Message-Handling-Unit

[Jassi Brar]

On Tue, Jun 21, 2016 at 3:32 PM, Neil Armstrong  wrote:
> Add Amlogic Meson SoCs Message-Handling-Unit as mailbox controller
> with 2 independent channels/links to communicate with a remote processor.
>
> Signed-off-by: Neil Armstrong 

.

> +++ b/drivers/mailbox/meson_mhu.c
> @@ -0,0 +1,199 @@
> +/*
> + * Copyright (C) 2016 BayLibre SAS.
> + * Author: Neil Armstrong 
> + * Heavily based on meson_mhu.c from :
> + * Copyright (C) 2013-2015 Fujitsu Semiconductor Ltd.
> + * Copyright (C) 2015 Linaro Ltd.
> + * Author: Jassi Brar 

.
> +
> +#define INTR_SET_OFS   0x0
> +#define INTR_STAT_OFS  0x4
> +#define INTR_CLR_OFS   0x8
> +
> +#define MHU_LP_OFFSET  0x10
> +#define MHU_HP_OFFSET  0x1c
> +
> +#define TX_REG_OFFSET  0x24
> +
It seems only some register offsets have changed from arm_mhu. So
maybe just adapt the arm_mhu driver to look for IP variant and assign
corresponding offsets to set,stat,clr registers.

Cheers.

Re: [PATCH v2 6/6] x86: Fix thread_saved_pc()

[Brian Gerst]

On Mon, Jun 20, 2016 at 12:01 PM, Josh Poimboeuf  wrote:
> On Sat, Jun 18, 2016 at 04:56:18PM -0400, Brian Gerst wrote:
>> thread_saved_pc() was using a completely bogus method to get the return
>> address.  Since switch_to() was previously inlined, there was no sane way
>> to know where on the stack the return address was stored.  Now with the
>> frame of a sleeping thread well defined, this can be implemented correctly.
>>
>> Signed-off-by: Brian Gerst 
>> ---
>>  arch/x86/include/asm/processor.h | 10 ++
>>  arch/x86/kernel/process.c| 10 ++
>>  arch/x86/kernel/process_32.c |  8 
>>  3 files changed, 12 insertions(+), 16 deletions(-)
>>
>> diff --git a/arch/x86/include/asm/processor.h 
>> b/arch/x86/include/asm/processor.h
>> index 1e7d634..413f4f1 100644
>> --- a/arch/x86/include/asm/processor.h
>> +++ b/arch/x86/include/asm/processor.h
>> @@ -716,8 +716,6 @@ static inline void spin_lock_prefetch(const void *x)
>>   .io_bitmap_ptr  = NULL,   \
>>  }
>>
>> -extern unsigned long thread_saved_pc(struct task_struct *tsk);
>> -
>>  /*
>>   * TOP_OF_KERNEL_STACK_PADDING reserves 8 bytes on top of the ring0 stack.
>>   * This is necessary to guarantee that the entire "struct pt_regs"
>> @@ -767,17 +765,13 @@ extern unsigned long thread_saved_pc(struct 
>> task_struct *tsk);
>>   .sp0 = TOP_OF_INIT_STACK \
>>  }
>>
>> -/*
>> - * Return saved PC of a blocked thread.
>> - * What is this good for? it will be always the scheduler or ret_from_fork.
>> - */
>> -#define thread_saved_pc(t)   READ_ONCE_NOCHECK(*(unsigned long 
>> *)((t)->thread.sp - 8))
>> -
>>  #define task_pt_regs(tsk)((struct pt_regs *)(tsk)->thread.sp0 - 1)
>>  extern unsigned long KSTK_ESP(struct task_struct *task);
>>
>>  #endif /* CONFIG_X86_64 */
>>
>> +extern unsigned long thread_saved_pc(struct task_struct *tsk);
>> +
>>  extern void start_thread(struct pt_regs *regs, unsigned long new_ip,
>>  unsigned long new_sp);
>>
>> diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
>> index 00ebab0..db458c4 100644
>> --- a/arch/x86/kernel/process.c
>> +++ b/arch/x86/kernel/process.c
>> @@ -513,6 +513,16 @@ unsigned long arch_randomize_brk(struct mm_struct *mm)
>>  }
>>
>>  /*
>> + * Return saved PC of a blocked thread.
>> + */
>> +unsigned long thread_saved_pc(struct task_struct *tsk)
>> +{
>> + struct inactive_task_frame *frame =
>> + (struct inactive_task_frame *) READ_ONCE(tsk->thread.sp);
>> + return READ_ONCE_NOCHECK(frame->ret_addr);
>> +}
>> +
>> +/*
>
> I would agree with the above (removed) comment:
>
>   "What is this good for?  it will be always the scheduler or ret_from_fork."
>
> And I'd guess the same is true for all the arches which have to
> implement it.  Maybe this function (and its single call site in
> sched_show_task()) should just be removed altogether?

I didn't really want to stray down that path with this series.  This
just makes it functional again.  the usefulness is still open for
debate.

--
Brian Gerst

Re: [PATCH v2 6/6] x86: Fix thread_saved_pc()

[Brian Gerst]

On Mon, Jun 20, 2016 at 12:01 PM, Josh Poimboeuf  wrote:
> On Sat, Jun 18, 2016 at 04:56:18PM -0400, Brian Gerst wrote:
>> thread_saved_pc() was using a completely bogus method to get the return
>> address.  Since switch_to() was previously inlined, there was no sane way
>> to know where on the stack the return address was stored.  Now with the
>> frame of a sleeping thread well defined, this can be implemented correctly.
>>
>> Signed-off-by: Brian Gerst 
>> ---
>>  arch/x86/include/asm/processor.h | 10 ++
>>  arch/x86/kernel/process.c| 10 ++
>>  arch/x86/kernel/process_32.c |  8 
>>  3 files changed, 12 insertions(+), 16 deletions(-)
>>
>> diff --git a/arch/x86/include/asm/processor.h 
>> b/arch/x86/include/asm/processor.h
>> index 1e7d634..413f4f1 100644
>> --- a/arch/x86/include/asm/processor.h
>> +++ b/arch/x86/include/asm/processor.h
>> @@ -716,8 +716,6 @@ static inline void spin_lock_prefetch(const void *x)
>>   .io_bitmap_ptr  = NULL,   \
>>  }
>>
>> -extern unsigned long thread_saved_pc(struct task_struct *tsk);
>> -
>>  /*
>>   * TOP_OF_KERNEL_STACK_PADDING reserves 8 bytes on top of the ring0 stack.
>>   * This is necessary to guarantee that the entire "struct pt_regs"
>> @@ -767,17 +765,13 @@ extern unsigned long thread_saved_pc(struct 
>> task_struct *tsk);
>>   .sp0 = TOP_OF_INIT_STACK \
>>  }
>>
>> -/*
>> - * Return saved PC of a blocked thread.
>> - * What is this good for? it will be always the scheduler or ret_from_fork.
>> - */
>> -#define thread_saved_pc(t)   READ_ONCE_NOCHECK(*(unsigned long 
>> *)((t)->thread.sp - 8))
>> -
>>  #define task_pt_regs(tsk)((struct pt_regs *)(tsk)->thread.sp0 - 1)
>>  extern unsigned long KSTK_ESP(struct task_struct *task);
>>
>>  #endif /* CONFIG_X86_64 */
>>
>> +extern unsigned long thread_saved_pc(struct task_struct *tsk);
>> +
>>  extern void start_thread(struct pt_regs *regs, unsigned long new_ip,
>>  unsigned long new_sp);
>>
>> diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
>> index 00ebab0..db458c4 100644
>> --- a/arch/x86/kernel/process.c
>> +++ b/arch/x86/kernel/process.c
>> @@ -513,6 +513,16 @@ unsigned long arch_randomize_brk(struct mm_struct *mm)
>>  }
>>
>>  /*
>> + * Return saved PC of a blocked thread.
>> + */
>> +unsigned long thread_saved_pc(struct task_struct *tsk)
>> +{
>> + struct inactive_task_frame *frame =
>> + (struct inactive_task_frame *) READ_ONCE(tsk->thread.sp);
>> + return READ_ONCE_NOCHECK(frame->ret_addr);
>> +}
>> +
>> +/*
>
> I would agree with the above (removed) comment:
>
>   "What is this good for?  it will be always the scheduler or ret_from_fork."
>
> And I'd guess the same is true for all the arches which have to
> implement it.  Maybe this function (and its single call site in
> sched_show_task()) should just be removed altogether?

I didn't really want to stray down that path with this series.  This
just makes it functional again.  the usefulness is still open for
debate.

--
Brian Gerst

Re: [PATCH v3 2/8] mfd: ac100: Add device tree bindings for X-Powers AC100 codec/RTC combo IC

[Chen-Yu Tsai]

On Tue, Jun 21, 2016 at 9:14 PM, Rob Herring  wrote:
> On Mon, Jun 20, 2016 at 10:52:12AM +0800, Chen-Yu Tsai wrote:
>> Signed-off-by: Chen-Yu Tsai 
>> ---
>> Changes since v2:
>>
>>   - Fix interrupt line for ac100_codec in provided example.
>>
>> ---
>>  Documentation/devicetree/bindings/mfd/ac100.txt | 42 
>> +
>>  1 file changed, 42 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/mfd/ac100.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mfd/ac100.txt 
>> b/Documentation/devicetree/bindings/mfd/ac100.txt
>> new file mode 100644
>> index ..a793954bb952
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mfd/ac100.txt
>> @@ -0,0 +1,42 @@
>> +X-Powers AC100 Codec/RTC IC device tree bindings
>> +
>> +AC100 is a audio codec and RTC subsystem combo IC. The 2 parts are
>> +separated, including power supplies and interrupt lines, but share
>> +a common register address space and host interface.
>> +
>> +Required properties:
>> +- compatible: "x-powers,ac100"
>> +- reg: The I2C slave address or RSB hardware address for the chip
>> +- sub-nodes:
>> +  - codec
>> +- compatible: "x-powers,ac100-codec"
>> +- interrupt-parent: The parent interrupt controller
>> +- interrupts: SoC NMI / GPIO interrupt connected to the IRQ_AUDIO pin
>> +  - rtc
>> +- compatible: "x-powers,ac100-rtc"
>> +- interrupt-parent: The parent interrupt controller
>> +- interrupts: SoC NMI / GPIO interrupt connected to the IRQ_RTC pin
>> +- #clock-cells: shall be 1
>> +- clock-output-names: "cko1_rtc", "cko2_rtc", "cko3_rtc"
>> +- see clock/clock-bindings.txt for common clock bindings
>> +
>> +Example:
>> +
>> +ac100: codec@e89 {
>> + compatible = "x-powers,ac100";
>> + reg = <0xe89>;
>> +
>> + ac100_codec {
>
> Use generic node names and no underscores:
>
> codec {

Right. I intended to add them as labels, not change the node names.

Thanks
ChenYu

>
>> + compatible = "x-powers,ac100-codec";
>> + interrupt-parent = <_pio>;
>> + interrupts = <0 9 IRQ_TYPE_LEVEL_LOW>; /* PL9 */
>> + };
>> +
>> + ac100_rtc {
>
> rtc {
>
>> + compatible = "x-powers,ac100-rtc";
>> + interrupt-parent = <_intc>;
>> + interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
>> + #clock-cells = <1>;
>> + clock-output-names = "cko1_rtc", "cko2_rtc", "cko3_rtc";
>> + };
>> +};
>> --
>> 2.8.1
>>

Re: [PATCH v3 2/8] mfd: ac100: Add device tree bindings for X-Powers AC100 codec/RTC combo IC

[Chen-Yu Tsai]

On Tue, Jun 21, 2016 at 9:14 PM, Rob Herring  wrote:
> On Mon, Jun 20, 2016 at 10:52:12AM +0800, Chen-Yu Tsai wrote:
>> Signed-off-by: Chen-Yu Tsai 
>> ---
>> Changes since v2:
>>
>>   - Fix interrupt line for ac100_codec in provided example.
>>
>> ---
>>  Documentation/devicetree/bindings/mfd/ac100.txt | 42 
>> +
>>  1 file changed, 42 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/mfd/ac100.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mfd/ac100.txt 
>> b/Documentation/devicetree/bindings/mfd/ac100.txt
>> new file mode 100644
>> index ..a793954bb952
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mfd/ac100.txt
>> @@ -0,0 +1,42 @@
>> +X-Powers AC100 Codec/RTC IC device tree bindings
>> +
>> +AC100 is a audio codec and RTC subsystem combo IC. The 2 parts are
>> +separated, including power supplies and interrupt lines, but share
>> +a common register address space and host interface.
>> +
>> +Required properties:
>> +- compatible: "x-powers,ac100"
>> +- reg: The I2C slave address or RSB hardware address for the chip
>> +- sub-nodes:
>> +  - codec
>> +- compatible: "x-powers,ac100-codec"
>> +- interrupt-parent: The parent interrupt controller
>> +- interrupts: SoC NMI / GPIO interrupt connected to the IRQ_AUDIO pin
>> +  - rtc
>> +- compatible: "x-powers,ac100-rtc"
>> +- interrupt-parent: The parent interrupt controller
>> +- interrupts: SoC NMI / GPIO interrupt connected to the IRQ_RTC pin
>> +- #clock-cells: shall be 1
>> +- clock-output-names: "cko1_rtc", "cko2_rtc", "cko3_rtc"
>> +- see clock/clock-bindings.txt for common clock bindings
>> +
>> +Example:
>> +
>> +ac100: codec@e89 {
>> + compatible = "x-powers,ac100";
>> + reg = <0xe89>;
>> +
>> + ac100_codec {
>
> Use generic node names and no underscores:
>
> codec {

Right. I intended to add them as labels, not change the node names.

Thanks
ChenYu

>
>> + compatible = "x-powers,ac100-codec";
>> + interrupt-parent = <_pio>;
>> + interrupts = <0 9 IRQ_TYPE_LEVEL_LOW>; /* PL9 */
>> + };
>> +
>> + ac100_rtc {
>
> rtc {
>
>> + compatible = "x-powers,ac100-rtc";
>> + interrupt-parent = <_intc>;
>> + interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
>> + #clock-cells = <1>;
>> + clock-output-names = "cko1_rtc", "cko2_rtc", "cko3_rtc";
>> + };
>> +};
>> --
>> 2.8.1
>>

Re: [PATCH 2/3] staging: lowmemorykiller: count anon pages only when we have swap devices

[Ganesh Mahendran]

Hi, David:

On Tue, Jun 21, 2016 at 01:22:00PM -0700, David Rientjes wrote:
> On Tue, 21 Jun 2016, Ganesh Mahendran wrote:
> 
> > lowmem_count() should only count anon pages when we have swap device.
> > 
> 
> Why?

I make a mistake. I thought lowmem_count will return the shrinkalbe page
of a process.

> 
> > Signed-off-by: Ganesh Mahendran 
> > ---
> >  drivers/staging/android/lowmemorykiller.c | 12 
> >  1 file changed, 8 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/staging/android/lowmemorykiller.c 
> > b/drivers/staging/android/lowmemorykiller.c
> > index 6da9260..1d8de47 100644
> > --- a/drivers/staging/android/lowmemorykiller.c
> > +++ b/drivers/staging/android/lowmemorykiller.c
> > @@ -73,10 +73,14 @@ static unsigned long lowmem_deathpending_timeout;
> >  static unsigned long lowmem_count(struct shrinker *s,
> >   struct shrink_control *sc)
> >  {
> > -   return global_page_state(NR_ACTIVE_ANON) +
> > -   global_page_state(NR_ACTIVE_FILE) +
> > -   global_page_state(NR_INACTIVE_ANON) +
> > -   global_page_state(NR_INACTIVE_FILE);
> > +   unsigned long freeable = global_page_state(NR_ACTIVE_FILE) +
> > +   global_page_state(NR_INACTIVE_FILE);
> > +
> > +   if (get_nr_swap_pages() > 0)
> > +   freeable += global_page_state(NR_ACTIVE_ANON) +
> > +   global_page_state(NR_INACTIVE_ANON);
> > +
> > +   return freeable;
> >  }
> >  
> >  static unsigned long lowmem_scan(struct shrinker *s, struct shrink_control 
> > *sc)
> 
> Shouldn't this be advertising the amount of memory that is freeable by 
> killing the process with the highest priority oom_score_adj?  It's not 
> legitimate to say it can free all anon and file memory if nothing is oom 
> killable, so this function is wrong both originally and with your patched 
> version.

Yes, so should we just simply return 1 to make do_shrink_slab() go ahead?
Then lowmem_scan() will do the real job to scan all the process.

Thanks.

Re: [PATCH 2/3] staging: lowmemorykiller: count anon pages only when we have swap devices

[Ganesh Mahendran]

Hi, David:

On Tue, Jun 21, 2016 at 01:22:00PM -0700, David Rientjes wrote:
> On Tue, 21 Jun 2016, Ganesh Mahendran wrote:
> 
> > lowmem_count() should only count anon pages when we have swap device.
> > 
> 
> Why?

I make a mistake. I thought lowmem_count will return the shrinkalbe page
of a process.

> 
> > Signed-off-by: Ganesh Mahendran 
> > ---
> >  drivers/staging/android/lowmemorykiller.c | 12 
> >  1 file changed, 8 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/staging/android/lowmemorykiller.c 
> > b/drivers/staging/android/lowmemorykiller.c
> > index 6da9260..1d8de47 100644
> > --- a/drivers/staging/android/lowmemorykiller.c
> > +++ b/drivers/staging/android/lowmemorykiller.c
> > @@ -73,10 +73,14 @@ static unsigned long lowmem_deathpending_timeout;
> >  static unsigned long lowmem_count(struct shrinker *s,
> >   struct shrink_control *sc)
> >  {
> > -   return global_page_state(NR_ACTIVE_ANON) +
> > -   global_page_state(NR_ACTIVE_FILE) +
> > -   global_page_state(NR_INACTIVE_ANON) +
> > -   global_page_state(NR_INACTIVE_FILE);
> > +   unsigned long freeable = global_page_state(NR_ACTIVE_FILE) +
> > +   global_page_state(NR_INACTIVE_FILE);
> > +
> > +   if (get_nr_swap_pages() > 0)
> > +   freeable += global_page_state(NR_ACTIVE_ANON) +
> > +   global_page_state(NR_INACTIVE_ANON);
> > +
> > +   return freeable;
> >  }
> >  
> >  static unsigned long lowmem_scan(struct shrinker *s, struct shrink_control 
> > *sc)
> 
> Shouldn't this be advertising the amount of memory that is freeable by 
> killing the process with the highest priority oom_score_adj?  It's not 
> legitimate to say it can free all anon and file memory if nothing is oom 
> killable, so this function is wrong both originally and with your patched 
> version.

Yes, so should we just simply return 1 to make do_shrink_slab() go ahead?
Then lowmem_scan() will do the real job to scan all the process.

Thanks.

Re: [PATCH v8 3/8] perf tests: Add testcase for auxiliary evlist

[Wangnan (F)]

On 2016/6/22 5:05, Arnaldo Carvalho de Melo wrote:

Em Mon, Jun 20, 2016 at 10:47:20AM +, Wang Nan escreveu:

Improve test backward


[SNIP]



diff --git a/tools/perf/tests/backward-ring-buffer.c 
b/tools/perf/tests/backward-ring-buffer.c
index d9ba991..76e34c0 100644
--- a/tools/perf/tests/backward-ring-buffer.c
+++ b/tools/perf/tests/backward-ring-buffer.c
@@ -31,16 +31,19 @@ static int count_samples(struct perf_evlist *evlist, int 
*sample_count,
for (i = 0; i < evlist->nr_mmaps; i++) {
union perf_event *event;
  
-		perf_evlist__mmap_read_catchup(evlist, i);

-   while ((event = perf_evlist__mmap_read_backward(evlist, i)) != 
NULL) {
+   if (evlist->backward)
+   perf_evlist__mmap_read_catchup(evlist, i);

So, shouldn't this be done at perf_evlist__mmap_read_catchup()? I.e. you
will use this only when you know that one of the evlists count_samples()
will deal with can be a backwards one...

I.e. do with perf_evlist__mmap_read_catchup the same thing you did in
perf_evlist__mmap_read, checking there this evlist->backward.


I can make the code clearer, but I don't agree hiding evlist->backward 
checker in

perf_evlist__mmap_read_catchup():

1. If we make perf_evlist__mmap_read_catchup() implicitly ignore 
non-backward evlist,
   then we are creating a new rule for reading from mmaps that, before 
calling
   perf_evlist__mmap_read() we need to call 
perf_evlist__mmap_read_catchup() first.
   Theoretically, existing code should be adjusted to satisify this new 
rule, but

   actually most of catchup does nothing.

   If we don't require existing code be adjusted, then we are still 
required to
   clarify when catchup() is required, so evlist->backward is still 
exposed.


2. I think we don't need to restrict perf_evlist__mmap_read_catchup() 
for backward
   ring buffer. It is a generic operations, can be used for a normal 
evlist to

   consume existing data in ring buffer.



This can be done on top, so I'll continue tentatively merging this.


+   while ((event = perf_evlist__mmap_read(evlist, i)) != NULL) {
const u32 type = event->header.type;
  
  			switch (type) {

case PERF_RECORD_SAMPLE:
-   (*sample_count)++;
+   if (sample_count)
+   (*sample_count)++;
break;
case PERF_RECORD_COMM:
-   (*comm_count)++;
+   if (comm_count)
+   (*comm_count)++;

You could've avoided all this by passing some dummy integer pointer for
the enter_sample_count case. Making the patch smaller helps reviewing
:-)


Will do.

Thank you.

Re: [PATCH] xen/pciback: Fix conf_space read/write overlap check.

[Juergen Gross]

On 21/06/16 17:52, Boris Ostrovsky wrote:
> On 06/21/2016 10:37 AM, Andrey Grodzovsky wrote:
>> Current overlap check is evaluating to false a case where a filter field
>> is fully contained (proper subset) of a r/w request.
>> This change applies classical overlap check instead to include
>> all the scenarios.
>>
>> Related to https://www.mail-archive.com/xen-devel@lists.xen.org/msg72174.html
>>
>> Cc: Jan Beulich 
>> Cc: Boris Ostrovsky 
>> Cc: sta...@vger.kernel.org
>> Signed-off-by: Andrey Grodzovsky 
> 
> + David and Juergen (maintainers) and kernel list.
> 
> Reviewed-by: Boris Ostrovsky 

Acked-by: Juergen Gross 

> 
> 
>> ---
>>  drivers/xen/xen-pciback/conf_space.c | 6 ++
>>  1 file changed, 2 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/xen/xen-pciback/conf_space.c 
>> b/drivers/xen/xen-pciback/conf_space.c
>> index 8e67336..6a25533 100644
>> --- a/drivers/xen/xen-pciback/conf_space.c
>> +++ b/drivers/xen/xen-pciback/conf_space.c
>> @@ -183,8 +183,7 @@ int xen_pcibk_config_read(struct pci_dev *dev, int 
>> offset, int size,
>>  field_start = OFFSET(cfg_entry);
>>  field_end = OFFSET(cfg_entry) + field->size;
>>  
>> -if ((req_start >= field_start && req_start < field_end)
>> -|| (req_end > field_start && req_end <= field_end)) {
>> + if (req_end > field_start && field_end > req_start) {
>>  err = conf_space_read(dev, cfg_entry, field_start,
>>_val);
>>  if (err)
>> @@ -230,8 +229,7 @@ int xen_pcibk_config_write(struct pci_dev *dev, int 
>> offset, int size, u32 value)
>>  field_start = OFFSET(cfg_entry);
>>  field_end = OFFSET(cfg_entry) + field->size;
>>  
>> -if ((req_start >= field_start && req_start < field_end)
>> -|| (req_end > field_start && req_end <= field_end)) {
>> + if (req_end > field_start && field_end > req_start) {
>>  tmp_val = 0;
>>  
>>  err = xen_pcibk_config_read(dev, field_start,
> 
> 
> 

Re: [PATCH v8 3/8] perf tests: Add testcase for auxiliary evlist

[Wangnan (F)]

On 2016/6/22 5:05, Arnaldo Carvalho de Melo wrote:

Em Mon, Jun 20, 2016 at 10:47:20AM +, Wang Nan escreveu:

Improve test backward


[SNIP]



diff --git a/tools/perf/tests/backward-ring-buffer.c 
b/tools/perf/tests/backward-ring-buffer.c
index d9ba991..76e34c0 100644
--- a/tools/perf/tests/backward-ring-buffer.c
+++ b/tools/perf/tests/backward-ring-buffer.c
@@ -31,16 +31,19 @@ static int count_samples(struct perf_evlist *evlist, int 
*sample_count,
for (i = 0; i < evlist->nr_mmaps; i++) {
union perf_event *event;
  
-		perf_evlist__mmap_read_catchup(evlist, i);

-   while ((event = perf_evlist__mmap_read_backward(evlist, i)) != 
NULL) {
+   if (evlist->backward)
+   perf_evlist__mmap_read_catchup(evlist, i);

So, shouldn't this be done at perf_evlist__mmap_read_catchup()? I.e. you
will use this only when you know that one of the evlists count_samples()
will deal with can be a backwards one...

I.e. do with perf_evlist__mmap_read_catchup the same thing you did in
perf_evlist__mmap_read, checking there this evlist->backward.


I can make the code clearer, but I don't agree hiding evlist->backward 
checker in

perf_evlist__mmap_read_catchup():

1. If we make perf_evlist__mmap_read_catchup() implicitly ignore 
non-backward evlist,
   then we are creating a new rule for reading from mmaps that, before 
calling
   perf_evlist__mmap_read() we need to call 
perf_evlist__mmap_read_catchup() first.
   Theoretically, existing code should be adjusted to satisify this new 
rule, but

   actually most of catchup does nothing.

   If we don't require existing code be adjusted, then we are still 
required to
   clarify when catchup() is required, so evlist->backward is still 
exposed.


2. I think we don't need to restrict perf_evlist__mmap_read_catchup() 
for backward
   ring buffer. It is a generic operations, can be used for a normal 
evlist to

   consume existing data in ring buffer.



This can be done on top, so I'll continue tentatively merging this.


+   while ((event = perf_evlist__mmap_read(evlist, i)) != NULL) {
const u32 type = event->header.type;
  
  			switch (type) {

case PERF_RECORD_SAMPLE:
-   (*sample_count)++;
+   if (sample_count)
+   (*sample_count)++;
break;
case PERF_RECORD_COMM:
-   (*comm_count)++;
+   if (comm_count)
+   (*comm_count)++;

You could've avoided all this by passing some dummy integer pointer for
the enter_sample_count case. Making the patch smaller helps reviewing
:-)


Will do.

Thank you.

Re: [PATCH] xen/pciback: Fix conf_space read/write overlap check.

[Juergen Gross]

On 21/06/16 17:52, Boris Ostrovsky wrote:
> On 06/21/2016 10:37 AM, Andrey Grodzovsky wrote:
>> Current overlap check is evaluating to false a case where a filter field
>> is fully contained (proper subset) of a r/w request.
>> This change applies classical overlap check instead to include
>> all the scenarios.
>>
>> Related to https://www.mail-archive.com/xen-devel@lists.xen.org/msg72174.html
>>
>> Cc: Jan Beulich 
>> Cc: Boris Ostrovsky 
>> Cc: sta...@vger.kernel.org
>> Signed-off-by: Andrey Grodzovsky 
> 
> + David and Juergen (maintainers) and kernel list.
> 
> Reviewed-by: Boris Ostrovsky 

Acked-by: Juergen Gross 

> 
> 
>> ---
>>  drivers/xen/xen-pciback/conf_space.c | 6 ++
>>  1 file changed, 2 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/xen/xen-pciback/conf_space.c 
>> b/drivers/xen/xen-pciback/conf_space.c
>> index 8e67336..6a25533 100644
>> --- a/drivers/xen/xen-pciback/conf_space.c
>> +++ b/drivers/xen/xen-pciback/conf_space.c
>> @@ -183,8 +183,7 @@ int xen_pcibk_config_read(struct pci_dev *dev, int 
>> offset, int size,
>>  field_start = OFFSET(cfg_entry);
>>  field_end = OFFSET(cfg_entry) + field->size;
>>  
>> -if ((req_start >= field_start && req_start < field_end)
>> -|| (req_end > field_start && req_end <= field_end)) {
>> + if (req_end > field_start && field_end > req_start) {
>>  err = conf_space_read(dev, cfg_entry, field_start,
>>_val);
>>  if (err)
>> @@ -230,8 +229,7 @@ int xen_pcibk_config_write(struct pci_dev *dev, int 
>> offset, int size, u32 value)
>>  field_start = OFFSET(cfg_entry);
>>  field_end = OFFSET(cfg_entry) + field->size;
>>  
>> -if ((req_start >= field_start && req_start < field_end)
>> -|| (req_end > field_start && req_end <= field_end)) {
>> + if (req_end > field_start && field_end > req_start) {
>>  tmp_val = 0;
>>  
>>  err = xen_pcibk_config_read(dev, field_start,
> 
> 
> 

Re: [PATCH 1/3] staging: lowmemorykiller: change lowmem_adj to lowmem_score_adj

[Ganesh Mahendran]

Hi, David:

On Tue, Jun 21, 2016 at 01:27:40PM -0700, David Rientjes wrote:
> On Tue, 21 Jun 2016, Ganesh Mahendran wrote:
> 
> > om_adj is deprecated, and in lowmemorykiller module, we use score adj
> > to do the comparing.
> > ---
> > oom_score_adj = p->signal->oom_score_adj;
> > if (oom_score_adj < min_score_adj) {
> > task_unlock(p);
> > continue;
> > }
> > ---
> > 
> > This patch makes the variable name consistent with the usage.
> > 
> 
> Umm, I don't think you can just remove a parameter to a module and replace 
> it with something that has a different unit and not think that userspace 
> will break as a result.

You are right, this change will break android AMS which will set the LMK
watermark via /sys/module/lowmemorykiller/parameters/adj.

Please help to review below change. Only make the varialbe name consistent
with the variable usage.

--
>From 394872fc1993a04ae471b10d7f971d4544812ec4 Mon Sep 17 00:00:00 2001
From: Ganesh Mahendran 
Date: Wed, 22 Jun 2016 10:53:13 +0800
Subject: [PATCH v2] staging: lowmemorykiller: make variable name consistent with
 the varialbe usage

LMK use oom_score_adj to do the comparing. But the variable name is
*_adj. This patch makes thevarialbe name consistent with the varialb
usage to avoid ambiguity.

*_adj -> *_score_adj

Signed-off-by: Ganesh Mahendran 
---
v2:
  do not change user API - David
---
 drivers/staging/android/lowmemorykiller.c | 23 ---
 1 file changed, 12 insertions(+), 11 deletions(-)

diff --git a/drivers/staging/android/lowmemorykiller.c 
b/drivers/staging/android/lowmemorykiller.c
index 24d2745..6568bbf 100644
--- a/drivers/staging/android/lowmemorykiller.c
+++ b/drivers/staging/android/lowmemorykiller.c
@@ -44,14 +44,15 @@
 #include 
 
 static u32 lowmem_debug_level = 1;
-static short lowmem_adj[6] = {
+
+static short lowmem_score_adj[6] = {
0,
-   1,
-   6,
-   12,
+   58,
+   352,
+   705,
 };
 
-static int lowmem_adj_size = 4;
+static int lowmem_score_adj_size = 4;
 static int lowmem_minfree[6] = {
3 * 512,/* 6MB */
2 * 1024,   /* 8MB */
@@ -89,20 +90,20 @@ static unsigned long lowmem_scan(struct shrinker *s, struct 
shrink_control *sc)
int minfree = 0;
int selected_tasksize = 0;
short selected_oom_score_adj;
-   int array_size = ARRAY_SIZE(lowmem_adj);
+   int array_size = ARRAY_SIZE(lowmem_score_adj);
int other_free = global_page_state(NR_FREE_PAGES) - totalreserve_pages;
int other_file = global_page_state(NR_FILE_PAGES) -
global_page_state(NR_SHMEM) -
total_swapcache_pages();
 
-   if (lowmem_adj_size < array_size)
-   array_size = lowmem_adj_size;
+   if (lowmem_score_adj_size < array_size)
+   array_size = lowmem_score_adj_size;
if (lowmem_minfree_size < array_size)
array_size = lowmem_minfree_size;
for (i = 0; i < array_size; i++) {
minfree = lowmem_minfree[i];
if (other_free < minfree && other_file < minfree) {
-   min_score_adj = lowmem_adj[i];
+   min_score_adj = lowmem_score_adj[i];
break;
}
}
@@ -165,7 +166,7 @@ static unsigned long lowmem_scan(struct shrinker *s, struct 
shrink_control *sc)
if (selected->mm)
task_set_lmk_waiting(selected);
task_unlock(selected);
-   lowmem_print(1, "Killing '%s' (%d), adj %hd,\n"
+   lowmem_print(1, "Killing '%s' (%d), score adj %hd,\n"
 "   to free %ldkB on behalf of '%s' (%d) 
because\n"
 "   cache %ldkB is below limit %ldkB for 
oom_score_adj %hd\n"
 "   Free memory is %ldkB above reserved\n",
@@ -205,7 +206,7 @@ device_initcall(lowmem_init);
  * bootargs behaviour is to continue using module_param here.
  */
 module_param_named(cost, lowmem_shrinker.seeks, int, S_IRUGO | S_IWUSR);
-module_param_array_named(adj, lowmem_adj, short, _adj_size,
+module_param_array_named(adj, lowmem_score_adj, short, _score_adj_size,
 S_IRUGO | S_IWUSR);
 module_param_array_named(minfree, lowmem_minfree, uint, _minfree_size,
 S_IRUGO | S_IWUSR);
-- 
1.9.1

Re: [PATCH 1/3] staging: lowmemorykiller: change lowmem_adj to lowmem_score_adj

[Ganesh Mahendran]

Hi, David:

On Tue, Jun 21, 2016 at 01:27:40PM -0700, David Rientjes wrote:
> On Tue, 21 Jun 2016, Ganesh Mahendran wrote:
> 
> > om_adj is deprecated, and in lowmemorykiller module, we use score adj
> > to do the comparing.
> > ---
> > oom_score_adj = p->signal->oom_score_adj;
> > if (oom_score_adj < min_score_adj) {
> > task_unlock(p);
> > continue;
> > }
> > ---
> > 
> > This patch makes the variable name consistent with the usage.
> > 
> 
> Umm, I don't think you can just remove a parameter to a module and replace 
> it with something that has a different unit and not think that userspace 
> will break as a result.

You are right, this change will break android AMS which will set the LMK
watermark via /sys/module/lowmemorykiller/parameters/adj.

Please help to review below change. Only make the varialbe name consistent
with the variable usage.

--
>From 394872fc1993a04ae471b10d7f971d4544812ec4 Mon Sep 17 00:00:00 2001
From: Ganesh Mahendran 
Date: Wed, 22 Jun 2016 10:53:13 +0800
Subject: [PATCH v2] staging: lowmemorykiller: make variable name consistent with
 the varialbe usage

LMK use oom_score_adj to do the comparing. But the variable name is
*_adj. This patch makes thevarialbe name consistent with the varialb
usage to avoid ambiguity.

*_adj -> *_score_adj

Signed-off-by: Ganesh Mahendran 
---
v2:
  do not change user API - David
---
 drivers/staging/android/lowmemorykiller.c | 23 ---
 1 file changed, 12 insertions(+), 11 deletions(-)

diff --git a/drivers/staging/android/lowmemorykiller.c 
b/drivers/staging/android/lowmemorykiller.c
index 24d2745..6568bbf 100644
--- a/drivers/staging/android/lowmemorykiller.c
+++ b/drivers/staging/android/lowmemorykiller.c
@@ -44,14 +44,15 @@
 #include 
 
 static u32 lowmem_debug_level = 1;
-static short lowmem_adj[6] = {
+
+static short lowmem_score_adj[6] = {
0,
-   1,
-   6,
-   12,
+   58,
+   352,
+   705,
 };
 
-static int lowmem_adj_size = 4;
+static int lowmem_score_adj_size = 4;
 static int lowmem_minfree[6] = {
3 * 512,/* 6MB */
2 * 1024,   /* 8MB */
@@ -89,20 +90,20 @@ static unsigned long lowmem_scan(struct shrinker *s, struct 
shrink_control *sc)
int minfree = 0;
int selected_tasksize = 0;
short selected_oom_score_adj;
-   int array_size = ARRAY_SIZE(lowmem_adj);
+   int array_size = ARRAY_SIZE(lowmem_score_adj);
int other_free = global_page_state(NR_FREE_PAGES) - totalreserve_pages;
int other_file = global_page_state(NR_FILE_PAGES) -
global_page_state(NR_SHMEM) -
total_swapcache_pages();
 
-   if (lowmem_adj_size < array_size)
-   array_size = lowmem_adj_size;
+   if (lowmem_score_adj_size < array_size)
+   array_size = lowmem_score_adj_size;
if (lowmem_minfree_size < array_size)
array_size = lowmem_minfree_size;
for (i = 0; i < array_size; i++) {
minfree = lowmem_minfree[i];
if (other_free < minfree && other_file < minfree) {
-   min_score_adj = lowmem_adj[i];
+   min_score_adj = lowmem_score_adj[i];
break;
}
}
@@ -165,7 +166,7 @@ static unsigned long lowmem_scan(struct shrinker *s, struct 
shrink_control *sc)
if (selected->mm)
task_set_lmk_waiting(selected);
task_unlock(selected);
-   lowmem_print(1, "Killing '%s' (%d), adj %hd,\n"
+   lowmem_print(1, "Killing '%s' (%d), score adj %hd,\n"
 "   to free %ldkB on behalf of '%s' (%d) 
because\n"
 "   cache %ldkB is below limit %ldkB for 
oom_score_adj %hd\n"
 "   Free memory is %ldkB above reserved\n",
@@ -205,7 +206,7 @@ device_initcall(lowmem_init);
  * bootargs behaviour is to continue using module_param here.
  */
 module_param_named(cost, lowmem_shrinker.seeks, int, S_IRUGO | S_IWUSR);
-module_param_array_named(adj, lowmem_adj, short, _adj_size,
+module_param_array_named(adj, lowmem_score_adj, short, _score_adj_size,
 S_IRUGO | S_IWUSR);
 module_param_array_named(minfree, lowmem_minfree, uint, _minfree_size,
 S_IRUGO | S_IWUSR);
-- 
1.9.1

Re: [PATCH] ppc: Fix BPF JIT for ABIv2

[Michael Ellerman]

On Tue, 2016-06-21 at 08:45 -0700, Alexei Starovoitov wrote:
> On 6/21/16 7:47 AM, Thadeu Lima de Souza Cascardo wrote:
> > > > 
> > > > The calling convention is different with ABIv2 and so we'll need changes
> > > > in bpf_slow_path_common() and sk_negative_common().
> > > 
> > > How big would those changes be? Do we know?
> > > 
> > > How come no one reported this was broken previously? This is the first 
> > > I've
> > > heard of it being broken.
> > > 
> > 
> > I just heard of it less than two weeks ago, and only could investigate it 
> > last
> > week, when I realized mainline was also affected.
> > 
> > It looks like the little-endian support for classic JIT were done before the
> > conversion to ABIv2. And as JIT is disabled by default, no one seems to have
> > exercised it.
> 
> it's not a surprise unfortunately. The JITs that were written before
> test_bpf.ko was developed were missing corner cases. Typical tcpdump
> would be fine, but fragmented packets, negative offsets and
> out-out-bounds wouldn't be handled correctly.
> I'd suggest to validate the stable backport with test_bpf as well.
 
OK thanks.

I have been running seltests/net/test_bpf, but I realise now it doesn't enable
the JIT.

cheers

Re: [PATCH] ppc: Fix BPF JIT for ABIv2

[Michael Ellerman]

On Tue, 2016-06-21 at 08:45 -0700, Alexei Starovoitov wrote:
> On 6/21/16 7:47 AM, Thadeu Lima de Souza Cascardo wrote:
> > > > 
> > > > The calling convention is different with ABIv2 and so we'll need changes
> > > > in bpf_slow_path_common() and sk_negative_common().
> > > 
> > > How big would those changes be? Do we know?
> > > 
> > > How come no one reported this was broken previously? This is the first 
> > > I've
> > > heard of it being broken.
> > > 
> > 
> > I just heard of it less than two weeks ago, and only could investigate it 
> > last
> > week, when I realized mainline was also affected.
> > 
> > It looks like the little-endian support for classic JIT were done before the
> > conversion to ABIv2. And as JIT is disabled by default, no one seems to have
> > exercised it.
> 
> it's not a surprise unfortunately. The JITs that were written before
> test_bpf.ko was developed were missing corner cases. Typical tcpdump
> would be fine, but fragmented packets, negative offsets and
> out-out-bounds wouldn't be handled correctly.
> I'd suggest to validate the stable backport with test_bpf as well.
 
OK thanks.

I have been running seltests/net/test_bpf, but I realise now it doesn't enable
the JIT.

cheers

Re: Reported regressions for 4.7 as of Sunday, 2016-06-19

[Quinn Tran]

Investigating.

Regards,
Quinn Tran







-Original Message-
From: "Martin K. Petersen" 
Organization: Oracle Corporation
Date: Tuesday, June 21, 2016 at 6:25 PM
To: Linus Torvalds 
Cc: Josh Boyer , "Martin K. Petersen" 
, Johannes Thumshirn , Thorsten 
Leemhuis , linux-kernel 
, Quinn Tran 
Subject: Re: Reported regressions for 4.7 as of Sunday, 2016-06-19

>> "Linus" == Linus Torvalds  writes:
>
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1348342
>
>This first one appears to be a crash in a USB sound doodad and not
>qla2xxx. Also, this appears to be where the 4.5.5 -> 4.5.6 notion comes
>from. So we can probably ignore 4.5.5 as the last good revision.
>
>Linus> as far as I can tell. And neither of them looks very likely, but
>Linus> what do I know. Adding Martin Petersen and Johannes Thumshirn to
>Linus> the participants just in case they go "Ahh.."
>
>Doubt it's Johannes' tweak. The qla2xxx crash from the two other
>bugzilla entries is in:
>
>(gdb) list *qla24xx_process_response_queue+0x49
>0x27e09 is in qla24xx_process_response_queue 
>(drivers/scsi/qla2xxx/qla_isr.c:2560).
>2555if (rsp->msix->cpuid != smp_processor_id()) {
>2556/* if kernel does not notify qla of IRQ's CPU change,
>2557 * then set it here.
>2558 */
>2559rsp->msix->cpuid = smp_processor_id();
>2560ha->tgt.rspq_vector_cpuid = rsp->msix->cpuid;
>2561}
>2562
>2563while (rsp->ring_ptr->signature != RESPONSE_PROCESSED) {
>2564pkt = (struct sts_entry_24xx *)rsp->ring_ptr;
>
>That particular code went into 4.5 and comes from:
>
>commit cdb898c52d1dfad4b4800b83a58b3fe5d352edde
>Author: Quinn Tran 
>Date:   Thu Dec 17 14:57:05 2015 -0500
>
>qla2xxx: Add irq affinity notification
>
>Register to receive notification of when irq setting change
>occured.
>
>Signed-off-by: Quinn Tran 
>Signed-off-by: Himanshu Madhani 
>Signed-off-by: Nicholas Bellinger 
>
>Quinn?
>
>-- 
>Martin K. Petersen Oracle Linux Engineering

Re: Reported regressions for 4.7 as of Sunday, 2016-06-19

[Quinn Tran]

Investigating.

Regards,
Quinn Tran







-Original Message-
From: "Martin K. Petersen" 
Organization: Oracle Corporation
Date: Tuesday, June 21, 2016 at 6:25 PM
To: Linus Torvalds 
Cc: Josh Boyer , "Martin K. Petersen" 
, Johannes Thumshirn , Thorsten 
Leemhuis , linux-kernel 
, Quinn Tran 
Subject: Re: Reported regressions for 4.7 as of Sunday, 2016-06-19

>> "Linus" == Linus Torvalds  writes:
>
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1348342
>
>This first one appears to be a crash in a USB sound doodad and not
>qla2xxx. Also, this appears to be where the 4.5.5 -> 4.5.6 notion comes
>from. So we can probably ignore 4.5.5 as the last good revision.
>
>Linus> as far as I can tell. And neither of them looks very likely, but
>Linus> what do I know. Adding Martin Petersen and Johannes Thumshirn to
>Linus> the participants just in case they go "Ahh.."
>
>Doubt it's Johannes' tweak. The qla2xxx crash from the two other
>bugzilla entries is in:
>
>(gdb) list *qla24xx_process_response_queue+0x49
>0x27e09 is in qla24xx_process_response_queue 
>(drivers/scsi/qla2xxx/qla_isr.c:2560).
>2555if (rsp->msix->cpuid != smp_processor_id()) {
>2556/* if kernel does not notify qla of IRQ's CPU change,
>2557 * then set it here.
>2558 */
>2559rsp->msix->cpuid = smp_processor_id();
>2560ha->tgt.rspq_vector_cpuid = rsp->msix->cpuid;
>2561}
>2562
>2563while (rsp->ring_ptr->signature != RESPONSE_PROCESSED) {
>2564pkt = (struct sts_entry_24xx *)rsp->ring_ptr;
>
>That particular code went into 4.5 and comes from:
>
>commit cdb898c52d1dfad4b4800b83a58b3fe5d352edde
>Author: Quinn Tran 
>Date:   Thu Dec 17 14:57:05 2015 -0500
>
>qla2xxx: Add irq affinity notification
>
>Register to receive notification of when irq setting change
>occured.
>
>Signed-off-by: Quinn Tran 
>Signed-off-by: Himanshu Madhani 
>Signed-off-by: Nicholas Bellinger 
>
>Quinn?
>
>-- 
>Martin K. Petersen Oracle Linux Engineering

Re: [RFC PATCH 1/2] drm: bridge: anx7688: Add anx7688 bridge driver support.

[Archit Taneja]

On 6/22/2016 8:14 AM, Nicolas Boichat wrote:

Hi Archit,

Thanks for your reply.

On Tue, Jun 21, 2016 at 11:39 PM, Archit Taneja  wrote:

Hi,

On 6/20/2016 12:44 PM, Nicolas Boichat wrote:


ANX7688 is a HDMI to DP converter (as well as USB-C port controller),
that has an internal microcontroller.

The only reason a Linux kernel driver is necessary is to reject
resolutions that require more bandwidth than what is available on
the DP side. DP bandwidth and lane count are reported by the bridge
via 2 registers on I2C.



How does the chip know when to enable/disable itself? Does it shutoff
itself if there isn't anything on the HDMI link?


Not 100% sure of the internals (there is a closed source firmware in
the chip), but I believe the HDMI/DP part of the chip is switched on
whenever there is a DP over USB-C connector plugged in.



Signed-off-by: Nicolas Boichat 
---

Hi,

I tested this driver using the Mediatek HDMI controller (MT8173) upstream
of the ANX bridge chip (Phillip sent a PULL request on June 13:
git://git.pengutronix.de/git/pza/linux.git tags/mediatek-drm-2016-06-13
).

I have 2 concerns, that I'm not sure how to address within the kernel DRM
framework:
   1. All other bridge drivers also have a connector attached to it.
However, in
  this case, we cannot read the monitor EDID directly, so I'm not sure
what
  I could put in a "get_modes" function. Instead, ANX7688 provides a
I2C
  passthru/repeater, so the EDID is read on the Mediatek HDMI
controller side.

  That leads to a somewhat strange layout, where we have:
  - MTK HDMI bridge/encoder
- MTK connector (HDMI)
- ANX7688 bridge
  - No connector




You should ideally have one DP connector at the end of the chain:

 - MTK HDMI bridge/encoder
 - ANX7688 bridge
- Connector (DP)

In the dt-bindings for this board, hdmi's output port shouldn't be
connected to a hdmi connector, but the input port of the ANX7688
DP bridge. The output port of the bridge should be the one that
connects to the DP connector.


Yes that's what I do (in the device tree).

Actually, experimenting a bit more with the code, I realized that the
connector is always attached to the encoder, not the bridge, so the 2
layouts above are actually identical (from the userspace point of
view). Except that the connector name should be HDMI in one case, and
DP in the other. But I think that's mostly a cosmetic difference?


Yeah, probably. I don't know what exactly the userspace does with
the connector type, but it would be nice to represent it as a DP
connector in case it makes any decisions based on it.




One way I can think of fixing this is to make make the MTK hdmi
encoder driver a bit smarter by observing the DT connections. If
it's output port is connected to just a hdmi-connector, then
things should be as before. If the output is connected to the DP
bridge, then it should create a DP connector. The connector ops
for the DP connector can still be the same as that of the HDMI
connector before, but the phandle to the DDC bus would be in the
DP device node in this case.


I think it'd be a bit weird to have the DDC bus phandle on the DP
connector, as we're not reading the EDID on the DP side of the bridge,
but on the HDMI side (and the bridge can do all sort of things to the
EDID: At the very least, I think it caches it).


On the board, do the DDC lines join directly from the SoC pins to the
DP connector, or does it go via the ANX7688 chip?

Even with the current bindings (referred from the link below), the
hdmi connector has the DDC node. Shouldn't it be the same in the DP
case too? The DP connector, like before, is still manged by the HDMI
driver, the only difference being the name and that it's two hops away
in the DT bindings.

https://patchwork.kernel.org/patch/9137089/




This way, you can get around having the correct layout.

Ideally, a bridge driver shouldn't be the one that creates a
connector. It may contain some of the connector functionality, but
the connector creation should be managed by the kms driver.
Almost all bridge drivers creating a connector in their .attach
callbacks since they own some of the connector functionality (like
reading EDID). That's something we're trying to fix by providing
some more bridge api that kms drivers can use.

Since this bridge driver doesn't have any connector functionality
anyway, you should be okay.


Great, thanks for clarifying.



  Resolution filtering works fine though, thanks to mode_fixup callback
on the
  bridge. It also helps that Mediatek HDMI bridge calls mode_fixup from
its
  connector mode_valid callback, so that invalid modes are not even
presented
  to userspace.

   2. In the bandwidth computation, I hard-code 8-bit per channel (bpc).
bpc does
  not seem to be included in the mode setting itself. We could possibly
iterate
  over connectors on the DRM device, 

Re: [RFC PATCH 1/2] drm: bridge: anx7688: Add anx7688 bridge driver support.

[Archit Taneja]

On 6/22/2016 8:14 AM, Nicolas Boichat wrote:

Hi Archit,

Thanks for your reply.

On Tue, Jun 21, 2016 at 11:39 PM, Archit Taneja  wrote:

Hi,

On 6/20/2016 12:44 PM, Nicolas Boichat wrote:


ANX7688 is a HDMI to DP converter (as well as USB-C port controller),
that has an internal microcontroller.

The only reason a Linux kernel driver is necessary is to reject
resolutions that require more bandwidth than what is available on
the DP side. DP bandwidth and lane count are reported by the bridge
via 2 registers on I2C.



How does the chip know when to enable/disable itself? Does it shutoff
itself if there isn't anything on the HDMI link?


Not 100% sure of the internals (there is a closed source firmware in
the chip), but I believe the HDMI/DP part of the chip is switched on
whenever there is a DP over USB-C connector plugged in.



Signed-off-by: Nicolas Boichat 
---

Hi,

I tested this driver using the Mediatek HDMI controller (MT8173) upstream
of the ANX bridge chip (Phillip sent a PULL request on June 13:
git://git.pengutronix.de/git/pza/linux.git tags/mediatek-drm-2016-06-13
).

I have 2 concerns, that I'm not sure how to address within the kernel DRM
framework:
   1. All other bridge drivers also have a connector attached to it.
However, in
  this case, we cannot read the monitor EDID directly, so I'm not sure
what
  I could put in a "get_modes" function. Instead, ANX7688 provides a
I2C
  passthru/repeater, so the EDID is read on the Mediatek HDMI
controller side.

  That leads to a somewhat strange layout, where we have:
  - MTK HDMI bridge/encoder
- MTK connector (HDMI)
- ANX7688 bridge
  - No connector




You should ideally have one DP connector at the end of the chain:

 - MTK HDMI bridge/encoder
 - ANX7688 bridge
- Connector (DP)

In the dt-bindings for this board, hdmi's output port shouldn't be
connected to a hdmi connector, but the input port of the ANX7688
DP bridge. The output port of the bridge should be the one that
connects to the DP connector.


Yes that's what I do (in the device tree).

Actually, experimenting a bit more with the code, I realized that the
connector is always attached to the encoder, not the bridge, so the 2
layouts above are actually identical (from the userspace point of
view). Except that the connector name should be HDMI in one case, and
DP in the other. But I think that's mostly a cosmetic difference?


Yeah, probably. I don't know what exactly the userspace does with
the connector type, but it would be nice to represent it as a DP
connector in case it makes any decisions based on it.




One way I can think of fixing this is to make make the MTK hdmi
encoder driver a bit smarter by observing the DT connections. If
it's output port is connected to just a hdmi-connector, then
things should be as before. If the output is connected to the DP
bridge, then it should create a DP connector. The connector ops
for the DP connector can still be the same as that of the HDMI
connector before, but the phandle to the DDC bus would be in the
DP device node in this case.


I think it'd be a bit weird to have the DDC bus phandle on the DP
connector, as we're not reading the EDID on the DP side of the bridge,
but on the HDMI side (and the bridge can do all sort of things to the
EDID: At the very least, I think it caches it).


On the board, do the DDC lines join directly from the SoC pins to the
DP connector, or does it go via the ANX7688 chip?

Even with the current bindings (referred from the link below), the
hdmi connector has the DDC node. Shouldn't it be the same in the DP
case too? The DP connector, like before, is still manged by the HDMI
driver, the only difference being the name and that it's two hops away
in the DT bindings.

https://patchwork.kernel.org/patch/9137089/




This way, you can get around having the correct layout.

Ideally, a bridge driver shouldn't be the one that creates a
connector. It may contain some of the connector functionality, but
the connector creation should be managed by the kms driver.
Almost all bridge drivers creating a connector in their .attach
callbacks since they own some of the connector functionality (like
reading EDID). That's something we're trying to fix by providing
some more bridge api that kms drivers can use.

Since this bridge driver doesn't have any connector functionality
anyway, you should be okay.


Great, thanks for clarifying.



  Resolution filtering works fine though, thanks to mode_fixup callback
on the
  bridge. It also helps that Mediatek HDMI bridge calls mode_fixup from
its
  connector mode_valid callback, so that invalid modes are not even
presented
  to userspace.

   2. In the bandwidth computation, I hard-code 8-bit per channel (bpc).
bpc does
  not seem to be included in the mode setting itself. We could possibly
iterate
  over connectors on the DRM device, but then, IIUC,
connector->display_info.bpc

Re: [PATCH v10 08/22] IB/hns: Add icm support

[Wei Hu (Xavier)]

On 2016/6/21 19:55, Leon Romanovsky wrote:

On Tue, Jun 21, 2016 at 12:37:39PM +0800, Wei Hu (Xavier) wrote:


On 2016/6/20 21:04, Leon Romanovsky wrote:

On Mon, Jun 20, 2016 at 05:48:15PM +0800, Wei Hu (Xavier) wrote:

On 2016/6/20 17:27, Leon Romanovsky wrote:

On Mon, Jun 20, 2016 at 03:49:24PM +0800, Wei Hu (Xavier) wrote:

On 2016/6/20 14:06, Leon Romanovsky wrote:

On Mon, Jun 20, 2016 at 12:37:40PM +0800, Wei Hu (Xavier) wrote:

On 2016/6/17 17:58, Leon Romanovsky wrote:

On Thu, Jun 16, 2016 at 10:35:16PM +0800, Lijun Ou wrote:

This patch mainly added icm support for RoCE. It initializes icm
which managers the relative memory blocks for RoCE. The data
structures of RoCE will be located in it. For example, CQ table,
QP table and MTPT table so on.

Signed-off-by: Wei Hu 
Signed-off-by: Nenglong Zhao 
Signed-off-by: Lijun Ou 
---

<...>


+

Another question which you didn't answer [1].

"I wonder if you have the same needs for ICM as it is in mlx4 device.
Do you have firmware?"

[1] http://marc.info/?l=linux-rdma=146545553104913=2

Hi, Leon
 Now we haven't firmware.
 But hardware still need memory for QPC\CQC\MTPT\mtt etc.

ICM stands for InfiniHost (Interconnect) Context Memory is a specific
memory place to share between host <-> FW and host <-> HW if HW is
aware of specific structures.

I assume that in your case, it is enough to allocate memory region and
supply it to HW. Am I right?

For Our hardware,
1. ICM has a memory management method, It's very good for QPC\CQC\MTPT\mtt
etc. we need it.

You need special HW to leverage its. AFAIK it is Mellanox specific.

For our hardware, we use ICM to memory management, the memory shared with
host and HW.
QPC\CQC\MTPT\mtt has specific memory requirement.
QPC\CQC\MTPT need continuous memory. we use ICM to management the block of
memory. It's very good！

I wasn't convinced why do you need to copy whole ICM logic which is
specific to Mellanox. Your requirements can be implemented by standard CMA
and/or DMA.

Hi, Leon

In hip06 soc,
Hardware need multiple memory blocks for QPC\CQC\MTPT, every block has 
continuous memory xxKbyte (like 128Kbyte),

We need to configure the first address of 128Kbyte to hardware.

For example:
//
example 1:
In create qp,
1. If the xx Kbyte memory that include QPC related with qpn, has not 
been allocated, do step 2.

   else do step 3.
2. dma_alloc xx Kbyte memory for QPC,  and configure the first address 
of xx Kbyte to hardware.

3. find the QPC memory in xx Kbyte, get the dma_addr.
4. send mailbox command to hardware to create QP.

In step 2, we call xx_table_get function as below to perform logic.
int hns_roce_table_get(struct hns_roce_dev *hr_dev,
   struct hns_roce_icm_table *table, unsigned long obj)
{

//dma_alloc_coherent 128Kbyte memory
hns_roce_alloc_icm(hr_dev,
  HNS_ROCE_TABLE_CHUNK_SIZE >> PAGE_SHIFT, );

/*configure the first address of xx Kbyte to hardware*/
hns_roce_map_icm(hr_dev, table, obj);

}

In step 3, we call xx_table_find function to perform logic.
void *hns_roce_table_find(struct hns_roce_icm_table *table, unsigned 
long obj,

  dma_addr_t *dma_handle);


example 2:
In modify qp:
1. find the QPC memory,  get the virtual addr.
2. modify the fields of QPC.
3. send mailbox command to hardware to modify QP.

In step 1,  we call xx_table_find function to perform logic.
//--


so, now we haven't a firmware, but ICM algorithm still suitable for 
hip06 soc perfectly.


Regards
Wei Hu

2. The meomry for QPC\CQC\MTPT\mtt only used for RoCE hardware and driver,
we don't want use MR.

I didn't mean Infiniband MR, but memory region returned from standard
allocation functions (kmalloc, ...).


3. Now we haven't firmware, maybe we need it next version.

You are always invited to add support once it will be needed, no need to
add it in advance.

Thanks

Re: [PATCH v10 08/22] IB/hns: Add icm support

[Wei Hu (Xavier)]

On 2016/6/21 19:55, Leon Romanovsky wrote:

On Tue, Jun 21, 2016 at 12:37:39PM +0800, Wei Hu (Xavier) wrote:


On 2016/6/20 21:04, Leon Romanovsky wrote:

On Mon, Jun 20, 2016 at 05:48:15PM +0800, Wei Hu (Xavier) wrote:

On 2016/6/20 17:27, Leon Romanovsky wrote:

On Mon, Jun 20, 2016 at 03:49:24PM +0800, Wei Hu (Xavier) wrote:

On 2016/6/20 14:06, Leon Romanovsky wrote:

On Mon, Jun 20, 2016 at 12:37:40PM +0800, Wei Hu (Xavier) wrote:

On 2016/6/17 17:58, Leon Romanovsky wrote:

On Thu, Jun 16, 2016 at 10:35:16PM +0800, Lijun Ou wrote:

This patch mainly added icm support for RoCE. It initializes icm
which managers the relative memory blocks for RoCE. The data
structures of RoCE will be located in it. For example, CQ table,
QP table and MTPT table so on.

Signed-off-by: Wei Hu 
Signed-off-by: Nenglong Zhao 
Signed-off-by: Lijun Ou 
---

<...>


+

Another question which you didn't answer [1].

"I wonder if you have the same needs for ICM as it is in mlx4 device.
Do you have firmware?"

[1] http://marc.info/?l=linux-rdma=146545553104913=2

Hi, Leon
 Now we haven't firmware.
 But hardware still need memory for QPC\CQC\MTPT\mtt etc.

ICM stands for InfiniHost (Interconnect) Context Memory is a specific
memory place to share between host <-> FW and host <-> HW if HW is
aware of specific structures.

I assume that in your case, it is enough to allocate memory region and
supply it to HW. Am I right?

For Our hardware,
1. ICM has a memory management method, It's very good for QPC\CQC\MTPT\mtt
etc. we need it.

You need special HW to leverage its. AFAIK it is Mellanox specific.

For our hardware, we use ICM to memory management, the memory shared with
host and HW.
QPC\CQC\MTPT\mtt has specific memory requirement.
QPC\CQC\MTPT need continuous memory. we use ICM to management the block of
memory. It's very good！

I wasn't convinced why do you need to copy whole ICM logic which is
specific to Mellanox. Your requirements can be implemented by standard CMA
and/or DMA.

Hi, Leon

In hip06 soc,
Hardware need multiple memory blocks for QPC\CQC\MTPT, every block has 
continuous memory xxKbyte (like 128Kbyte),

We need to configure the first address of 128Kbyte to hardware.

For example:
//
example 1:
In create qp,
1. If the xx Kbyte memory that include QPC related with qpn, has not 
been allocated, do step 2.

   else do step 3.
2. dma_alloc xx Kbyte memory for QPC,  and configure the first address 
of xx Kbyte to hardware.

3. find the QPC memory in xx Kbyte, get the dma_addr.
4. send mailbox command to hardware to create QP.

In step 2, we call xx_table_get function as below to perform logic.
int hns_roce_table_get(struct hns_roce_dev *hr_dev,
   struct hns_roce_icm_table *table, unsigned long obj)
{

//dma_alloc_coherent 128Kbyte memory
hns_roce_alloc_icm(hr_dev,
  HNS_ROCE_TABLE_CHUNK_SIZE >> PAGE_SHIFT, );

/*configure the first address of xx Kbyte to hardware*/
hns_roce_map_icm(hr_dev, table, obj);

}

In step 3, we call xx_table_find function to perform logic.
void *hns_roce_table_find(struct hns_roce_icm_table *table, unsigned 
long obj,

  dma_addr_t *dma_handle);


example 2:
In modify qp:
1. find the QPC memory,  get the virtual addr.
2. modify the fields of QPC.
3. send mailbox command to hardware to modify QP.

In step 1,  we call xx_table_find function to perform logic.
//--


so, now we haven't a firmware, but ICM algorithm still suitable for 
hip06 soc perfectly.


Regards
Wei Hu

2. The meomry for QPC\CQC\MTPT\mtt only used for RoCE hardware and driver,
we don't want use MR.

I didn't mean Infiniband MR, but memory region returned from standard
allocation functions (kmalloc, ...).


3. Now we haven't firmware, maybe we need it next version.

You are always invited to add support once it will be needed, no need to
add it in advance.

Thanks

Re: [PATCH v3] tools/perf: Fix the mask in regs_dump__printf and print_sample_iregs

[Madhavan Srinivasan]

On Tuesday 21 June 2016 09:05 PM, Yury Norov wrote:
> On Tue, Jun 21, 2016 at 08:26:40PM +0530, Madhavan Srinivasan wrote:
>> When decoding the perf_regs mask in regs_dump__printf(),
>> we loop through the mask using find_first_bit and find_next_bit functions.
>> "mask" is of type "u64", but sent as a "unsigned long *" to
>> lib functions along with sizeof().
>>
>> While the exisitng code works fine in most of the case,
>> the logic is broken when using a 32bit perf on a 64bit kernel (Big Endian).
>> When reading u64 using (u32 *)()[0], perf (lib/find_*_bit()) assumes it 
>> gets
>> lower 32bits of u64 which is wrong. Proposed fix is to swap the words
>> of the u64 to handle this case. This is _not_ endianess swap.
>>
>> Suggested-by: Yury Norov 
>> Cc: Yury Norov 
>> Cc: Peter Zijlstra 
>> Cc: Ingo Molnar 
>> Cc: Arnaldo Carvalho de Melo 
>> Cc: Alexander Shishkin 
>> Cc: Jiri Olsa 
>> Cc: Adrian Hunter 
>> Cc: Kan Liang 
>> Cc: Wang Nan 
>> Cc: Michael Ellerman 
>> Signed-off-by: Madhavan Srinivasan 
>> ---
>> Changelog v2:
>> 1)Moved the swap code to a common function
>> 2)Added more comments in the code
>>
>> Changelog v1:
>> 1)updated commit message and patch subject
>> 2)Add the fix to print_sample_iregs() in builtin-script.c
>>
>>  tools/include/linux/bitmap.h |  9 +
> What about include/linux/bitmap.h? I think we'd place it there first.

Wanted to handle that separately.

>
>>  tools/perf/builtin-script.c  | 16 +++-
>>  tools/perf/util/session.c| 16 +++-
>>  3 files changed, 39 insertions(+), 2 deletions(-)
>>
>> diff --git a/tools/include/linux/bitmap.h b/tools/include/linux/bitmap.h
>> index 28f5493da491..79998b26eb04 100644
>> --- a/tools/include/linux/bitmap.h
>> +++ b/tools/include/linux/bitmap.h
>> @@ -2,6 +2,7 @@
>>  #define _PERF_BITOPS_H
>>  
>>  #include 
>> +#include 
>>  #include 
>>  
>>  #define DECLARE_BITMAP(name,bits) \
>> @@ -22,6 +23,14 @@ void __bitmap_or(unsigned long *dst, const unsigned long 
>> *bitmap1,
>>  #define small_const_nbits(nbits) \
>>  (__builtin_constant_p(nbits) && (nbits) <= BITS_PER_LONG)
>>  
>> +static inline void bitmap_from_u64(unsigned long *_mask, u64 mask)
> Inline is not required. Some people don't not like it. Underscored parameter 
> in

Not sure why you say that. IIUC we can avoid a function call overhead,
also rest of the functions in the file likes it.

> function declaration is not the best idea as well. Try:
> static void bitmap_from_u64(unsigned long *bitmap, u64 mask)
>
>> +{
>> +_mask[0] = mask & ULONG_MAX;
>> +
>> +if (sizeof(mask) > sizeof(unsigned long))
>> +_mask[1] = mask >> 32;
>> +}
>> +
>>  static inline void bitmap_zero(unsigned long *dst, int nbits)
>>  {
>>  if (small_const_nbits(nbits))
>> diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
>> index e3ce2f34d3ad..73928310fd91 100644
>> --- a/tools/perf/builtin-script.c
>> +++ b/tools/perf/builtin-script.c
>> @@ -412,11 +412,25 @@ static void print_sample_iregs(struct perf_sample 
>> *sample,
>>  struct regs_dump *regs = >intr_regs;
>>  uint64_t mask = attr->sample_regs_intr;
>>  unsigned i = 0, r;
>> +unsigned long _mask[sizeof(mask)/sizeof(unsigned long)];
> If we start with it, I think we'd hide declaration machinery as well:
>
> #define DECLARE_L64_BITMAP(__name) unsigned long 
> __name[sizeof(u64)/sizeof(unsigned long)]
> or
> #define L64_BITMAP_SIZE (sizeof(u64)/sizeof(unsigned long))
>
> Or both :) Whatever you prefer.

ok

>
>>  
>>  if (!regs)
>>  return;
>>  
>> -for_each_set_bit(r, (unsigned long *) , sizeof(mask) * 8) {
>> +/*
>> + * Since u64 is passed as 'unsigned long *', check
>> + * to see whether we need to swap words within u64.
>> + * Reason being, in 32 bit big endian userspace on a
>> + * 64bit kernel, 'unsigned long' is 32 bits.
>> + * When reading u64 using (u32 *)()[0] and (u32 *)()[1],
>> + * we will get wrong value for the mask. This is what
>> + * find_first_bit() and find_next_bit() is doing.
>> + * Issue here is "(u32 *)()[0]" gets upper 32 bits of u64,
>> + * but perf assumes it gets lower 32bits of u64. Hence the check
>> + * and swap.
>> + */
>> +bitmap_from_u64(_mask, mask);
>> +for_each_set_bit(r, _mask, sizeof(mask) * 8) {
>>  u64 val = regs->regs[i++];
>>  printf("%5s:0x%"PRIx64" ", perf_reg_name(r), val);
>>  }
>> diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
>> index 5214974e841a..1337b1c73f82 100644
>> --- a/tools/perf/util/session.c
>> +++ b/tools/perf/util/session.c
>> @@ -940,8 +940,22 @@ static void branch_stack__printf(struct 

Re: [PATCH v3] tools/perf: Fix the mask in regs_dump__printf and print_sample_iregs

[Madhavan Srinivasan]

On Tuesday 21 June 2016 09:05 PM, Yury Norov wrote:
> On Tue, Jun 21, 2016 at 08:26:40PM +0530, Madhavan Srinivasan wrote:
>> When decoding the perf_regs mask in regs_dump__printf(),
>> we loop through the mask using find_first_bit and find_next_bit functions.
>> "mask" is of type "u64", but sent as a "unsigned long *" to
>> lib functions along with sizeof().
>>
>> While the exisitng code works fine in most of the case,
>> the logic is broken when using a 32bit perf on a 64bit kernel (Big Endian).
>> When reading u64 using (u32 *)()[0], perf (lib/find_*_bit()) assumes it 
>> gets
>> lower 32bits of u64 which is wrong. Proposed fix is to swap the words
>> of the u64 to handle this case. This is _not_ endianess swap.
>>
>> Suggested-by: Yury Norov 
>> Cc: Yury Norov 
>> Cc: Peter Zijlstra 
>> Cc: Ingo Molnar 
>> Cc: Arnaldo Carvalho de Melo 
>> Cc: Alexander Shishkin 
>> Cc: Jiri Olsa 
>> Cc: Adrian Hunter 
>> Cc: Kan Liang 
>> Cc: Wang Nan 
>> Cc: Michael Ellerman 
>> Signed-off-by: Madhavan Srinivasan 
>> ---
>> Changelog v2:
>> 1)Moved the swap code to a common function
>> 2)Added more comments in the code
>>
>> Changelog v1:
>> 1)updated commit message and patch subject
>> 2)Add the fix to print_sample_iregs() in builtin-script.c
>>
>>  tools/include/linux/bitmap.h |  9 +
> What about include/linux/bitmap.h? I think we'd place it there first.

Wanted to handle that separately.

>
>>  tools/perf/builtin-script.c  | 16 +++-
>>  tools/perf/util/session.c| 16 +++-
>>  3 files changed, 39 insertions(+), 2 deletions(-)
>>
>> diff --git a/tools/include/linux/bitmap.h b/tools/include/linux/bitmap.h
>> index 28f5493da491..79998b26eb04 100644
>> --- a/tools/include/linux/bitmap.h
>> +++ b/tools/include/linux/bitmap.h
>> @@ -2,6 +2,7 @@
>>  #define _PERF_BITOPS_H
>>  
>>  #include 
>> +#include 
>>  #include 
>>  
>>  #define DECLARE_BITMAP(name,bits) \
>> @@ -22,6 +23,14 @@ void __bitmap_or(unsigned long *dst, const unsigned long 
>> *bitmap1,
>>  #define small_const_nbits(nbits) \
>>  (__builtin_constant_p(nbits) && (nbits) <= BITS_PER_LONG)
>>  
>> +static inline void bitmap_from_u64(unsigned long *_mask, u64 mask)
> Inline is not required. Some people don't not like it. Underscored parameter 
> in

Not sure why you say that. IIUC we can avoid a function call overhead,
also rest of the functions in the file likes it.

> function declaration is not the best idea as well. Try:
> static void bitmap_from_u64(unsigned long *bitmap, u64 mask)
>
>> +{
>> +_mask[0] = mask & ULONG_MAX;
>> +
>> +if (sizeof(mask) > sizeof(unsigned long))
>> +_mask[1] = mask >> 32;
>> +}
>> +
>>  static inline void bitmap_zero(unsigned long *dst, int nbits)
>>  {
>>  if (small_const_nbits(nbits))
>> diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
>> index e3ce2f34d3ad..73928310fd91 100644
>> --- a/tools/perf/builtin-script.c
>> +++ b/tools/perf/builtin-script.c
>> @@ -412,11 +412,25 @@ static void print_sample_iregs(struct perf_sample 
>> *sample,
>>  struct regs_dump *regs = >intr_regs;
>>  uint64_t mask = attr->sample_regs_intr;
>>  unsigned i = 0, r;
>> +unsigned long _mask[sizeof(mask)/sizeof(unsigned long)];
> If we start with it, I think we'd hide declaration machinery as well:
>
> #define DECLARE_L64_BITMAP(__name) unsigned long 
> __name[sizeof(u64)/sizeof(unsigned long)]
> or
> #define L64_BITMAP_SIZE (sizeof(u64)/sizeof(unsigned long))
>
> Or both :) Whatever you prefer.

ok

>
>>  
>>  if (!regs)
>>  return;
>>  
>> -for_each_set_bit(r, (unsigned long *) , sizeof(mask) * 8) {
>> +/*
>> + * Since u64 is passed as 'unsigned long *', check
>> + * to see whether we need to swap words within u64.
>> + * Reason being, in 32 bit big endian userspace on a
>> + * 64bit kernel, 'unsigned long' is 32 bits.
>> + * When reading u64 using (u32 *)()[0] and (u32 *)()[1],
>> + * we will get wrong value for the mask. This is what
>> + * find_first_bit() and find_next_bit() is doing.
>> + * Issue here is "(u32 *)()[0]" gets upper 32 bits of u64,
>> + * but perf assumes it gets lower 32bits of u64. Hence the check
>> + * and swap.
>> + */
>> +bitmap_from_u64(_mask, mask);
>> +for_each_set_bit(r, _mask, sizeof(mask) * 8) {
>>  u64 val = regs->regs[i++];
>>  printf("%5s:0x%"PRIx64" ", perf_reg_name(r), val);
>>  }
>> diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
>> index 5214974e841a..1337b1c73f82 100644
>> --- a/tools/perf/util/session.c
>> +++ b/tools/perf/util/session.c
>> @@ -940,8 +940,22 @@ static void branch_stack__printf(struct perf_sample 
>> *sample)
>>  static void regs_dump__printf(u64 mask, u64 *regs)
>>  {
>>  unsigned rid, i = 0;
>> +unsigned long _mask[sizeof(mask)/sizeof(unsigned long)];
>>  
>> -for_each_set_bit(rid, (unsigned long *) , sizeof(mask) * 8) {
>> +/*
>> + * Since u64 

[PATCH V2 4/4] stm: Mark the functions of writing buffer with notrace

[Chunyan Zhang]

If CONFIG_STM_FTRACE is selected, Function trace data would be
writen to STM buffer, all  functions that related to writing data
packets to STM buffer should be marked 'notrace' to avoid being
traced by Ftrace, otherwise the program would stall into an endless loop.

Signed-off-by: Chunyan Zhang 
Acked-by: Steven Rostedt 
---
 drivers/hwtracing/coresight/coresight-stm.c |  2 +-
 drivers/hwtracing/intel_th/sth.c| 11 +++
 drivers/hwtracing/stm/core.c|  7 ---
 drivers/hwtracing/stm/dummy_stm.c   |  2 +-
 include/linux/stm.h |  4 ++--
 5 files changed, 15 insertions(+), 11 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-stm.c 
b/drivers/hwtracing/coresight/coresight-stm.c
index 73be58a..345c81e 100644
--- a/drivers/hwtracing/coresight/coresight-stm.c
+++ b/drivers/hwtracing/coresight/coresight-stm.c
@@ -386,7 +386,7 @@ static long stm_generic_set_options(struct stm_data 
*stm_data,
return 0;
 }
 
-static ssize_t stm_generic_packet(struct stm_data *stm_data,
+static ssize_t notrace stm_generic_packet(struct stm_data *stm_data,
  unsigned int master,
  unsigned int channel,
  unsigned int packet,
diff --git a/drivers/hwtracing/intel_th/sth.c b/drivers/hwtracing/intel_th/sth.c
index e1aee61..b034446 100644
--- a/drivers/hwtracing/intel_th/sth.c
+++ b/drivers/hwtracing/intel_th/sth.c
@@ -67,10 +67,13 @@ static void sth_iowrite(void __iomem *dest, const unsigned 
char *payload,
}
 }
 
-static ssize_t sth_stm_packet(struct stm_data *stm_data, unsigned int master,
- unsigned int channel, unsigned int packet,
- unsigned int flags, unsigned int size,
- const unsigned char *payload)
+static ssize_t notrace sth_stm_packet(struct stm_data *stm_data,
+ unsigned int master,
+ unsigned int channel,
+ unsigned int packet,
+ unsigned int flags,
+ unsigned int size,
+ const unsigned char *payload)
 {
struct sth_device *sth = container_of(stm_data, struct sth_device, stm);
struct intel_th_channel __iomem *out =
diff --git a/drivers/hwtracing/stm/core.c b/drivers/hwtracing/stm/core.c
index ff31108..3139b01 100644
--- a/drivers/hwtracing/stm/core.c
+++ b/drivers/hwtracing/stm/core.c
@@ -424,7 +424,7 @@ static int stm_file_assign(struct stm_file *stmf, char *id, 
unsigned int width)
return ret;
 }
 
-static ssize_t stm_write(struct stm_data *data, unsigned int master,
+static ssize_t notrace stm_write(struct stm_data *data, unsigned int master,
  unsigned int channel, const char *buf, size_t count)
 {
unsigned int flags = STP_PACKET_TIMESTAMPED;
@@ -1069,8 +1069,9 @@ void stm_source_unregister_device(struct stm_source_data 
*data)
 }
 EXPORT_SYMBOL_GPL(stm_source_unregister_device);
 
-int stm_source_write(struct stm_source_data *data, unsigned int chan,
-const char *buf, size_t count)
+int notrace stm_source_write(struct stm_source_data *data,
+unsigned int chan,
+const char *buf, size_t count)
 {
struct stm_source_device *src = data->src;
struct stm_device *stm;
diff --git a/drivers/hwtracing/stm/dummy_stm.c 
b/drivers/hwtracing/stm/dummy_stm.c
index a86612d..c5f94ca 100644
--- a/drivers/hwtracing/stm/dummy_stm.c
+++ b/drivers/hwtracing/stm/dummy_stm.c
@@ -21,7 +21,7 @@
 #include 
 #include 
 
-static ssize_t
+static ssize_t notrace
 dummy_stm_packet(struct stm_data *stm_data, unsigned int master,
 unsigned int channel, unsigned int packet, unsigned int flags,
 unsigned int size, const unsigned char *payload)
diff --git a/include/linux/stm.h b/include/linux/stm.h
index 2b6639a..80c60da 100644
--- a/include/linux/stm.h
+++ b/include/linux/stm.h
@@ -140,7 +140,7 @@ int stm_source_register_device(struct device *parent,
   struct stm_source_data *data);
 void stm_source_unregister_device(struct stm_source_data *data);
 
-int stm_source_write(struct stm_source_data *data, unsigned int chan,
-const char *buf, size_t count);
+int notrace stm_source_write(struct stm_source_data *data, unsigned int chan,
+const char *buf, size_t count);
 
 #endif /* _STM_H_ */
-- 
1.9.1

[PATCH V2 4/4] stm: Mark the functions of writing buffer with notrace

[Chunyan Zhang]

If CONFIG_STM_FTRACE is selected, Function trace data would be
writen to STM buffer, all  functions that related to writing data
packets to STM buffer should be marked 'notrace' to avoid being
traced by Ftrace, otherwise the program would stall into an endless loop.

Signed-off-by: Chunyan Zhang 
Acked-by: Steven Rostedt 
---
 drivers/hwtracing/coresight/coresight-stm.c |  2 +-
 drivers/hwtracing/intel_th/sth.c| 11 +++
 drivers/hwtracing/stm/core.c|  7 ---
 drivers/hwtracing/stm/dummy_stm.c   |  2 +-
 include/linux/stm.h |  4 ++--
 5 files changed, 15 insertions(+), 11 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-stm.c 
b/drivers/hwtracing/coresight/coresight-stm.c
index 73be58a..345c81e 100644
--- a/drivers/hwtracing/coresight/coresight-stm.c
+++ b/drivers/hwtracing/coresight/coresight-stm.c
@@ -386,7 +386,7 @@ static long stm_generic_set_options(struct stm_data 
*stm_data,
return 0;
 }
 
-static ssize_t stm_generic_packet(struct stm_data *stm_data,
+static ssize_t notrace stm_generic_packet(struct stm_data *stm_data,
  unsigned int master,
  unsigned int channel,
  unsigned int packet,
diff --git a/drivers/hwtracing/intel_th/sth.c b/drivers/hwtracing/intel_th/sth.c
index e1aee61..b034446 100644
--- a/drivers/hwtracing/intel_th/sth.c
+++ b/drivers/hwtracing/intel_th/sth.c
@@ -67,10 +67,13 @@ static void sth_iowrite(void __iomem *dest, const unsigned 
char *payload,
}
 }
 
-static ssize_t sth_stm_packet(struct stm_data *stm_data, unsigned int master,
- unsigned int channel, unsigned int packet,
- unsigned int flags, unsigned int size,
- const unsigned char *payload)
+static ssize_t notrace sth_stm_packet(struct stm_data *stm_data,
+ unsigned int master,
+ unsigned int channel,
+ unsigned int packet,
+ unsigned int flags,
+ unsigned int size,
+ const unsigned char *payload)
 {
struct sth_device *sth = container_of(stm_data, struct sth_device, stm);
struct intel_th_channel __iomem *out =
diff --git a/drivers/hwtracing/stm/core.c b/drivers/hwtracing/stm/core.c
index ff31108..3139b01 100644
--- a/drivers/hwtracing/stm/core.c
+++ b/drivers/hwtracing/stm/core.c
@@ -424,7 +424,7 @@ static int stm_file_assign(struct stm_file *stmf, char *id, 
unsigned int width)
return ret;
 }
 
-static ssize_t stm_write(struct stm_data *data, unsigned int master,
+static ssize_t notrace stm_write(struct stm_data *data, unsigned int master,
  unsigned int channel, const char *buf, size_t count)
 {
unsigned int flags = STP_PACKET_TIMESTAMPED;
@@ -1069,8 +1069,9 @@ void stm_source_unregister_device(struct stm_source_data 
*data)
 }
 EXPORT_SYMBOL_GPL(stm_source_unregister_device);
 
-int stm_source_write(struct stm_source_data *data, unsigned int chan,
-const char *buf, size_t count)
+int notrace stm_source_write(struct stm_source_data *data,
+unsigned int chan,
+const char *buf, size_t count)
 {
struct stm_source_device *src = data->src;
struct stm_device *stm;
diff --git a/drivers/hwtracing/stm/dummy_stm.c 
b/drivers/hwtracing/stm/dummy_stm.c
index a86612d..c5f94ca 100644
--- a/drivers/hwtracing/stm/dummy_stm.c
+++ b/drivers/hwtracing/stm/dummy_stm.c
@@ -21,7 +21,7 @@
 #include 
 #include 
 
-static ssize_t
+static ssize_t notrace
 dummy_stm_packet(struct stm_data *stm_data, unsigned int master,
 unsigned int channel, unsigned int packet, unsigned int flags,
 unsigned int size, const unsigned char *payload)
diff --git a/include/linux/stm.h b/include/linux/stm.h
index 2b6639a..80c60da 100644
--- a/include/linux/stm.h
+++ b/include/linux/stm.h
@@ -140,7 +140,7 @@ int stm_source_register_device(struct device *parent,
   struct stm_source_data *data);
 void stm_source_unregister_device(struct stm_source_data *data);
 
-int stm_source_write(struct stm_source_data *data, unsigned int chan,
-const char *buf, size_t count);
+int notrace stm_source_write(struct stm_source_data *data, unsigned int chan,
+const char *buf, size_t count);
 
 #endif /* _STM_H_ */
-- 
1.9.1

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Peter Chen]

On Tue, Jun 21, 2016 at 05:47:47PM +0300, Felipe Balbi wrote:
> 
> Hi,
> 
> Peter Chen  writes:
> >> >> >> >> >>> + * @otg_dev: OTG controller device, if needs to be used with 
> >> >> >> >> >>> OTG core.
> >> >> >> >> >> 
> >> >> >> >> >> do you really know of any platform which has a separate OTG 
> >> >> >> >> >> controller?
> >> >> >> >> >> 
> >> >> >> >> >
> >> >> >> >> > Andrew had pointed out in [1] that Tegra210 has separate blocks 
> >> >> >> >> > for OTG, host
> >> >> >> >> > and gadget.
> >> >> >> >> >
> >> >> >> >> > [1] http://article.gmane.org/gmane.linux.ports.tegra/22969
> >> >> >> >> 
> >> >> >> >> that's not an OTG controller, it's just a mux. No different than 
> >> >> >> >> Intel's
> >> >> >> >> mux for swapping between XHCI and peripheral-only DWC3.
> >> >> >> >> 
> >> >> >> >> frankly, I would NEVER talk about OTG when type-C comes into 
> >> >> >> >> play. They
> >> >> >> >> are two competing standards and, apparently, type-C is winning 
> >> >> >> >> when it
> >> >> >> >> comes to role-swapping.
> >> >> >> >> 
> >> >> >> >
> >> >> >> > In fact, OTG is mis-used by people. Currently, if the port is 
> >> >> >> > dual-role,
> >> >> >> > It will be considered as an OTG port.
> >> >> >> 
> >> >> >> That's because "dual-role" is a non-standard OTG. Seen as people 
> >> >> >> really
> >> >> >> didn't care about OTG, we (linux-usb folks) ended up naturally 
> >> >> >> referring
> >> >> >> to "non-standard OTG" as "dual-role". Just to avoid confusion.
> >> >> >
> >> >> > So, unless we use OTG FSM defined in OTG spec, we should not mention
> >> >> > "OTG" in Linux, right?
> >> >> 
> >> >> to avoid confusion with the terminology, yes. With that settled, let's
> >> >> figure out how you can deliver what your marketting guys are asking of
> >> >> you.
> >> >> 
> >> >
> >> > Since nxp SoC claims they are OTG compliance, we need to pass usb.org
> >> > test. The internal bsp has passed PET test, and formal compliance test
> >> > is on the way (should pass too). 
> >> >
> >> > The dual-role and OTG compliance use the same zImage, but different
> >> > dtb.
> >> 
> >> okay, that's good to know. Now, the question really is: considering we
> >> only have one user for this generic OTG FSM layer, do we really need to
> >> make it generic at all? I mean, just look at how invasive a change that
> >> is.
> >
> > If the chipidea is the only user for this roger's framework, I don't
> > think it is necessary. In fact, Roger introduces this framework, and
> > the first user is dwc3, we think it can be used for others. Let's
> 
> Right, we need to look at the history of dwc3 to figure out why the
> conclusion that dwc3 needs this was made.
> 
> Roger started working on this framework when Power on Reset section of
> databook had some details which weren't always clear and, for safety, we
> always had reset asserted for a really long time. It was so long (about
> 400 ms) that resetting dwc3 for each role swap was just too much.
> 
> Coupled with that, the OTG chapter wasn't very clear either on
> expections from Host and Peripheral side initialization in OTG/DRD
> systems.
> 
> More recent version of dwc3 databook have a much better description of
> how and which reset bits _must_ be asserted and which shouldn't be
> touched unless it's for debugging purposes. When I implemented that, our
> ->probe() went from 400ms down to about 50us.
> 
> Coupled with that, the OTG chapter also became a lot clearer to the
> point that it states you just don't initialize anything other than the
> OTG block, and just wait for OTG interrupt to do whatever it is you need
> to do.
> 
> This meant that we could actually afford to do full reinitialization of
> dwc3 on role swap (it's now only 50us anyway) and we knew how to swap
> roles properly.
> 
> (The reason for needing soft-reset during role swap is kinda long. But
> in summary dwc3 shadows register writes to both host and peripheral
> sides)
> 
> > just discuss if it is necessary for dual-role switch.
> 
> fair. However, if we have a single user we don't have a Generic
> layer. There's not enough variance to come up with truly generic
> architecture for this.
> 
> -- 

I have put some points in my last reply [1], I summery it here to
see if a generic framework is deserved or not?

1. If there are some parts we can use during the role switch
- The common start/stop host and peripheral operation
eg, when switch from host to peripheral, all drivers can use
usb_remove_hcd to finish it.
- A common workqueue to handle vbus and id event
- sysfs for role switch

2. Does a mux driver can do it well? Yoshihiro, here we need your
point. The main point is if we need to call USB API to change
roles (eg, usb_remove_hcd) during the role switch, thanks.


[1] http://www.spinics.net/lists/linux-usb/msg142974.html
-- 

Best Regards,
Peter Chen

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Peter Chen]

On Tue, Jun 21, 2016 at 05:47:47PM +0300, Felipe Balbi wrote:
> 
> Hi,
> 
> Peter Chen  writes:
> >> >> >> >> >>> + * @otg_dev: OTG controller device, if needs to be used with 
> >> >> >> >> >>> OTG core.
> >> >> >> >> >> 
> >> >> >> >> >> do you really know of any platform which has a separate OTG 
> >> >> >> >> >> controller?
> >> >> >> >> >> 
> >> >> >> >> >
> >> >> >> >> > Andrew had pointed out in [1] that Tegra210 has separate blocks 
> >> >> >> >> > for OTG, host
> >> >> >> >> > and gadget.
> >> >> >> >> >
> >> >> >> >> > [1] http://article.gmane.org/gmane.linux.ports.tegra/22969
> >> >> >> >> 
> >> >> >> >> that's not an OTG controller, it's just a mux. No different than 
> >> >> >> >> Intel's
> >> >> >> >> mux for swapping between XHCI and peripheral-only DWC3.
> >> >> >> >> 
> >> >> >> >> frankly, I would NEVER talk about OTG when type-C comes into 
> >> >> >> >> play. They
> >> >> >> >> are two competing standards and, apparently, type-C is winning 
> >> >> >> >> when it
> >> >> >> >> comes to role-swapping.
> >> >> >> >> 
> >> >> >> >
> >> >> >> > In fact, OTG is mis-used by people. Currently, if the port is 
> >> >> >> > dual-role,
> >> >> >> > It will be considered as an OTG port.
> >> >> >> 
> >> >> >> That's because "dual-role" is a non-standard OTG. Seen as people 
> >> >> >> really
> >> >> >> didn't care about OTG, we (linux-usb folks) ended up naturally 
> >> >> >> referring
> >> >> >> to "non-standard OTG" as "dual-role". Just to avoid confusion.
> >> >> >
> >> >> > So, unless we use OTG FSM defined in OTG spec, we should not mention
> >> >> > "OTG" in Linux, right?
> >> >> 
> >> >> to avoid confusion with the terminology, yes. With that settled, let's
> >> >> figure out how you can deliver what your marketting guys are asking of
> >> >> you.
> >> >> 
> >> >
> >> > Since nxp SoC claims they are OTG compliance, we need to pass usb.org
> >> > test. The internal bsp has passed PET test, and formal compliance test
> >> > is on the way (should pass too). 
> >> >
> >> > The dual-role and OTG compliance use the same zImage, but different
> >> > dtb.
> >> 
> >> okay, that's good to know. Now, the question really is: considering we
> >> only have one user for this generic OTG FSM layer, do we really need to
> >> make it generic at all? I mean, just look at how invasive a change that
> >> is.
> >
> > If the chipidea is the only user for this roger's framework, I don't
> > think it is necessary. In fact, Roger introduces this framework, and
> > the first user is dwc3, we think it can be used for others. Let's
> 
> Right, we need to look at the history of dwc3 to figure out why the
> conclusion that dwc3 needs this was made.
> 
> Roger started working on this framework when Power on Reset section of
> databook had some details which weren't always clear and, for safety, we
> always had reset asserted for a really long time. It was so long (about
> 400 ms) that resetting dwc3 for each role swap was just too much.
> 
> Coupled with that, the OTG chapter wasn't very clear either on
> expections from Host and Peripheral side initialization in OTG/DRD
> systems.
> 
> More recent version of dwc3 databook have a much better description of
> how and which reset bits _must_ be asserted and which shouldn't be
> touched unless it's for debugging purposes. When I implemented that, our
> ->probe() went from 400ms down to about 50us.
> 
> Coupled with that, the OTG chapter also became a lot clearer to the
> point that it states you just don't initialize anything other than the
> OTG block, and just wait for OTG interrupt to do whatever it is you need
> to do.
> 
> This meant that we could actually afford to do full reinitialization of
> dwc3 on role swap (it's now only 50us anyway) and we knew how to swap
> roles properly.
> 
> (The reason for needing soft-reset during role swap is kinda long. But
> in summary dwc3 shadows register writes to both host and peripheral
> sides)
> 
> > just discuss if it is necessary for dual-role switch.
> 
> fair. However, if we have a single user we don't have a Generic
> layer. There's not enough variance to come up with truly generic
> architecture for this.
> 
> -- 

I have put some points in my last reply [1], I summery it here to
see if a generic framework is deserved or not?

1. If there are some parts we can use during the role switch
- The common start/stop host and peripheral operation
eg, when switch from host to peripheral, all drivers can use
usb_remove_hcd to finish it.
- A common workqueue to handle vbus and id event
- sysfs for role switch

2. Does a mux driver can do it well? Yoshihiro, here we need your
point. The main point is if we need to call USB API to change
roles (eg, usb_remove_hcd) during the role switch, thanks.


[1] http://www.spinics.net/lists/linux-usb/msg142974.html
-- 

Best Regards,
Peter Chen

[PATCH] dm: Check kthread_run's return value

[Minfei Huang]

kthread function is used to process kthread_work. And there is no return
value checking during create this thread. Add this checking to fix this
issue.

Signed-off-by: Minfei Huang 
Signed-off-by: Minfei Huang 
---
 drivers/md/dm.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/md/dm.c b/drivers/md/dm.c
index 1b2f962..d68b9d2 100644
--- a/drivers/md/dm.c
+++ b/drivers/md/dm.c
@@ -2654,12 +2654,15 @@ struct queue_limits *dm_get_queue_limits(struct 
mapped_device *md)
 }
 EXPORT_SYMBOL_GPL(dm_get_queue_limits);
 
-static void dm_old_init_rq_based_worker_thread(struct mapped_device *md)
+static int dm_old_init_rq_based_worker_thread(struct mapped_device *md)
 {
/* Initialize the request-based DM worker thread */
init_kthread_worker(>kworker);
md->kworker_task = kthread_run(kthread_worker_fn, >kworker,
   "kdmwork-%s", dm_device_name(md));
+   if (IS_ERR(md->kworker_task))
+   return -ENOMEM;
+   return 0;
 }
 
 /*
@@ -2667,6 +2670,8 @@ static void dm_old_init_rq_based_worker_thread(struct 
mapped_device *md)
  */
 static int dm_old_init_request_queue(struct mapped_device *md)
 {
+   int ret;
+
/* Fully initialize the queue */
if (!blk_init_allocated_queue(md->queue, dm_request_fn, NULL))
return -EINVAL;
@@ -2678,7 +2683,9 @@ static int dm_old_init_request_queue(struct mapped_device 
*md)
blk_queue_softirq_done(md->queue, dm_softirq_done);
blk_queue_prep_rq(md->queue, dm_old_prep_fn);
 
-   dm_old_init_rq_based_worker_thread(md);
+   ret = dm_old_init_rq_based_worker_thread(md);
+   if (ret < 0)
+   return ret;
 
elv_register_queue(md->queue);
 
-- 
2.7.4 (Apple Git-66)

[PATCH] dm: Check kthread_run's return value

[Minfei Huang]

kthread function is used to process kthread_work. And there is no return
value checking during create this thread. Add this checking to fix this
issue.

Signed-off-by: Minfei Huang 
Signed-off-by: Minfei Huang 
---
 drivers/md/dm.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/md/dm.c b/drivers/md/dm.c
index 1b2f962..d68b9d2 100644
--- a/drivers/md/dm.c
+++ b/drivers/md/dm.c
@@ -2654,12 +2654,15 @@ struct queue_limits *dm_get_queue_limits(struct 
mapped_device *md)
 }
 EXPORT_SYMBOL_GPL(dm_get_queue_limits);
 
-static void dm_old_init_rq_based_worker_thread(struct mapped_device *md)
+static int dm_old_init_rq_based_worker_thread(struct mapped_device *md)
 {
/* Initialize the request-based DM worker thread */
init_kthread_worker(>kworker);
md->kworker_task = kthread_run(kthread_worker_fn, >kworker,
   "kdmwork-%s", dm_device_name(md));
+   if (IS_ERR(md->kworker_task))
+   return -ENOMEM;
+   return 0;
 }
 
 /*
@@ -2667,6 +2670,8 @@ static void dm_old_init_rq_based_worker_thread(struct 
mapped_device *md)
  */
 static int dm_old_init_request_queue(struct mapped_device *md)
 {
+   int ret;
+
/* Fully initialize the queue */
if (!blk_init_allocated_queue(md->queue, dm_request_fn, NULL))
return -EINVAL;
@@ -2678,7 +2683,9 @@ static int dm_old_init_request_queue(struct mapped_device 
*md)
blk_queue_softirq_done(md->queue, dm_softirq_done);
blk_queue_prep_rq(md->queue, dm_old_prep_fn);
 
-   dm_old_init_rq_based_worker_thread(md);
+   ret = dm_old_init_rq_based_worker_thread(md);
+   if (ret < 0)
+   return ret;
 
elv_register_queue(md->queue);
 
-- 
2.7.4 (Apple Git-66)

[PATCH v2] PCI/MSI: Simplify the return value of arch_setup_msi_irqs

[Shawn Lin]

No any callers do care whether arch_setup_msi_irqs returns
-ENOSPC or other error numbers. That means they treat the
negative numbers in the same way. So there shouldn't make any
difference to directly return -ENOSPC if finding it's non-zero.

Signed-off-by: Shawn Lin 

---

Changes in v2:
- fix warning generated by -Wmisleading-indentation reported by Kbuild robot

 drivers/pci/msi.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index a080f44..5057219 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -108,7 +108,7 @@ int __weak arch_setup_msi_irqs(struct pci_dev *dev, int 
nvec, int type)
 {
struct msi_controller *chip = dev->bus->msi;
struct msi_desc *entry;
-   int ret;
+   int ret = 0;
 
if (chip && chip->setup_irqs)
return chip->setup_irqs(chip, dev, nvec, type);
@@ -121,9 +121,7 @@ int __weak arch_setup_msi_irqs(struct pci_dev *dev, int 
nvec, int type)
 
for_each_pci_msi_entry(entry, dev) {
ret = arch_setup_msi_irq(dev, entry);
-   if (ret < 0)
-   return ret;
-   if (ret > 0)
+   if (ret)
return -ENOSPC;
}
 
-- 
2.3.7

[PATCH v2] PCI/MSI: Simplify the return value of arch_setup_msi_irqs

[Shawn Lin]

No any callers do care whether arch_setup_msi_irqs returns
-ENOSPC or other error numbers. That means they treat the
negative numbers in the same way. So there shouldn't make any
difference to directly return -ENOSPC if finding it's non-zero.

Signed-off-by: Shawn Lin 

---

Changes in v2:
- fix warning generated by -Wmisleading-indentation reported by Kbuild robot

 drivers/pci/msi.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index a080f44..5057219 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -108,7 +108,7 @@ int __weak arch_setup_msi_irqs(struct pci_dev *dev, int 
nvec, int type)
 {
struct msi_controller *chip = dev->bus->msi;
struct msi_desc *entry;
-   int ret;
+   int ret = 0;
 
if (chip && chip->setup_irqs)
return chip->setup_irqs(chip, dev, nvec, type);
@@ -121,9 +121,7 @@ int __weak arch_setup_msi_irqs(struct pci_dev *dev, int 
nvec, int type)
 
for_each_pci_msi_entry(entry, dev) {
ret = arch_setup_msi_irq(dev, entry);
-   if (ret < 0)
-   return ret;
-   if (ret > 0)
+   if (ret)
return -ENOSPC;
}
 
-- 
2.3.7

[RESEND PATCH v2 3/4] ARM: dts: rockchip: add GMAC nodes for RK322x SoCs

[Xing Zheng]

This patch add the GMAC dt nodes for rk322x SoCs.

Signed-off-by: Xing Zheng 

---

Changes in v2: None

 arch/arm/boot/dts/rk322x.dtsi |   64 +
 1 file changed, 64 insertions(+)

diff --git a/arch/arm/boot/dts/rk322x.dtsi b/arch/arm/boot/dts/rk322x.dtsi
index d5626705..a9cbef9 100644
--- a/arch/arm/boot/dts/rk322x.dtsi
+++ b/arch/arm/boot/dts/rk322x.dtsi
@@ -415,6 +415,28 @@
status = "disabled";
};
 
+   gmac: eth@3020 {
+   compatible = "rockchip,rk3228-gmac";
+   reg = <0x3020 0x1>;
+   rockchip,grf = <>;
+   interrupts = ;
+   interrupt-names = "macirq";
+   clocks = < SCLK_MAC>, < SCLK_MAC_RX>,
+   < SCLK_MAC_TX>, < SCLK_MAC_REF>,
+   < SCLK_MAC_REFOUT>, < ACLK_GMAC>,
+   < PCLK_GMAC>;
+   clock-names = "stmmaceth", "mac_clk_rx",
+   "mac_clk_tx", "clk_mac_ref",
+   "clk_mac_refout", "aclk_mac",
+   "pclk_mac";
+   resets = < SRST_GMAC>;
+   reset-names = "stmmaceth";
+   phy-mode = "rgmii";
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   status = "disabled";
+   };
+
gic: interrupt-controller@3201 {
compatible = "arm,gic-400";
interrupt-controller;
@@ -499,6 +521,10 @@
bias-disable;
};
 
+   pcfg_pull_none_drv_12ma: pcfg-pull-none-drv-12ma {
+   drive-strength = <12>;
+   };
+
emmc {
emmc_clk: emmc-clk {
rockchip,pins = <2 7 RK_FUNC_2 _pull_none>;
@@ -520,6 +546,44 @@
};
};
 
+   gmac {
+   rgmii_pins: rgmii-pins {
+   rockchip,pins = <2 14 RK_FUNC_1 
_pull_none>,
+   <2 12 RK_FUNC_1 
_pull_none>,
+   <2 25 RK_FUNC_1 
_pull_none>,
+   <2 19 RK_FUNC_1 
_pull_none_drv_12ma>,
+   <2 18 RK_FUNC_1 
_pull_none_drv_12ma>,
+   <2 22 RK_FUNC_1 
_pull_none_drv_12ma>,
+   <2 23 RK_FUNC_1 
_pull_none_drv_12ma>,
+   <2 9 RK_FUNC_1 
_pull_none_drv_12ma>,
+   <2 13 RK_FUNC_1 
_pull_none_drv_12ma>,
+   <2 17 RK_FUNC_1 
_pull_none>,
+   <2 16 RK_FUNC_1 
_pull_none>,
+   <2 21 RK_FUNC_2 
_pull_none>,
+   <2 20 RK_FUNC_2 
_pull_none>,
+   <2 11 RK_FUNC_1 
_pull_none>,
+   <2 8 RK_FUNC_1 _pull_none>;
+   };
+
+   rmii_pins: rmii-pins {
+   rockchip,pins = <2 14 RK_FUNC_1 
_pull_none>,
+   <2 12 RK_FUNC_1 
_pull_none>,
+   <2 25 RK_FUNC_1 
_pull_none>,
+   <2 19 RK_FUNC_1 
_pull_none_drv_12ma>,
+   <2 18 RK_FUNC_1 
_pull_none_drv_12ma>,
+   <2 13 RK_FUNC_1 
_pull_none_drv_12ma>,
+   <2 17 RK_FUNC_1 
_pull_none>,
+   <2 16 RK_FUNC_1 
_pull_none>,
+   <2 8 RK_FUNC_1 _pull_none>,
+   <2 15 RK_FUNC_1 
_pull_none>;
+   };
+
+   phy_pins: phy-pins {
+   rockchip,pins = <2 14 RK_FUNC_2 
_pull_none>,
+   <2 8 RK_FUNC_2 _pull_none>;
+   };
+   };
+
i2c0 {
i2c0_xfer: i2c0-xfer {
rockchip,pins = <0 0 RK_FUNC_1 _pull_none>,
-- 
1.7.9.5

[RESEND PATCH v2 3/4] ARM: dts: rockchip: add GMAC nodes for RK322x SoCs

[Xing Zheng]

This patch add the GMAC dt nodes for rk322x SoCs.

Signed-off-by: Xing Zheng 

---

Changes in v2: None

 arch/arm/boot/dts/rk322x.dtsi |   64 +
 1 file changed, 64 insertions(+)

diff --git a/arch/arm/boot/dts/rk322x.dtsi b/arch/arm/boot/dts/rk322x.dtsi
index d5626705..a9cbef9 100644
--- a/arch/arm/boot/dts/rk322x.dtsi
+++ b/arch/arm/boot/dts/rk322x.dtsi
@@ -415,6 +415,28 @@
status = "disabled";
};
 
+   gmac: eth@3020 {
+   compatible = "rockchip,rk3228-gmac";
+   reg = <0x3020 0x1>;
+   rockchip,grf = <>;
+   interrupts = ;
+   interrupt-names = "macirq";
+   clocks = < SCLK_MAC>, < SCLK_MAC_RX>,
+   < SCLK_MAC_TX>, < SCLK_MAC_REF>,
+   < SCLK_MAC_REFOUT>, < ACLK_GMAC>,
+   < PCLK_GMAC>;
+   clock-names = "stmmaceth", "mac_clk_rx",
+   "mac_clk_tx", "clk_mac_ref",
+   "clk_mac_refout", "aclk_mac",
+   "pclk_mac";
+   resets = < SRST_GMAC>;
+   reset-names = "stmmaceth";
+   phy-mode = "rgmii";
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   status = "disabled";
+   };
+
gic: interrupt-controller@3201 {
compatible = "arm,gic-400";
interrupt-controller;
@@ -499,6 +521,10 @@
bias-disable;
};
 
+   pcfg_pull_none_drv_12ma: pcfg-pull-none-drv-12ma {
+   drive-strength = <12>;
+   };
+
emmc {
emmc_clk: emmc-clk {
rockchip,pins = <2 7 RK_FUNC_2 _pull_none>;
@@ -520,6 +546,44 @@
};
};
 
+   gmac {
+   rgmii_pins: rgmii-pins {
+   rockchip,pins = <2 14 RK_FUNC_1 
_pull_none>,
+   <2 12 RK_FUNC_1 
_pull_none>,
+   <2 25 RK_FUNC_1 
_pull_none>,
+   <2 19 RK_FUNC_1 
_pull_none_drv_12ma>,
+   <2 18 RK_FUNC_1 
_pull_none_drv_12ma>,
+   <2 22 RK_FUNC_1 
_pull_none_drv_12ma>,
+   <2 23 RK_FUNC_1 
_pull_none_drv_12ma>,
+   <2 9 RK_FUNC_1 
_pull_none_drv_12ma>,
+   <2 13 RK_FUNC_1 
_pull_none_drv_12ma>,
+   <2 17 RK_FUNC_1 
_pull_none>,
+   <2 16 RK_FUNC_1 
_pull_none>,
+   <2 21 RK_FUNC_2 
_pull_none>,
+   <2 20 RK_FUNC_2 
_pull_none>,
+   <2 11 RK_FUNC_1 
_pull_none>,
+   <2 8 RK_FUNC_1 _pull_none>;
+   };
+
+   rmii_pins: rmii-pins {
+   rockchip,pins = <2 14 RK_FUNC_1 
_pull_none>,
+   <2 12 RK_FUNC_1 
_pull_none>,
+   <2 25 RK_FUNC_1 
_pull_none>,
+   <2 19 RK_FUNC_1 
_pull_none_drv_12ma>,
+   <2 18 RK_FUNC_1 
_pull_none_drv_12ma>,
+   <2 13 RK_FUNC_1 
_pull_none_drv_12ma>,
+   <2 17 RK_FUNC_1 
_pull_none>,
+   <2 16 RK_FUNC_1 
_pull_none>,
+   <2 8 RK_FUNC_1 _pull_none>,
+   <2 15 RK_FUNC_1 
_pull_none>;
+   };
+
+   phy_pins: phy-pins {
+   rockchip,pins = <2 14 RK_FUNC_2 
_pull_none>,
+   <2 8 RK_FUNC_2 _pull_none>;
+   };
+   };
+
i2c0 {
i2c0_xfer: i2c0-xfer {
rockchip,pins = <0 0 RK_FUNC_1 _pull_none>,
-- 
1.7.9.5

[RESEND PATCH v2 4/4] ARM: dts: rockchip: add support rk3229 evb board

[Xing Zheng]

Initial release for rk3229 evb board, and turn the GMAC on.

Signed-off-by: Xing Zheng 

---

Changes in v2:
- rename rk3228.dtsi to rk322x.dtsi

 arch/arm/boot/dts/Makefile   |1 +
 arch/arm/boot/dts/rk3229-evb.dts |   90 ++
 arch/arm/boot/dts/rk3229.dtsi|   45 +++
 3 files changed, 136 insertions(+)
 create mode 100644 arch/arm/boot/dts/rk3229-evb.dts
 create mode 100644 arch/arm/boot/dts/rk3229.dtsi

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 06b6c2d..5e0833f 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -602,6 +602,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
rk3066a-rayeager.dtb \
rk3188-radxarock.dtb \
rk3228-evb.dtb \
+   rk3229-evb.dtb \
rk3288-evb-act8846.dtb \
rk3288-evb-rk808.dtb \
rk3288-firefly-beta.dtb \
diff --git a/arch/arm/boot/dts/rk3229-evb.dts b/arch/arm/boot/dts/rk3229-evb.dts
new file mode 100644
index 000..77a46c7
--- /dev/null
+++ b/arch/arm/boot/dts/rk3229-evb.dts
@@ -0,0 +1,90 @@
+/*
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ *  Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "rk3229.dtsi"
+
+/ {
+   model = "Rockchip RK3229 Evaluation board";
+   compatible = "rockchip,rk3229-evb", "rockchip,rk3229";
+
+   memory {
+   device_type = "memory";
+   reg = <0x6000 0x4000>;
+   };
+
+   ext_gmac: ext_gmac {
+   compatible = "fixed-clock";
+   clock-frequency = <12500>;
+   clock-output-names = "ext_gmac";
+   #clock-cells = <0>;
+   };
+
+   vcc_phy: vcc-phy-regulator {
+   compatible = "regulator-fixed";
+   enable-active-high;
+   regulator-name = "vcc_phy";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+};
+
+ {
+   phy-supply = <_phy>;
+   phy-mode = "rgmii";
+   clock_in_out = "input";
+   snps,reset-gpio = < 24 GPIO_ACTIVE_LOW>;
+   snps,reset-active-low;
+   snps,reset-delays-us = <0 1 100>;
+   assigned-clocks = < SCLK_MAC_EXTCLK>, < SCLK_MAC>;
+   assigned-clock-parents = <_gmac>, < SCLK_MAC_EXTCLK>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   tx_delay = <0x30>;
+   rx_delay = <0x10>;
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
diff --git a/arch/arm/boot/dts/rk3229.dtsi b/arch/arm/boot/dts/rk3229.dtsi
new file mode 100644
index 000..35ca047
--- /dev/null
+++ b/arch/arm/boot/dts/rk3229.dtsi
@@ -0,0 +1,45 @@
+/*
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the 

[RESEND PATCH v2 0/4] Add support i2s/spdif/gmac features for RK322x SoCs

[Xing Zheng]

Hi,
  We have the brother chipset product that RK3228 and RK3229,
They have many common configuration, but there are a number
of different features. In order to develop the future when they
are easy to distinguish, we need them to be independent.
  And, these patchset add i2s/gmac dts nodes for RK322x SoCs,
and add the new dts file of the rk3229 evb board.

Thanks.

Changes in v2:
- rename rk3228.dtsi to rk322x.dtsi

Xing Zheng (4):
  ARM: dts: rockchip: rename rk3228.dtsi to rk322x.dtsi
  ARM: dts: rockchip: add i2s nodes for RK322x SoCs
  ARM: dts: rockchip: add GMAC nodes for RK322x SoCs
  ARM: dts: rockchip: add support rk3229 evb board

 arch/arm/boot/dts/Makefile   |1 +
 arch/arm/boot/dts/rk3228.dtsi|  548 +
 arch/arm/boot/dts/rk3229-evb.dts |   90 +
 arch/arm/boot/dts/rk3229.dtsi|   45 +++
 arch/arm/boot/dts/rk322x.dtsi|  708 ++
 5 files changed, 845 insertions(+), 547 deletions(-)
 create mode 100644 arch/arm/boot/dts/rk3229-evb.dts
 create mode 100644 arch/arm/boot/dts/rk3229.dtsi
 create mode 100644 arch/arm/boot/dts/rk322x.dtsi

-- 
1.7.9.5

[RESEND PATCH v2 1/4] ARM: dts: rockchip: rename rk3228.dtsi to rk322x.dtsi

[Xing Zheng]

We have the brother chipset that RK3228 and RK3229, they share most
of dts configuration, but there are a number of different features.
In order to develop the future when they are easy to distinguish,
we need them to be independent.

Signed-off-by: Xing Zheng 
---

Changes in v2: None

 arch/arm/boot/dts/rk3228.dtsi |  548 +-
 arch/arm/boot/dts/rk322x.dtsi |  589 +
 2 files changed, 590 insertions(+), 547 deletions(-)
 create mode 100644 arch/arm/boot/dts/rk322x.dtsi

diff --git a/arch/arm/boot/dts/rk3228.dtsi b/arch/arm/boot/dts/rk3228.dtsi
index e23a22e..e10f0b3 100644
--- a/arch/arm/boot/dts/rk3228.dtsi
+++ b/arch/arm/boot/dts/rk3228.dtsi
@@ -38,554 +38,8 @@
  * OTHER DEALINGS IN THE SOFTWARE.
  */
 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include "skeleton.dtsi"
+#include "rk322x.dtsi"
 
 / {
compatible = "rockchip,rk3228";
-
-   interrupt-parent = <>;
-
-   aliases {
-   serial0 = 
-   serial1 = 
-   serial2 = 
-   };
-
-   cpus {
-   #address-cells = <1>;
-   #size-cells = <0>;
-
-   cpu0: cpu@f00 {
-   device_type = "cpu";
-   compatible = "arm,cortex-a7";
-   reg = <0xf00>;
-   resets = < SRST_CORE0>;
-   operating-points = <
-   /* KHzuV */
-816000 100
-   >;
-   #cooling-cells = <2>; /* min followed by max */
-   clock-latency = <4>;
-   clocks = < ARMCLK>;
-   };
-
-   cpu1: cpu@f01 {
-   device_type = "cpu";
-   compatible = "arm,cortex-a7";
-   reg = <0xf01>;
-   resets = < SRST_CORE1>;
-   };
-
-   cpu2: cpu@f02 {
-   device_type = "cpu";
-   compatible = "arm,cortex-a7";
-   reg = <0xf02>;
-   resets = < SRST_CORE2>;
-   };
-
-   cpu3: cpu@f03 {
-   device_type = "cpu";
-   compatible = "arm,cortex-a7";
-   reg = <0xf03>;
-   resets = < SRST_CORE3>;
-   };
-   };
-
-   amba {
-   compatible = "simple-bus";
-   #address-cells = <1>;
-   #size-cells = <1>;
-   ranges;
-
-   pdma: pdma@110f {
-   compatible = "arm,pl330", "arm,primecell";
-   reg = <0x110f 0x4000>;
-   interrupts = ,
-;
-   #dma-cells = <1>;
-   clocks = < ACLK_DMAC>;
-   clock-names = "apb_pclk";
-   };
-   };
-
-   arm-pmu {
-   compatible = "arm,cortex-a7-pmu";
-   interrupts = ,
-,
-,
-;
-   interrupt-affinity = <>, <>, <>, <>;
-   };
-
-   timer {
-   compatible = "arm,armv7-timer";
-   arm,cpu-registers-not-fw-configured;
-   interrupts = ,
-,
-,
-;
-   clock-frequency = <2400>;
-   };
-
-   xin24m: oscillator {
-   compatible = "fixed-clock";
-   clock-frequency = <2400>;
-   clock-output-names = "xin24m";
-   #clock-cells = <0>;
-   };
-
-   grf: syscon@1100 {
-   compatible = "syscon";
-   reg = <0x1100 0x1000>;
-   };
-
-   uart0: serial@1101 {
-   compatible = "snps,dw-apb-uart";
-   reg = <0x1101 0x100>;
-   interrupts = ;
-   clock-frequency = <2400>;
-   clocks = < SCLK_UART0>, < PCLK_UART0>;
-   clock-names = "baudclk", "apb_pclk";
-   pinctrl-names = "default";
-   pinctrl-0 = <_xfer _cts _rts>;
-   reg-shift = <2>;
-   reg-io-width = <4>;
-   status = "disabled";
-   };
-
-   uart1: serial@1102 {
-   compatible = "snps,dw-apb-uart";
-   reg = <0x1102 0x100>;
-   interrupts = ;
-   clock-frequency = <2400>;
-   clocks = < SCLK_UART1>, < PCLK_UART1>;
-   clock-names = "baudclk", "apb_pclk";
-   pinctrl-names = "default";
-   pinctrl-0 = <_xfer>;
-   reg-shift = <2>;
-   reg-io-width = <4>;
-   status = "disabled";
-

[RESEND PATCH v2 1/4] ARM: dts: rockchip: rename rk3228.dtsi to rk322x.dtsi

[Xing Zheng]

We have the brother chipset that RK3228 and RK3229, they share most
of dts configuration, but there are a number of different features.
In order to develop the future when they are easy to distinguish,
we need them to be independent.

Signed-off-by: Xing Zheng 
---

Changes in v2: None

 arch/arm/boot/dts/rk3228.dtsi |  548 +-
 arch/arm/boot/dts/rk322x.dtsi |  589 +
 2 files changed, 590 insertions(+), 547 deletions(-)
 create mode 100644 arch/arm/boot/dts/rk322x.dtsi

diff --git a/arch/arm/boot/dts/rk3228.dtsi b/arch/arm/boot/dts/rk3228.dtsi
index e23a22e..e10f0b3 100644
--- a/arch/arm/boot/dts/rk3228.dtsi
+++ b/arch/arm/boot/dts/rk3228.dtsi
@@ -38,554 +38,8 @@
  * OTHER DEALINGS IN THE SOFTWARE.
  */
 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include "skeleton.dtsi"
+#include "rk322x.dtsi"
 
 / {
compatible = "rockchip,rk3228";
-
-   interrupt-parent = <>;
-
-   aliases {
-   serial0 = 
-   serial1 = 
-   serial2 = 
-   };
-
-   cpus {
-   #address-cells = <1>;
-   #size-cells = <0>;
-
-   cpu0: cpu@f00 {
-   device_type = "cpu";
-   compatible = "arm,cortex-a7";
-   reg = <0xf00>;
-   resets = < SRST_CORE0>;
-   operating-points = <
-   /* KHzuV */
-816000 100
-   >;
-   #cooling-cells = <2>; /* min followed by max */
-   clock-latency = <4>;
-   clocks = < ARMCLK>;
-   };
-
-   cpu1: cpu@f01 {
-   device_type = "cpu";
-   compatible = "arm,cortex-a7";
-   reg = <0xf01>;
-   resets = < SRST_CORE1>;
-   };
-
-   cpu2: cpu@f02 {
-   device_type = "cpu";
-   compatible = "arm,cortex-a7";
-   reg = <0xf02>;
-   resets = < SRST_CORE2>;
-   };
-
-   cpu3: cpu@f03 {
-   device_type = "cpu";
-   compatible = "arm,cortex-a7";
-   reg = <0xf03>;
-   resets = < SRST_CORE3>;
-   };
-   };
-
-   amba {
-   compatible = "simple-bus";
-   #address-cells = <1>;
-   #size-cells = <1>;
-   ranges;
-
-   pdma: pdma@110f {
-   compatible = "arm,pl330", "arm,primecell";
-   reg = <0x110f 0x4000>;
-   interrupts = ,
-;
-   #dma-cells = <1>;
-   clocks = < ACLK_DMAC>;
-   clock-names = "apb_pclk";
-   };
-   };
-
-   arm-pmu {
-   compatible = "arm,cortex-a7-pmu";
-   interrupts = ,
-,
-,
-;
-   interrupt-affinity = <>, <>, <>, <>;
-   };
-
-   timer {
-   compatible = "arm,armv7-timer";
-   arm,cpu-registers-not-fw-configured;
-   interrupts = ,
-,
-,
-;
-   clock-frequency = <2400>;
-   };
-
-   xin24m: oscillator {
-   compatible = "fixed-clock";
-   clock-frequency = <2400>;
-   clock-output-names = "xin24m";
-   #clock-cells = <0>;
-   };
-
-   grf: syscon@1100 {
-   compatible = "syscon";
-   reg = <0x1100 0x1000>;
-   };
-
-   uart0: serial@1101 {
-   compatible = "snps,dw-apb-uart";
-   reg = <0x1101 0x100>;
-   interrupts = ;
-   clock-frequency = <2400>;
-   clocks = < SCLK_UART0>, < PCLK_UART0>;
-   clock-names = "baudclk", "apb_pclk";
-   pinctrl-names = "default";
-   pinctrl-0 = <_xfer _cts _rts>;
-   reg-shift = <2>;
-   reg-io-width = <4>;
-   status = "disabled";
-   };
-
-   uart1: serial@1102 {
-   compatible = "snps,dw-apb-uart";
-   reg = <0x1102 0x100>;
-   interrupts = ;
-   clock-frequency = <2400>;
-   clocks = < SCLK_UART1>, < PCLK_UART1>;
-   clock-names = "baudclk", "apb_pclk";
-   pinctrl-names = "default";
-   pinctrl-0 = <_xfer>;
-   reg-shift = <2>;
-   reg-io-width = <4>;
-   status = "disabled";
-   };
-
-   uart2: