[PATCH] cpufreq: mt8173: Add support for MT8176 and MT817x compatibles

[Daniel Kurtz]

The Mediatek MT8173 is just on of several SOCs from the same MT817x family,
including the 6-core (4-little/2-big) MT8176.

The mt8173-cpufreq driver supports all of these SOCs, however, machines
using them may use a different machine compatible.

Since this driver checks explicitly for the machine compatible string, add
support for the whole family.

Signed-off-by: Daniel Kurtz 
---
This patch is based on the compatibles added by the MT8176 series:

 https://patchwork.kernel.org/patch/9573209/
 https://patchwork.kernel.org/patch/9573213/

 drivers/cpufreq/mt8173-cpufreq.c | 25 +++--
 1 file changed, 23 insertions(+), 2 deletions(-)

diff --git a/drivers/cpufreq/mt8173-cpufreq.c b/drivers/cpufreq/mt8173-cpufreq.c
index ab25b1235a5e..07f7aac56f31 100644
--- a/drivers/cpufreq/mt8173-cpufreq.c
+++ b/drivers/cpufreq/mt8173-cpufreq.c
@@ -573,13 +573,34 @@ static struct platform_driver mt8173_cpufreq_platdrv = {
.probe  = mt8173_cpufreq_probe,
 };
 
+/* List of machine compatible strings supported by this driver */
+static const char *mt8173_cpufreq_machines[] = {
+   "mediatek,mt817x",
+   "mediatek,mt8173",
+   "mediatek,mt8176",
+};
+
+static int mt8173_cpufreq_is_compatible(void)
+{
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(mt8173_cpufreq_machines); i++)
+   if (of_machine_is_compatible(mt8173_cpufreq_machines[i]))
+   return 0;
+
+   return -ENODEV;
+}
+
 static int mt8173_cpufreq_driver_init(void)
 {
struct platform_device *pdev;
int err;
 
-   if (!of_machine_is_compatible("mediatek,mt8173"))
-   return -ENODEV;
+   err = mt8173_cpufreq_is_compatible();
+   if (err) {
+   pr_err("Machine is not compatible with 'mediatek,mt8173'\n");
+   return err;
+   }
 
err = platform_driver_register(&mt8173_cpufreq_platdrv);
if (err)
-- 
2.12.0.rc1.440.g5b76565f74-goog

[PATCH 2/2] vfio: type1: conditionally check MSI remapping at irq domain level

[Mian Yousaf Kaukab]

Check only if irq domains are available.

Signed-off-by: Mian Yousaf Kaukab 
---
 drivers/vfio/vfio_iommu_type1.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index bd6f293c4ebd..e3ed50e40ead 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -1287,8 +1287,9 @@ static int vfio_iommu_type1_attach_group(void *iommu_data,
INIT_LIST_HEAD(&domain->group_list);
list_add(&group->next, &domain->group_list);
 
-   msi_remap = resv_msi ? irq_domain_check_msi_remap() :
-   iommu_capable(bus, IOMMU_CAP_INTR_REMAP);
+   msi_remap = resv_msi && IS_ENABLED(CONFIG_IRQ_DOMAIN) ?
+   irq_domain_check_msi_remap() :
+   iommu_capable(bus, IOMMU_CAP_INTR_REMAP);
 
if (!allow_unsafe_interrupts && !msi_remap) {
pr_warn("%s: No interrupt remapping support.  Use the module 
param \"allow_unsafe_interrupts\" to enable VFIO IOMMU support on this 
platform\n",
-- 
2.11.0

[PATCH 1/2] irqdomain: add empty irq_domain_check_msi_remap

[Mian Yousaf Kaukab]

Fix following build error for s390:
drivers/vfio/vfio_iommu_type1.c: In function 'vfio_iommu_type1_attach_group':
drivers/vfio/vfio_iommu_type1.c:1290:25: error: implicit declaration of 
function 'irq_domain_check_msi_remap'

Signed-off-by: Mian Yousaf Kaukab 
---
 include/linux/irqdomain.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
index 188eced6813e..137817b08cdc 100644
--- a/include/linux/irqdomain.h
+++ b/include/linux/irqdomain.h
@@ -524,6 +524,10 @@ static inline struct irq_domain *irq_find_matching_fwnode(
 {
return NULL;
 }
+static inline bool irq_domain_check_msi_remap(void)
+{
+   return true;
+}
 #endif /* !CONFIG_IRQ_DOMAIN */
 
 #endif /* _LINUX_IRQDOMAIN_H */
-- 
2.11.0

[PATCH v3 1/7] arm64: dts: exynos: Add the burst and esc clock frequency properties for exynos5433 dts

[Hoegeun Kwon]

The OF graph is not needed because the panel is a child of dsi. So
added the burst and esc clock frequency properties to the parent (DSI
node), taking into account the bisectability problem so that remove
the OF graph from DSI node.

Signed-off-by: Hoegeun Kwon 
Reviewed-by: Andrzej Hajda 
---
 arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
index 6ce93a3..e31e20c 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
@@ -298,6 +298,8 @@
status = "okay";
vddcore-supply = <&ldo6_reg>;
vddio-supply = <&ldo7_reg>;
+   samsung,burst-clock-frequency = <51200>;
+   samsung,esc-clock-frequency = <1600>;
samsung,pll-clock-frequency = <2400>;
pinctrl-names = "default";
pinctrl-0 = <&te_irq>;
-- 
1.9.1

[PATCH v3 0/7] Fix the parse_dt of exynos dsi and remove the OF graph

[Hoegeun Kwon]

Hi All,

The dsi + panel is a parental relationship, so OF grpah is not needed.
Therefore, the current dsi_parse_dt function will throw an error,
because there is no linked OF graph for case such as fimd + dsi +
panel.

So the 1/5 patch parse the Pll, burst and esc clock frequency
properties in dsi_parse_dt and modified to create a bridge_node only
if there is an OF graph associated with dsi.

Also fixed the dts, which depend on the 1/5 patch. So removed the
ports node and move burst and esc clock frequency properties to the
parent (DSI node).

Changes for V3:
- Split the patches considering the bisectability problem.

Changes for V2:
- Added the clear explanation for commit. (1/5 patch)
- Fixed it to the same subject as the actual work. (2/5 ~ 5/5 patches)

Best Regards,
Hoegeun

Hoegeun Kwon (7):
  arm64: dts: exynos: Add the burst and esc clock frequency properties
for exynos5433 dts
  arm: dts: Add the burst and esc clock frequency properties for
exynos3250 dts
  arm: dts: Add the burst and esc clock frequency properties for
exynos4412 dts
  arm: dts: Add the burst and esc clock frequency properties for
exynos4210 dts
  drm/exynos: dsi: Fix the parse_dt function
  arm64: dts: exynos: Remove the OF graph from DSI node
  arm: dts: Remove the OF graph from DSI node

 arch/arm/boot/dts/exynos3250-rinato.dts| 23 ++--
 arch/arm/boot/dts/exynos4210-trats.dts | 23 ++--
 arch/arm/boot/dts/exynos4412-trats2.dts| 23 ++--
 .../boot/dts/exynos/exynos5433-tm2-common.dtsi | 16 ++-
 drivers/gpu/drm/exynos/exynos_drm_dsi.c| 32 ++
 5 files changed, 16 insertions(+), 101 deletions(-)

-- 
1.9.1

[PATCH v3 3/7] arm: dts: Add the burst and esc clock frequency properties for exynos4412 dts

[Hoegeun Kwon]

The OF graph is not needed because the panel is a child of dsi. So
added the burst and esc clock frequency properties to the parent (DSI
node), taking into account the bisectability problem so that remove
the OF graph from DSI node.

Signed-off-by: Hoegeun Kwon 
Reviewed-by: Andrzej Hajda 
---
 arch/arm/boot/dts/exynos4412-trats2.dts | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts 
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 41ecd6d..82221a0 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -385,6 +385,8 @@
 &dsi_0 {
vddcore-supply = <&ldo8_reg>;
vddio-supply = <&ldo10_reg>;
+   samsung,burst-clock-frequency = <5>;
+   samsung,esc-clock-frequency = <2000>;
samsung,pll-clock-frequency = <2400>;
status = "okay";
 
-- 
1.9.1

[PATCH v3 4/7] arm: dts: Add the burst and esc clock frequency properties for exynos4210 dts

[Hoegeun Kwon]

The OF graph is not needed because the panel is a child of dsi. So
added the burst and esc clock frequency properties to the parent (DSI
node), taking into account the bisectability problem so that remove
the OF graph from DSI node.

Signed-off-by: Hoegeun Kwon 
Reviewed-by: Andrzej Hajda 
---
 arch/arm/boot/dts/exynos4210-trats.dts | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4210-trats.dts 
b/arch/arm/boot/dts/exynos4210-trats.dts
index 0ca1b4d..1743ca8 100644
--- a/arch/arm/boot/dts/exynos4210-trats.dts
+++ b/arch/arm/boot/dts/exynos4210-trats.dts
@@ -197,6 +197,8 @@
 &dsi_0 {
vddcore-supply = <&vusb_reg>;
vddio-supply = <&vmipi_reg>;
+   samsung,burst-clock-frequency = <5>;
+   samsung,esc-clock-frequency = <2000>;
samsung,pll-clock-frequency = <2400>;
status = "okay";
 
-- 
1.9.1

Re: [PATCH 0/4] Improve intel-hid's self-consistency

[Alex Hung]

On Thu, Mar 2, 2017 at 7:03 AM, Andy Shevchenko
 wrote:
> On Fri, Feb 24, 2017 at 12:33 PM, Michał Kępień  wrote:
>> Commit 2cfa4b311acc ("platform/x86: intel-hid: Support 5 button array")
>> contains some coding style cleanups compared to the code it was based
>> on.  This patch series "backports" these cleanups to the rest of the
>> driver in order to make it more self-consistent and removes a redundant
>> set_bit() call as a bonus.
>>
>> This series was not tested on hardware supported by intel-hid.
>
> Alex, do you have an access to hardware to test? I wouldn't going to
> apply this until I get your tag(s) (in the best case
> Reviewed-and-tested-by).

The patches look good and tested on Latitude 7480

Reviewed-and-tested-by: Alex Hung 

>
> --
> With Best Regards,
> Andy Shevchenko

Re: [PATCH 2/2] vfio: type1: conditionally check MSI remapping at irq domain level

[Auger Eric]

Hi,

On 02/03/2017 11:01, Mian Yousaf Kaukab wrote:
> Check only if irq domains are available.
> 
> Signed-off-by: Mian Yousaf Kaukab 
> ---
>  drivers/vfio/vfio_iommu_type1.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
> index bd6f293c4ebd..e3ed50e40ead 100644
> --- a/drivers/vfio/vfio_iommu_type1.c
> +++ b/drivers/vfio/vfio_iommu_type1.c
> @@ -1287,8 +1287,9 @@ static int vfio_iommu_type1_attach_group(void 
> *iommu_data,
>   INIT_LIST_HEAD(&domain->group_list);
>   list_add(&group->next, &domain->group_list);
>  
> - msi_remap = resv_msi ? irq_domain_check_msi_remap() :
> - iommu_capable(bus, IOMMU_CAP_INTR_REMAP);
> + msi_remap = resv_msi && IS_ENABLED(CONFIG_IRQ_DOMAIN) ?
> + irq_domain_check_msi_remap() :
> + iommu_capable(bus, IOMMU_CAP_INTR_REMAP);
Is that patch actually needed after [PATCH 1/2] irqdomain: add empty
irq_domain_check_msi_remap. irq_domain_check_msi_remap() should be
defined and if you follow my suggestion, would return false. Anyway in
your case resv_msi should be false.

Thanks

Eric
>  
>   if (!allow_unsafe_interrupts && !msi_remap) {
>   pr_warn("%s: No interrupt remapping support.  Use the module 
> param \"allow_unsafe_interrupts\" to enable VFIO IOMMU support on this 
> platform\n",
> 

[PATCH v3 7/7] arm: dts: Remove the OF graph from DSI node

[Hoegeun Kwon]

The OF graph is not needed because the panel is a child of dsi. So
removed the ports node in DSI node, and port node in panel node.

Signed-off-by: Hoegeun Kwon 
Reviewed-by: Andrzej Hajda 
---
 arch/arm/boot/dts/exynos3250-rinato.dts | 21 -
 arch/arm/boot/dts/exynos4210-trats.dts  | 21 -
 arch/arm/boot/dts/exynos4412-trats2.dts | 21 -
 3 files changed, 63 deletions(-)

diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts 
b/arch/arm/boot/dts/exynos3250-rinato.dts
index c9f191c..82e676a 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -220,21 +220,6 @@
samsung,pll-clock-frequency = <2400>;
status = "okay";
 
-   ports {
-   #address-cells = <1>;
-   #size-cells = <0>;
-
-   port@1 {
-   reg = <1>;
-
-   dsi_out: endpoint {
-   remote-endpoint = <&dsi_in>;
-   samsung,burst-clock-frequency = <25000>;
-   samsung,esc-clock-frequency = <2000>;
-   };
-   };
-   };
-
panel@0 {
compatible = "samsung,s6e63j0x03";
reg = <0>;
@@ -264,12 +249,6 @@
vsync-len = <2>;
};
};
-
-   port {
-   dsi_in: endpoint {
-   remote-endpoint = <&dsi_out>;
-   };
-   };
};
 };
 
diff --git a/arch/arm/boot/dts/exynos4210-trats.dts 
b/arch/arm/boot/dts/exynos4210-trats.dts
index 1743ca8..9452bed 100644
--- a/arch/arm/boot/dts/exynos4210-trats.dts
+++ b/arch/arm/boot/dts/exynos4210-trats.dts
@@ -202,21 +202,6 @@
samsung,pll-clock-frequency = <2400>;
status = "okay";
 
-   ports {
-   #address-cells = <1>;
-   #size-cells = <0>;
-
-   port@1 {
-   reg = <1>;
-
-   dsi_out: endpoint {
-   remote-endpoint = <&dsi_in>;
-   samsung,burst-clock-frequency = <5>;
-   samsung,esc-clock-frequency = <2000>;
-   };
-   };
-   };
-
panel@0 {
reg = <0>;
compatible = "samsung,s6e8aa0";
@@ -244,12 +229,6 @@
vsync-len = <2>;
};
};
-
-   port {
-   dsi_in: endpoint {
-   remote-endpoint = <&dsi_out>;
-   };
-   };
};
 };
 
diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts 
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 82221a0..86ce5e5 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -390,21 +390,6 @@
samsung,pll-clock-frequency = <2400>;
status = "okay";
 
-   ports {
-   #address-cells = <1>;
-   #size-cells = <0>;
-
-   port@1 {
-   reg = <1>;
-
-   dsi_out: endpoint {
-   remote-endpoint = <&dsi_in>;
-   samsung,burst-clock-frequency = <5>;
-   samsung,esc-clock-frequency = <2000>;
-   };
-   };
-   };
-
panel@0 {
compatible = "samsung,s6e8aa0";
reg = <0>;
@@ -432,12 +417,6 @@
vsync-len = <2>;
};
};
-
-   port {
-   dsi_in: endpoint {
-   remote-endpoint = <&dsi_out>;
-   };
-   };
};
 };
 
-- 
1.9.1

Re: [PATCH 1/2] irqdomain: add empty irq_domain_check_msi_remap

[Auger Eric]

Hi Mian Yousaf,

On 02/03/2017 11:01, Mian Yousaf Kaukab wrote:
> Fix following build error for s390:
> drivers/vfio/vfio_iommu_type1.c: In function 'vfio_iommu_type1_attach_group':
> drivers/vfio/vfio_iommu_type1.c:1290:25: error: implicit declaration of 
> function 'irq_domain_check_msi_remap'
> 
> Signed-off-by: Mian Yousaf Kaukab 
> ---
>  include/linux/irqdomain.h | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
> index 188eced6813e..137817b08cdc 100644
> --- a/include/linux/irqdomain.h
> +++ b/include/linux/irqdomain.h
> @@ -524,6 +524,10 @@ static inline struct irq_domain 
> *irq_find_matching_fwnode(
>  {
>   return NULL;
>  }
> +static inline bool irq_domain_check_msi_remap(void)
> +{
> + return true;
By default you should rather return false, reporting there is no MSI
remapping capability on irq domain side. Besides thank you for the fix.

Best Regards

Eric
> +}
>  #endif /* !CONFIG_IRQ_DOMAIN */
>  
>  #endif /* _LINUX_IRQDOMAIN_H */
> 

Re: [PATCH 2/2] vfio: type1: conditionally check MSI remapping at irq domain level

[Marc Zyngier]

On 02/03/17 10:01, Mian Yousaf Kaukab wrote:
> Check only if irq domains are available.
> 
> Signed-off-by: Mian Yousaf Kaukab 
> ---
>  drivers/vfio/vfio_iommu_type1.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
> index bd6f293c4ebd..e3ed50e40ead 100644
> --- a/drivers/vfio/vfio_iommu_type1.c
> +++ b/drivers/vfio/vfio_iommu_type1.c
> @@ -1287,8 +1287,9 @@ static int vfio_iommu_type1_attach_group(void 
> *iommu_data,
>   INIT_LIST_HEAD(&domain->group_list);
>   list_add(&group->next, &domain->group_list);
>  
> - msi_remap = resv_msi ? irq_domain_check_msi_remap() :
> - iommu_capable(bus, IOMMU_CAP_INTR_REMAP);
> + msi_remap = resv_msi && IS_ENABLED(CONFIG_IRQ_DOMAIN) ?

Now, that seems completely overkill in the light of your previous patch.
Why do we need this at all?

> + irq_domain_check_msi_remap() :
> + iommu_capable(bus, IOMMU_CAP_INTR_REMAP);
>  
>   if (!allow_unsafe_interrupts && !msi_remap) {
>   pr_warn("%s: No interrupt remapping support.  Use the module 
> param \"allow_unsafe_interrupts\" to enable VFIO IOMMU support on this 
> platform\n",
> 

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...

Re: [PATCH 1/2] irqdomain: add empty irq_domain_check_msi_remap

[Marc Zyngier]

On 02/03/17 10:01, Mian Yousaf Kaukab wrote:
> Fix following build error for s390:
> drivers/vfio/vfio_iommu_type1.c: In function 'vfio_iommu_type1_attach_group':
> drivers/vfio/vfio_iommu_type1.c:1290:25: error: implicit declaration of 
> function 'irq_domain_check_msi_remap'
> 
> Signed-off-by: Mian Yousaf Kaukab 
> ---
>  include/linux/irqdomain.h | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
> index 188eced6813e..137817b08cdc 100644
> --- a/include/linux/irqdomain.h
> +++ b/include/linux/irqdomain.h
> @@ -524,6 +524,10 @@ static inline struct irq_domain 
> *irq_find_matching_fwnode(
>  {
>   return NULL;
>  }
> +static inline bool irq_domain_check_msi_remap(void)
> +{
> + return true;

I'm not sure about that one. If we don't support reserved regions for
MSI, why should we return "true" here? My gut feeling is that it should
be false (because we lack the infrastructure to deal with it).

It is a bit of a moot point since the only calling site will *not* call
this in that case, but I believe that we should be consistent.

Eric, what do you think?

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...

[PATCHv2] omap3isp: add support for CSI1 bus

[Pavel Machek]

Hi!

> > > >> +++ b/drivers/media/platform/omap3isp/ispccp2.c
> > > >> @@ -160,6 +163,33 @@ static int ccp2_if_enable(struct isp_ccp2_device
> > > >> *ccp2, u8 enable) return ret;
> > > >> 
> > > >>}
> > > >> 
> > > >> +  if (isp->revision == ISP_REVISION_2_0) {
> > > > 
> > > > The isp_csiphy.c code checks phy->isp->phy_type for the same purpose,
> > > > shouldn't you use that too ?
> > > 
> > > Do you want me to do phy->isp->phy_type == ISP_PHY_TYPE_3430 check
> > > here? Can do...
> > 
> > Yes that's what I meant.
> 
> Ok, that's something I can do.
> 
> But code is still somewhat "interesting". Code in omap3isp_csiphy_acquire()
> assumes csi2, and I don't need most of it.. so I'll just not use it,
> but it looks strange. I'll post new patch shortly.

Ok, how about this one?

Pavel

omap3isp: add rest of CSI1 support

CSI1 needs one more bit to be set up. Do just that.

It is not as straightforward as I'd like, see the comments in the code
for explanation.

Signed-off-by: Pavel Machek 

index ca09523..b6e055e 100644
--- a/drivers/media/platform/omap3isp/ispccp2.c
+++ b/drivers/media/platform/omap3isp/ispccp2.c
@@ -21,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "isp.h"
 #include "ispreg.h"
@@ -160,6 +163,22 @@ static int ccp2_if_enable(struct isp_ccp2_device *ccp2, u8 
enable)
return ret;
}
 
+   if (isp->phy_type == ISP_PHY_TYPE_3430) {
+   struct media_pad *pad;
+   struct v4l2_subdev *sensor;
+   const struct isp_ccp2_cfg *buscfg;
+
+   pad = media_entity_remote_pad(&ccp2->pads[CCP2_PAD_SINK]);
+   sensor = media_entity_to_v4l2_subdev(pad->entity);
+   /* Struct isp_bus_cfg has union inside */
+   buscfg = &((struct isp_bus_cfg *)sensor->host_priv)->bus.ccp2;
+
+   csiphy_routing_cfg_3430(&isp->isp_csiphy2,
+   ISP_INTERFACE_CCP2B_PHY1,
+   enable, !!buscfg->phy_layer,
+   buscfg->strobe_clk_pol);
+   }
+
/* Enable/Disable all the LCx channels */
for (i = 0; i < CCP2_LCx_CHANS_NUM; i++)
isp_reg_clr_set(isp, OMAP3_ISP_IOMEM_CCP2, ISPCCP2_LCx_CTRL(i),
@@ -1137,10 +1159,19 @@ int omap3isp_ccp2_init(struct isp_device *isp)
if (isp->revision == ISP_REVISION_2_0) {
ccp2->vdds_csib = devm_regulator_get(isp->dev, "vdds_csib");
if (IS_ERR(ccp2->vdds_csib)) {
+   if (PTR_ERR(ccp2->vdds_csib) == -EPROBE_DEFER)
+   return -EPROBE_DEFER;
dev_dbg(isp->dev,
"Could not get regulator vdds_csib\n");
ccp2->vdds_csib = NULL;
}
+   /*
+* If we set up ccp2->phy here,
+* omap3isp_csiphy_acquire() will go ahead and assume
+* csi2, dereferencing some null pointers.
+*
+* ccp2->phy = &isp->isp_csiphy2;
+*/
} else if (isp->revision == ISP_REVISION_15_0) {
ccp2->phy = &isp->isp_csiphy1;
}
diff --git a/drivers/media/platform/omap3isp/ispcsiphy.c 
b/drivers/media/platform/omap3isp/ispcsiphy.c
index 871d4fe..897097b 100644
--- a/drivers/media/platform/omap3isp/ispcsiphy.c
+++ b/drivers/media/platform/omap3isp/ispcsiphy.c
@@ -68,8 +68,8 @@ static void csiphy_routing_cfg_3630(struct isp_csiphy *phy,
regmap_write(phy->isp->syscon, phy->isp->syscon_offset, reg);
 }
 
-static void csiphy_routing_cfg_3430(struct isp_csiphy *phy, u32 iface, bool on,
-   bool ccp2_strobe)
+void csiphy_routing_cfg_3430(struct isp_csiphy *phy, u32 iface, bool on,
+bool ccp2_strobe, bool strobe_clk_pol)
 {
u32 csirxfe = OMAP343X_CONTROL_CSIRXFE_PWRDNZ
| OMAP343X_CONTROL_CSIRXFE_RESET;
@@ -85,6 +85,9 @@ static void csiphy_routing_cfg_3430(struct isp_csiphy *phy, 
u32 iface, bool on,
 
if (ccp2_strobe)
csirxfe |= OMAP343X_CONTROL_CSIRXFE_SELFORM;
+   
+   if (strobe_clk_pol)
+   csirxfe |= OMAP343X_CONTROL_CSIRXFE_CSIB_INV;
 
regmap_write(phy->isp->syscon, phy->isp->syscon_offset, csirxfe);
 }
@@ -108,7 +111,7 @@ static void csiphy_routing_cfg(struct isp_csiphy *phy,
if (phy->isp->phy_type == ISP_PHY_TYPE_3630 && on)
return csiphy_routing_cfg_3630(phy, iface, ccp2_strobe);
if (phy->isp->phy_type == ISP_PHY_TYPE_3430)
-   return csiphy_routing_cfg_3430(phy, iface, on, ccp2_strobe);
+   return csiphy_routing_cfg_3430(phy, iface, on, ccp2_strobe, 
false);
 }
 
 /*
diff --git a/drivers/media/platform/omap3isp/ispcsiphy.h 
b/drivers/media/platform/omap3isp/ispcsiph

Re: [WIP BRANCH] cgroups support in bfq-mq WIP branch

[Paolo Valente]

> Il giorno 25 feb 2017, alle ore 19:52, Jens Axboe  ha 
> scritto:
> 
> On 02/25/2017 10:44 AM, Paolo Valente wrote:
>> Hi,
>> I've just completed cgroups support, and I'd like to highlight the
>> main blk-mq issue that I have found along the way.  I have pushed the
>> commit that completes the support for cgroups to the usual WIP branch
>> [1].  Before moving to this issue, I have preliminary question about
>> the scheduler name, since I'm about to start preparing the patch
>> series for submission.  So far, I have used bfq-mq as a temporary
>> name.  Are we fine with it, or should I change it, for example, to
>> just bfq?  Jens?
> 
> Just call it 'bfq', that doesn't conflict with anything that's
> in the kernel already.
> 

ok

>> I've found a sort of circular dependency in blk-mq, related to
>> scheduler initialization.  To describe both the issue and how I've
>> addressed it, I'm pasting the message of the new commit.
> 
> Rebase your patches on top of Linus current master, some of them
> will need to change and some can be dropped.
> 

Done, but the last deadlock issue shows up again :( To help you get
context, I'm going to reply to the email in which your sent the patch that
solved it.


> And disentangle it completely from the old bfq, I don't want to see
> nasty stuff like includes of .c files with prior defines modifying
> behavior of functions.
> 

Of course.

> When that's done, get it posted for review asap. I would imagine
> we will go through a few postings and review cycles, and if we're
> targeting 4.12 with this, then we should get the ball rolling
> on that side.
> 

I was about to to submit, but bumped into the above regression.

Thanks,
Paolo

> -- 
> Jens Axboe
> 

Re: boot failure, module: overflow in relocation

[Xiong Zhou]

Nevermind, it got fixed now i think.

On Thu, Mar 02, 2017 at 05:51:27PM +0800, Xiong Zhou wrote:
> Hi,
> 
> One host failed to boot while merge going on,
> 
> [   13.076303] module: overflow in relocation type 10 val a0060e58
> [   13.076338] module: overflow in relocation type 10 val a01ac96b
> [   13.076340] module: `scsi_transport_sas' likely not compiled with 
> -mcmodel=kernel
> [   13.181517] module: `pps_core' likely not compiled with -mcmodel=kernel
> [   13.212405] module: overflow in relocation type 10 val a004c278
> [   13.244297] module: `fjes' likely not compiled with -mcmodel=kernel
> [   13.294340] module: overflow in relocation type 10 val a003be58
> [   13.294348] module: overflow in relocation type 10 val a0082797
> [   13.294350] module: `nd_pmem' likely not compiled with -mcmodel=kernel
> [   13.388080] module: `pps_core' likely not compiled with -mcmodel=kernel
> [   13.433976] module: overflow in relocation type 10 val a0095c8e
> [   13.466011] module: `drm' likely not compiled with -mcmodel=kernel
> 
> then wait to mount rootfs or other tasks like forever.
> 
> Bisect pointing to:
> commit d1091c7fa3d52ebce4dd3f15d04155b3469b2f90
> Author: Josh Poimboeuf 
> Date:   Tue Feb 21 15:35:32 2017 -0600
> 
> objtool: Improve detection of BUG() and other dead ends
> 
> After reverting these 3 commits, login prompt shows.
> 4e4636c objtool: Enclose contents of unreachable() macro in a block
> 3d1e236 objtool: Prevent GCC from merging annotate_unreachable()
> d1091c7 objtool: Improve detection of BUG() and other dead ends 
> 
> Thanks,
> 
>  bisect log --
> git bisect start
> # good: [86292b33d4b79ee03e2f43ea0381ef85f077c760] Merge branch 'akpm' 
> (patches from Andrew)
> git bisect good 86292b33d4b79ee03e2f43ea0381ef85f077c760
> # bad: [8313064c2e75542201e557e2b496668811c2484a] Merge tag 'nfsd-4.11' of 
> git://linux-nfs.org/~bfields/linux
> git bisect bad 8313064c2e75542201e557e2b496668811c2484a
> # bad: [d4f4cf77b37eaea58ef863a4cbc95dad3880b524] Merge branch 'for-linus' of 
> git://git.armlinux.org.uk/~rmk/linux-arm
> git bisect bad d4f4cf77b37eaea58ef863a4cbc95dad3880b524
> # bad: [74efe07bc38c538ba7ac40a895910f4f3bee3152] Merge branch 
> 'locking-urgent-for-linus' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
> git bisect bad 74efe07bc38c538ba7ac40a895910f4f3bee3152
> # good: [c4d2603dac3a555e4bb324daf5cb5cdb5694eedd] rhashtable: Fix RCU 
> dereference annotation in rht_bucket_nested
> git bisect good c4d2603dac3a555e4bb324daf5cb5cdb5694eedd
> # good: [2f44f75257d57f0d5668dba3a6ada0f4872132c9] Merge branch 'qed-fixes'
> git bisect good 2f44f75257d57f0d5668dba3a6ada0f4872132c9
> # good: [74e3f63ce60eb81fbd39aa6c0353059b7e2cb5f7] Merge 
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide
> git bisect good 74e3f63ce60eb81fbd39aa6c0353059b7e2cb5f7
> # bad: [4e4636cf981b5b629fbfb78aa9f232e015f7d521] objtool: Enclose contents 
> of unreachable() macro in a block
> git bisect bad 4e4636cf981b5b629fbfb78aa9f232e015f7d521
> # bad: [d1091c7fa3d52ebce4dd3f15d04155b3469b2f90] objtool: Improve detection 
> of BUG() and other dead ends
> git bisect bad d1091c7fa3d52ebce4dd3f15d04155b3469b2f90
> # good: [9f0c18aec620bc9d82268b3cb937568dd07b43ff] objtool: Fix 
> CONFIG_STACK_VALIDATION=y warning for out-of-tree modules
> git bisect good 9f0c18aec620bc9d82268b3cb937568dd07b43ff
> # first bad commit: [d1091c7fa3d52ebce4dd3f15d04155b3469b2f90] objtool: 
> Improve detection of BUG() and other dead ends

Re: [PATCH] usb: dwc3: ep0: Fix the possible missed request for handling delay STATUS phase

[Baolin Wang]

Hi,

On 28 February 2017 at 06:11, Alan Stern  wrote:
> On Tue, 21 Feb 2017, Baolin Wang wrote:
>
>> On 17 February 2017 at 16:04, Felipe Balbi  wrote:
>> >
>> > Hi,
>> >
>> > Baolin Wang  writes:
>>  (One possible approach would be to have the setup routine return
>>  different values for explicit and implicit status stages -- for
>>  example, return 1 if it wants to submit an explicit status request.
>>  That wouldn't be very different from the current
>>  USB_GADGET_DELAYED_STATUS approach.)
>> >>>
>> >>> not really, no. The idea was for composite.c and/or functions to support
>> >>> both methods (temporarily) and use "gadget->wants_explicit_stages" to
>> >>> explicitly queue DATA and STATUS. That would mean that f_mass_storage
>> >>> wouldn't have to return DELAYED_STATUS if
>> >>> (gadget->wants_explicit_stages).
>> >>>
>> >>> After all UDCs are converted over and set wants_explicit_stages (which
>> >>> should all be done in a single series), then we get rid of the flag and
>> >>> the older method of DELAYED_STATUS.
>> >>
>> >> (Sorry for late reply due to my holiday)
>> >> I also met the problem pointed by Alan, from my test, I still want to
>> >> need one return value to indicate if it wants to submit an explicit
>> >> status request. Think about the Control-IN with a data stage, we can
>> >> not get the STATUS phase request from usb_ep_queue() call, and we need
>> >
>> > why not? wLength tells you that this is a 3-stage transfer. Gadget
>> > driver should be able to figure out that it needs to usb_ep_queue()
>> > another request for status stage.
>>
>> I tried again, but still can not work. Suppose the no-data control:
>> (1) SET_ADDRESS request: function driver will not queue one request
>> for status phase by usb_ep_queue() call.
>
> Function drivers do not handle Set-Address requests at all.  The UDC
> driver handles these requests without telling the gadget driver about
> them.

Correct. What I mean is it will not queue one request for status phase
by usb_ep_queue() call, UDC driver will do that.

>
>> (2) SET_CONFIGURATION request: function driver will queue one 0-length
>> request for status phase by usb_ep_queue() call, especially for
>> mass_storage driver, it will queue one request  for status phase
>> later.
>>
>> So I am not sure how the Gadget driver can figure out that it needs to
>> usb_ep_queue() another request for status stage when handling the
>> no-data control?
>
> Gadget drivers already queue status-stage requests for no-data
> control-OUT requests.  The difficulty comes when you want to handle an
> IN request or an OUT request with a data stage.
>

I try to explain that explicitly, In dwc3 driver, we can handle the
STATUS phase request in 2 places: (1) in usb_ep_queue(), (2) in
dwc3_ep0_xfernotready()
For no-data control-OUT requests:
(1) SET_ADDRESS request: no request queued for status phase by
usb_ep_queue(), dwc3 driver need handle the STATUS phase request when
one not-ready-event comes in dwc3_ep0_xfernotready() function.
(2) SET_CONFIGURATION request: function driver will queue one 0-length
request for status phase by usb_ep_queue(), but we can handle this
request in usb_ep_queue() or dwc3_ep0_xfernotready(). When the
function driver queued one 0-length request for status phase before
the not-ready-event comes, we need handle this request in
dwc3_ep0_xfernotready() when the not-ready-event comes. When  the
function driver queued one 0-length request for status phase after the
not-ready-event comes, we can handle this request in usb_ep_queue().
So in dwc3_ep0_xfernotready(), we need to check if the request for
status phase has been queued into pending request list, but if the
pending request list is NULL, which means the function driver have not
queued one 0-length request until now (then we can handle it in
usb_ep_queue()), or situation (1) (no request queued for status
phase), then I can not identify this 2 situations to determine where I
can handle the status request. Hope I make it clear.

Your concern about an IN request or an OUT request with a data stage,
I agree with Felipe and we can identify. Thanks.
-- 
Baolin.wang
Best Regards

[PATCH 3/6] staging: wlan-ng: Fix sparse warnings in hfa384x_usb.c

[simran singhal]

drivers/staging/wlan-ng/hfa384x_usb.c:3520:34: warning: incorrect type in 
assignment (different base types)
drivers/staging/wlan-ng/hfa384x_usb.c:3520:34:expected unsigned int 
[unsigned] [usertype] datarate
drivers/staging/wlan-ng/hfa384x_usb.c:3520:34:got restricted __be32 
[usertype] 
drivers/staging/wlan-ng/hfa384x_usb.c:3521:33: warning: incorrect type in 
assignment (different base types)
drivers/staging/wlan-ng/hfa384x_usb.c:3521:33:expected unsigned int 
[unsigned] [usertype] antenna
drivers/staging/wlan-ng/hfa384x_usb.c:3521:33:got restricted __be32 
[usertype] 
drivers/staging/wlan-ng/hfa384x_usb.c:3522:34: warning: incorrect type in 
assignment (different base types)
drivers/staging/wlan-ng/hfa384x_usb.c:3522:34:expected unsigned int 
[unsigned] [usertype] priority
drivers/staging/wlan-ng/hfa384x_usb.c:3522:34:got restricted __be32 
[usertype] 
drivers/staging/wlan-ng/hfa384x_usb.c:3523:34: warning: incorrect type in 
assignment (different base types)
drivers/staging/wlan-ng/hfa384x_usb.c:3523:34:expected unsigned int 
[unsigned] [usertype] ssi_type
drivers/staging/wlan-ng/hfa384x_usb.c:3523:34:got restricted __be32 
[usertype] 
drivers/staging/wlan-ng/hfa384x_usb.c:3524:36: warning: incorrect type in 
assignment (different base types)
drivers/staging/wlan-ng/hfa384x_usb.c:3524:36:expected signed int [signed] 
[usertype] [explicitly-signed] ssi_signal
drivers/staging/wlan-ng/hfa384x_usb.c:3524:36:got restricted __be32 
[usertype] 
drivers/staging/wlan-ng/hfa384x_usb.c:3525:35: warning: incorrect type in 
assignment (different base types)
drivers/staging/wlan-ng/hfa384x_usb.c:3525:35:expected signed int [signed] 
[usertype] [explicitly-signed] ssi_noise
drivers/staging/wlan-ng/hfa384x_usb.c:3525:35:got restricted __be32 
[usertype] 
drivers/staging/wlan-ng/hfa384x_usb.c:3526:34: warning: incorrect type in 
assignment (different base types)
drivers/staging/wlan-ng/hfa384x_usb.c:3526:34:expected unsigned int 
[unsigned] [usertype] preamble
drivers/staging/wlan-ng/hfa384x_usb.c:3526:34:got restricted __be32 
[usertype] 
drivers/staging/wlan-ng/hfa384x_usb.c:3527:34: warning: incorrect type in 
assignment (different base types)
drivers/staging/wlan-ng/hfa384x_usb.c:3527:34:expected unsigned int 
[unsigned] [usertype] encoding
drivers/staging/wlan-ng/hfa384x_usb.c:3527:34:got restricted __be32 
[usertype] 

Signed-off-by: simran singhal 
---
 drivers/staging/wlan-ng/hfa384x_usb.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/wlan-ng/hfa384x_usb.c 
b/drivers/staging/wlan-ng/hfa384x_usb.c
index a7ff572..cdf987b 100644
--- a/drivers/staging/wlan-ng/hfa384x_usb.c
+++ b/drivers/staging/wlan-ng/hfa384x_usb.c
@@ -3517,14 +3517,14 @@ static void hfa384x_int_rxmonitor(struct wlandevice 
*wlandev,
caphdr->hosttime = __cpu_to_be64(jiffies);
caphdr->phytype = htonl(4); /* dss_dot11_b */
caphdr->channel = htonl(hw->sniff_channel);
-   caphdr->datarate = htonl(rxdesc->rate);
-   caphdr->antenna = htonl(0); /* unknown */
-   caphdr->priority = htonl(0);/* unknown */
-   caphdr->ssi_type = htonl(3);/* rssi_raw */
-   caphdr->ssi_signal = htonl(rxdesc->signal);
-   caphdr->ssi_noise = htonl(rxdesc->silence);
-   caphdr->preamble = htonl(0);/* unknown */
-   caphdr->encoding = htonl(1);/* cck */
+   caphdr->datarate = be32_to_cpu(htonl(rxdesc->rate));
+   caphdr->antenna = be32_to_cpu(htonl(0));/* unknown */
+   caphdr->priority = be32_to_cpu(htonl(0));   /* unknown */
+   caphdr->ssi_type = be32_to_cpu(htonl(3));   /* rssi_raw */
+   caphdr->ssi_signal = be32_to_cpu(htonl(rxdesc->signal));
+   caphdr->ssi_noise = be32_to_cpu(htonl(rxdesc->silence));
+   caphdr->preamble = be32_to_cpu(htonl(0));   /* unknown */
+   caphdr->encoding = be32_to_cpu(htonl(1));   /* cck */
}
 
/* Copy the 802.11 header to the skb
-- 
2.7.4

Re: [PATCH v4 1/1] drm/fb-helper: implement ioctl FBIO_WAITFORVSYNC

[Daniel Vetter]

On Thu, Mar 02, 2017 at 08:12:02AM +0100, Daniel Vetter wrote:
> On Tue, Feb 28, 2017 at 04:36:51PM +0100, Maxime Ripard wrote:
> > Implement legacy framebuffer ioctl FBIO_WAITFORVSYNC in the generic
> > framebuffer emulation driver. Legacy framebuffer users like non kms/drm
> > based OpenGL(ES)/EGL implementations may require the ioctl to
> > synchronize drawing or buffer flip for double buffering. It is tested on
> > the i.MX6.
> > 
> > Signed-off-by: Maxime Ripard 
> > Tested-by: Neil Armstrong 
> 
> Pushed to drm-misc, thanks.

I forgot to add Dave's irc ack to the commit patch, but for the record I
discussed it with him and he's not enthuastic, but ok.
-Daniel

> -Daniel
> 
> > ---
> >  drivers/gpu/drm/drm_fb_helper.c | 68 ++-
> >  include/drm/drm_fb_helper.h | 12 +-
> >  2 files changed, 79 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_fb_helper.c 
> > b/drivers/gpu/drm/drm_fb_helper.c
> > index c6de87abaca8..8ac8716c023a 100644
> > --- a/drivers/gpu/drm/drm_fb_helper.c
> > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > @@ -1240,6 +1240,74 @@ int drm_fb_helper_setcmap(struct fb_cmap *cmap, 
> > struct fb_info *info)
> >  EXPORT_SYMBOL(drm_fb_helper_setcmap);
> >  
> >  /**
> > + * drm_fb_helper_ioctl - legacy ioctl implementation
> > + * @info: fbdev registered by the helper
> > + * @cmd: ioctl command
> > + * @arg: ioctl argument
> > + *
> > + * A helper to implement the standard fbdev ioctl. Only
> > + * FBIO_WAITFORVSYNC is implemented for now.
> > + */
> > +int drm_fb_helper_ioctl(struct fb_info *info, unsigned int cmd,
> > +   unsigned long arg)
> > +{
> > +   struct drm_fb_helper *fb_helper = info->par;
> > +   struct drm_device *dev = fb_helper->dev;
> > +   struct drm_mode_set *mode_set;
> > +   struct drm_crtc *crtc;
> > +   int ret = 0;
> > +
> > +   mutex_lock(&dev->mode_config.mutex);
> > +   if (!drm_fb_helper_is_bound(fb_helper)) {
> > +   ret = -EBUSY;
> > +   goto unlock;
> > +   }
> > +
> > +   switch (cmd) {
> > +   case FBIO_WAITFORVSYNC:
> > +   /*
> > +* Only consider the first CRTC.
> > +*
> > +* This ioctl is supposed to take the CRTC number as
> > +* an argument, but in fbdev times, what that number
> > +* was supposed to be was quite unclear, different
> > +* drivers were passing that argument differently
> > +* (some by reference, some by value), and most of the
> > +* userspace applications were just hardcoding 0 as an
> > +* argument.
> > +*
> > +* The first CRTC should be the integrated panel on
> > +* most drivers, so this is the best choice we can
> > +* make. If we're not smart enough here, one should
> > +* just consider switch the userspace to KMS.
> > +*/
> > +   mode_set = &fb_helper->crtc_info[0].mode_set;
> > +   crtc = mode_set->crtc;
> > +
> > +   /*
> > +* Only wait for a vblank event if the CRTC is
> > +* enabled, otherwise just don't do anythintg,
> > +* not even report an error.
> > +*/
> > +   ret = drm_crtc_vblank_get(crtc);
> > +   if (!ret) {
> > +   drm_crtc_wait_one_vblank(crtc);
> > +   drm_crtc_vblank_put(crtc);
> > +   }
> > +
> > +   ret = 0;
> > +   goto unlock;
> > +   default:
> > +   ret = -ENOTTY;
> > +   }
> > +
> > +unlock:
> > +   mutex_unlock(&dev->mode_config.mutex);
> > +   return ret;
> > +}
> > +EXPORT_SYMBOL(drm_fb_helper_ioctl);
> > +
> > +/**
> >   * drm_fb_helper_check_var - implementation for ->fb_check_var
> >   * @var: screeninfo to check
> >   * @info: fbdev registered by the helper
> > diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
> > index 975deedd593e..2891888c6e41 100644
> > --- a/include/drm/drm_fb_helper.h
> > +++ b/include/drm/drm_fb_helper.h
> > @@ -230,7 +230,8 @@ struct drm_fb_helper {
> > .fb_blank   = drm_fb_helper_blank, \
> > .fb_pan_display = drm_fb_helper_pan_display, \
> > .fb_debug_enter = drm_fb_helper_debug_enter, \
> > -   .fb_debug_leave = drm_fb_helper_debug_leave
> > +   .fb_debug_leave = drm_fb_helper_debug_leave, \
> > +   .fb_ioctl   = drm_fb_helper_ioctl
> >  
> >  #ifdef CONFIG_DRM_FBDEV_EMULATION
> >  void drm_fb_helper_prepare(struct drm_device *dev, struct drm_fb_helper 
> > *helper,
> > @@ -286,6 +287,9 @@ void drm_fb_helper_set_suspend_unlocked(struct 
> > drm_fb_helper *fb_helper,
> >  
> >  int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct fb_info *info);
> >  
> > +int drm_fb_helper_ioctl(struct fb_info *info, unsigned int cmd,
> > +   unsigned long arg);
> > +
> >  int drm_fb_helper_hotplug_event(struct drm_fb_helper *fb_helper);
> >  int drm_fb_helper_initial_config(struct drm_fb_helper *fb_helper, i

Re: [PATCH v4 1/1] drm/fb-helper: implement ioctl FBIO_WAITFORVSYNC

[Daniel Vetter]

On Tue, Feb 28, 2017 at 04:36:51PM +0100, Maxime Ripard wrote:
> Implement legacy framebuffer ioctl FBIO_WAITFORVSYNC in the generic
> framebuffer emulation driver. Legacy framebuffer users like non kms/drm
> based OpenGL(ES)/EGL implementations may require the ioctl to
> synchronize drawing or buffer flip for double buffering. It is tested on
> the i.MX6.
> 
> Signed-off-by: Maxime Ripard 
> Tested-by: Neil Armstrong 

Pushed to drm-misc, thanks.
-Daniel

> ---
>  drivers/gpu/drm/drm_fb_helper.c | 68 ++-
>  include/drm/drm_fb_helper.h | 12 +-
>  2 files changed, 79 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index c6de87abaca8..8ac8716c023a 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -1240,6 +1240,74 @@ int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct 
> fb_info *info)
>  EXPORT_SYMBOL(drm_fb_helper_setcmap);
>  
>  /**
> + * drm_fb_helper_ioctl - legacy ioctl implementation
> + * @info: fbdev registered by the helper
> + * @cmd: ioctl command
> + * @arg: ioctl argument
> + *
> + * A helper to implement the standard fbdev ioctl. Only
> + * FBIO_WAITFORVSYNC is implemented for now.
> + */
> +int drm_fb_helper_ioctl(struct fb_info *info, unsigned int cmd,
> + unsigned long arg)
> +{
> + struct drm_fb_helper *fb_helper = info->par;
> + struct drm_device *dev = fb_helper->dev;
> + struct drm_mode_set *mode_set;
> + struct drm_crtc *crtc;
> + int ret = 0;
> +
> + mutex_lock(&dev->mode_config.mutex);
> + if (!drm_fb_helper_is_bound(fb_helper)) {
> + ret = -EBUSY;
> + goto unlock;
> + }
> +
> + switch (cmd) {
> + case FBIO_WAITFORVSYNC:
> + /*
> +  * Only consider the first CRTC.
> +  *
> +  * This ioctl is supposed to take the CRTC number as
> +  * an argument, but in fbdev times, what that number
> +  * was supposed to be was quite unclear, different
> +  * drivers were passing that argument differently
> +  * (some by reference, some by value), and most of the
> +  * userspace applications were just hardcoding 0 as an
> +  * argument.
> +  *
> +  * The first CRTC should be the integrated panel on
> +  * most drivers, so this is the best choice we can
> +  * make. If we're not smart enough here, one should
> +  * just consider switch the userspace to KMS.
> +  */
> + mode_set = &fb_helper->crtc_info[0].mode_set;
> + crtc = mode_set->crtc;
> +
> + /*
> +  * Only wait for a vblank event if the CRTC is
> +  * enabled, otherwise just don't do anythintg,
> +  * not even report an error.
> +  */
> + ret = drm_crtc_vblank_get(crtc);
> + if (!ret) {
> + drm_crtc_wait_one_vblank(crtc);
> + drm_crtc_vblank_put(crtc);
> + }
> +
> + ret = 0;
> + goto unlock;
> + default:
> + ret = -ENOTTY;
> + }
> +
> +unlock:
> + mutex_unlock(&dev->mode_config.mutex);
> + return ret;
> +}
> +EXPORT_SYMBOL(drm_fb_helper_ioctl);
> +
> +/**
>   * drm_fb_helper_check_var - implementation for ->fb_check_var
>   * @var: screeninfo to check
>   * @info: fbdev registered by the helper
> diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
> index 975deedd593e..2891888c6e41 100644
> --- a/include/drm/drm_fb_helper.h
> +++ b/include/drm/drm_fb_helper.h
> @@ -230,7 +230,8 @@ struct drm_fb_helper {
>   .fb_blank   = drm_fb_helper_blank, \
>   .fb_pan_display = drm_fb_helper_pan_display, \
>   .fb_debug_enter = drm_fb_helper_debug_enter, \
> - .fb_debug_leave = drm_fb_helper_debug_leave
> + .fb_debug_leave = drm_fb_helper_debug_leave, \
> + .fb_ioctl   = drm_fb_helper_ioctl
>  
>  #ifdef CONFIG_DRM_FBDEV_EMULATION
>  void drm_fb_helper_prepare(struct drm_device *dev, struct drm_fb_helper 
> *helper,
> @@ -286,6 +287,9 @@ void drm_fb_helper_set_suspend_unlocked(struct 
> drm_fb_helper *fb_helper,
>  
>  int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct fb_info *info);
>  
> +int drm_fb_helper_ioctl(struct fb_info *info, unsigned int cmd,
> + unsigned long arg);
> +
>  int drm_fb_helper_hotplug_event(struct drm_fb_helper *fb_helper);
>  int drm_fb_helper_initial_config(struct drm_fb_helper *fb_helper, int 
> bpp_sel);
>  int drm_fb_helper_single_add_all_connectors(struct drm_fb_helper *fb_helper);
> @@ -377,6 +381,12 @@ static inline int drm_fb_helper_setcmap(struct fb_cmap 
> *cmap,
>   return 0;
>  }
>  
> +static inline int drm_fb_helper_ioctl(struct fb_info *info, unsigned int cmd,
> +   unsigned lo

Re: [GIT PULL] vfs patches for 4.11

[Al Viro]

On Thu, Mar 02, 2017 at 10:32:08AM +0200, Amir Goldstein wrote:
> On Mon, Feb 20, 2017 at 7:17 PM, Al Viro  wrote:
> > On Mon, Feb 20, 2017 at 05:19:00PM +0100, Miklos Szeredi wrote:
> >> Hi Al,
> >>
> >> Please pull from:
> >>
> >>   git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git for-viro
> >>
> >> Amir Goldstein (4):
> >>   vfs: create vfs helper vfs_tmpfile()
> >>   vfs: deny fallocate() on directory
> >>   vfs: deny copy_file_range() for non regular files
> >>   vfs: wrap write f_ops with file_{start,end}_write()
> >
> > The last one could have a better summary, but anyway - pulled.
> 
> Al,
> 
> Please excuse my impatience, but do you plan to send these out to
> Linus for 4.11?

Yes.  As the matter of fact, it will be one of the pull requests in today's
pile.

Re: [PATCH] [media] ad5820: remove incorrect __exit markups

[Pavel Machek]

On Wed 2017-03-01 15:41:23, Dmitry Torokhov wrote:
> Even if bus is not hot-pluggable, devices can be unbound from the
> driver via sysfs, so we should not be using __exit annotations on
> remove() methods. The only exception is drivers registered with
> platform_driver_probe() which specifically disables sysfs bind/unbind
> attributes.
> 
> Signed-off-by: Dmitry Torokhov 

Acked-by: Pavel Machek 

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


signature.asc
Description: Digital signature

boot failure, module: overflow in relocation

[Xiong Zhou]

Hi,

One host failed to boot while merge going on,

[   13.076303] module: overflow in relocation type 10 val a0060e58
[   13.076338] module: overflow in relocation type 10 val a01ac96b
[   13.076340] module: `scsi_transport_sas' likely not compiled with 
-mcmodel=kernel
[   13.181517] module: `pps_core' likely not compiled with -mcmodel=kernel
[   13.212405] module: overflow in relocation type 10 val a004c278
[   13.244297] module: `fjes' likely not compiled with -mcmodel=kernel
[   13.294340] module: overflow in relocation type 10 val a003be58
[   13.294348] module: overflow in relocation type 10 val a0082797
[   13.294350] module: `nd_pmem' likely not compiled with -mcmodel=kernel
[   13.388080] module: `pps_core' likely not compiled with -mcmodel=kernel
[   13.433976] module: overflow in relocation type 10 val a0095c8e
[   13.466011] module: `drm' likely not compiled with -mcmodel=kernel

then wait to mount rootfs or other tasks like forever.

Bisect pointing to:
commit d1091c7fa3d52ebce4dd3f15d04155b3469b2f90
Author: Josh Poimboeuf 
Date:   Tue Feb 21 15:35:32 2017 -0600

objtool: Improve detection of BUG() and other dead ends

After reverting these 3 commits, login prompt shows.
4e4636c objtool: Enclose contents of unreachable() macro in a block
3d1e236 objtool: Prevent GCC from merging annotate_unreachable()
d1091c7 objtool: Improve detection of BUG() and other dead ends 

Thanks,

 bisect log --
git bisect start
# good: [86292b33d4b79ee03e2f43ea0381ef85f077c760] Merge branch 'akpm' (patches 
from Andrew)
git bisect good 86292b33d4b79ee03e2f43ea0381ef85f077c760
# bad: [8313064c2e75542201e557e2b496668811c2484a] Merge tag 'nfsd-4.11' of 
git://linux-nfs.org/~bfields/linux
git bisect bad 8313064c2e75542201e557e2b496668811c2484a
# bad: [d4f4cf77b37eaea58ef863a4cbc95dad3880b524] Merge branch 'for-linus' of 
git://git.armlinux.org.uk/~rmk/linux-arm
git bisect bad d4f4cf77b37eaea58ef863a4cbc95dad3880b524
# bad: [74efe07bc38c538ba7ac40a895910f4f3bee3152] Merge branch 
'locking-urgent-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect bad 74efe07bc38c538ba7ac40a895910f4f3bee3152
# good: [c4d2603dac3a555e4bb324daf5cb5cdb5694eedd] rhashtable: Fix RCU 
dereference annotation in rht_bucket_nested
git bisect good c4d2603dac3a555e4bb324daf5cb5cdb5694eedd
# good: [2f44f75257d57f0d5668dba3a6ada0f4872132c9] Merge branch 'qed-fixes'
git bisect good 2f44f75257d57f0d5668dba3a6ada0f4872132c9
# good: [74e3f63ce60eb81fbd39aa6c0353059b7e2cb5f7] Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide
git bisect good 74e3f63ce60eb81fbd39aa6c0353059b7e2cb5f7
# bad: [4e4636cf981b5b629fbfb78aa9f232e015f7d521] objtool: Enclose contents of 
unreachable() macro in a block
git bisect bad 4e4636cf981b5b629fbfb78aa9f232e015f7d521
# bad: [d1091c7fa3d52ebce4dd3f15d04155b3469b2f90] objtool: Improve detection of 
BUG() and other dead ends
git bisect bad d1091c7fa3d52ebce4dd3f15d04155b3469b2f90
# good: [9f0c18aec620bc9d82268b3cb937568dd07b43ff] objtool: Fix 
CONFIG_STACK_VALIDATION=y warning for out-of-tree modules
git bisect good 9f0c18aec620bc9d82268b3cb937568dd07b43ff
# first bad commit: [d1091c7fa3d52ebce4dd3f15d04155b3469b2f90] objtool: Improve 
detection of BUG() and other dead ends

Re: [Outreachy kernel] [PATCH 1/6] staging: wlan-ng: Fix sparse warning of restricted __le16

[Julia Lawall]

On Thu, 2 Mar 2017, Julia Lawall wrote:

>
>
> On Thu, 2 Mar 2017, simran singhal wrote:
>
> > This patch fixes the following sparse warning:
> > warning: cast to restricted __le16
>
> You commit message should not say just fix X.  What have you done to carry
> out the fix and why is this the correct approach?

This comment applies to all of the patches in the series.

julia

>
> julia
>
> >
> > Signed-off-by: simran singhal 
> > ---
> >  drivers/staging/wlan-ng/prism2sta.c | 51 
> > ++---
> >  1 file changed, 25 insertions(+), 26 deletions(-)
> >
> > diff --git a/drivers/staging/wlan-ng/prism2sta.c 
> > b/drivers/staging/wlan-ng/prism2sta.c
> > index 984804b..82d3a70 100644
> > --- a/drivers/staging/wlan-ng/prism2sta.c
> > +++ b/drivers/staging/wlan-ng/prism2sta.c
> > @@ -372,10 +372,9 @@ static int prism2sta_mlmerequest(struct wlandevice 
> > *wlandev,
> > qualmsg->noise.status =
> > P80211ENUM_msgitem_status_data_ok;
> >
> > -   qualmsg->link.data = le16_to_cpu(hw->qual.cq_curr_bss);
> > -   qualmsg->level.data =
> > -   le16_to_cpu(hw->qual.asl_curr_bss);
> > -   qualmsg->noise.data = le16_to_cpu(hw->qual.anl_curr_fc);
> > +   qualmsg->link.data = hw->qual.cq_curr_bss;
> > +   qualmsg->level.data = hw->qual.asl_curr_bss;
> > +   qualmsg->noise.data = hw->qual.anl_curr_fc;
> > qualmsg->txrate.data = hw->txrate;
> >
> > break;
> > @@ -603,10 +602,10 @@ static int prism2sta_getcardinfo(struct wlandevice 
> > *wlandev)
> > }
> >
> > /* get all the nic id fields in host byte order */
> > -   hw->ident_nic.id = le16_to_cpu(hw->ident_nic.id);
> > -   hw->ident_nic.variant = le16_to_cpu(hw->ident_nic.variant);
> > -   hw->ident_nic.major = le16_to_cpu(hw->ident_nic.major);
> > -   hw->ident_nic.minor = le16_to_cpu(hw->ident_nic.minor);
> > +   hw->ident_nic.id = hw->ident_nic.id;
> > +   hw->ident_nic.variant = hw->ident_nic.variant;
> > +   hw->ident_nic.major = hw->ident_nic.major;
> > +   hw->ident_nic.minor = hw->ident_nic.minor;
> >
> > netdev_info(wlandev->netdev, "ident: nic h/w: id=0x%02x %d.%d.%d\n",
> > hw->ident_nic.id, hw->ident_nic.major,
> > @@ -622,10 +621,10 @@ static int prism2sta_getcardinfo(struct wlandevice 
> > *wlandev)
> > }
> >
> > /* get all the private fw id fields in host byte order */
> > -   hw->ident_pri_fw.id = le16_to_cpu(hw->ident_pri_fw.id);
> > -   hw->ident_pri_fw.variant = le16_to_cpu(hw->ident_pri_fw.variant);
> > -   hw->ident_pri_fw.major = le16_to_cpu(hw->ident_pri_fw.major);
> > -   hw->ident_pri_fw.minor = le16_to_cpu(hw->ident_pri_fw.minor);
> > +   hw->ident_pri_fw.id = hw->ident_pri_fw.id;
> > +   hw->ident_pri_fw.variant = hw->ident_pri_fw.variant;
> > +   hw->ident_pri_fw.major = hw->ident_pri_fw.major;
> > +   hw->ident_pri_fw.minor = hw->ident_pri_fw.minor;
> >
> > netdev_info(wlandev->netdev, "ident: pri f/w: id=0x%02x %d.%d.%d\n",
> > hw->ident_pri_fw.id, hw->ident_pri_fw.major,
> > @@ -648,10 +647,10 @@ static int prism2sta_getcardinfo(struct wlandevice 
> > *wlandev)
> > }
> >
> > /* get all the station fw id fields in host byte order */
> > -   hw->ident_sta_fw.id = le16_to_cpu(hw->ident_sta_fw.id);
> > -   hw->ident_sta_fw.variant = le16_to_cpu(hw->ident_sta_fw.variant);
> > -   hw->ident_sta_fw.major = le16_to_cpu(hw->ident_sta_fw.major);
> > -   hw->ident_sta_fw.minor = le16_to_cpu(hw->ident_sta_fw.minor);
> > +   hw->ident_sta_fw.id = hw->ident_sta_fw.id;
> > +   hw->ident_sta_fw.variant = hw->ident_sta_fw.variant;
> > +   hw->ident_sta_fw.major = hw->ident_sta_fw.major;
> > +   hw->ident_sta_fw.minor = hw->ident_sta_fw.minor;
> >
> > /* strip out the 'special' variant bits */
> > hw->mm_mods = hw->ident_sta_fw.variant & GENMASK(15, 14);
> > @@ -683,11 +682,11 @@ static int prism2sta_getcardinfo(struct wlandevice 
> > *wlandev)
> > /* get all the Compatibility range, modem interface supplier
> >  * fields in byte order
> >  */
> > -   hw->cap_sup_mfi.role = le16_to_cpu(hw->cap_sup_mfi.role);
> > -   hw->cap_sup_mfi.id = le16_to_cpu(hw->cap_sup_mfi.id);
> > -   hw->cap_sup_mfi.variant = le16_to_cpu(hw->cap_sup_mfi.variant);
> > -   hw->cap_sup_mfi.bottom = le16_to_cpu(hw->cap_sup_mfi.bottom);
> > -   hw->cap_sup_mfi.top = le16_to_cpu(hw->cap_sup_mfi.top);
> > +   hw->cap_sup_mfi.role = hw->cap_sup_mfi.role;
> > +   hw->cap_sup_mfi.id = hw->cap_sup_mfi.id;
> > +   hw->cap_sup_mfi.variant = hw->cap_sup_mfi.variant;
> > +   hw->cap_sup_mfi.bottom = hw->cap_sup_mfi.bottom;
> > +   hw->cap_sup_mfi.top = hw->cap_sup_mfi.top;
> >
> > netdev_info(wlandev->netdev,
> > "MFI:SUP:role=0x%02x:id=0x%02x:var=0x%02x:b/t=%d/%d\n",
> > @@ -707,11 +706,11 @@ static int prism2sta_getcardinfo(struct wlandevice 
> > *wlandev)
> > /* ge

Re: [PATCH V2 3/4] drm/bridge: Drivers for megachips-stdpxxxx-ge-b850v3-fw (LVDS-DP++)

[Archit Taneja]

Hi Peter,

On 3/1/2017 4:08 PM, Peter Senna Tschudin wrote:

Hi Archit,

Thank you for the review!

On Wed, Mar 01, 2017 at 09:38:48AM +0530, Archit Taneja wrote:



On 02/28/2017 07:58 PM, Peter Senna Tschudin wrote:

The video processing pipeline on the second output on the GE B850v3:

  Host -> LVDS|--(STDP4028)--|DP -> DP|--(STDP2690)--|DP++ -> Video output

Each bridge has a dedicated flash containing firmware for supporting the
custom design. The result is that in this design neither the STDP4028
nor the STDP2690 behave as the stock bridges would. The compatible
strings include the suffix "-ge-b850v3-fw" to make it clear that the
driver is for the bridges with the firmware which is specific for the GE
B850v3.

The driver is powerless to control the video processing pipeline, as the
two bridges behaves as a single one. The driver is only needed for
telling the host about EDID / HPD, and for giving the host powers to ack
interrupts.

This driver adds one i2c_device for each bridge, but only one
drm_bridge. This design allows the creation of a functional connector
that is capable of reading EDID from the STDP2690 while handling
interrupts on the STDP4028.

Cc: Laurent Pinchart 
Cc: Martyn Welch 
Cc: Martin Donnelly 
Cc: Daniel Vetter 
Cc: Enric Balletbo i Serra 
Cc: Philipp Zabel 
Cc: Rob Herring 
Cc: Fabio Estevam 
Cc: David Airlie 
Cc: Thierry Reding 
Cc: Thierry Reding 
Cc: Archit Taneja 
Cc: Enric Balletbo 
Signed-off-by: Peter Senna Tschudin 
---
Changes from V1:
 - Updated copyright year
 - Fixed blank line issues
 - Updated ge_b850v3_lvds_remove() to not rely on ge_b850v3_lvds_ptr->edid and
   added a comment to explain the test.
 - Fixed checkpatch strict warnings about continuation lines. In one case
   fixing the warning would cause the continuation line to be over 80 chars and
   that strict warning remains.

 drivers/gpu/drm/bridge/Kconfig |  11 +
 drivers/gpu/drm/bridge/Makefile|   1 +
 .../drm/bridge/megachips-stdp-ge-b850v3-fw.c   | 411 +
 3 files changed, 423 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index eb8688e..4a937f1 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -48,6 +48,17 @@ config DRM_DW_HDMI_I2S_AUDIO
  Support the I2S Audio interface which is part of the Synopsis
  Designware HDMI block.

+config DRM_MEGACHIPS_STDP_GE_B850V3_FW
+   tristate "MegaChips stdp4028-ge-b850v3-fw and stdp2690-ge-b850v3-fw"
+   depends on OF
+   select DRM_KMS_HELPER
+   select DRM_PANEL
+   ---help---
+  This is a driver for the display bridges of
+  GE B850v3 that convert dual channel LVDS
+  to DP++. This is used with the i.MX6 imx-ldb
+  driver. You are likely to say N here.
+
 config DRM_NXP_PTN3460
tristate "NXP PTN3460 DP/LVDS bridge"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 2e83a785..af0b7cc 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -5,6 +5,7 @@ obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
 obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
 obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
 obj-$(CONFIG_DRM_DW_HDMI_I2S_AUDIO) += dw-hdmi-i2s-audio.o
+obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) += 
megachips-stdp-ge-b850v3-fw.o
 obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
 obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
 obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o
diff --git a/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c 
b/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
new file mode 100644
index 000..6f82a44
--- /dev/null
+++ b/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
@@ -0,0 +1,411 @@
+/*
+ * Driver for MegaChips STDP4028 with GE B850v3 firmware (LVDS-DP)
+ * Driver for MegaChips STDP2690 with GE B850v3 firmware (DP-DP++)
+
+ * Copyright (c) 2017, Collabora Ltd.
+ * Copyright (c) 2017, General Electric Company
+
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+
+ * This program is distributed in the hope 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.
+
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+
+ * This driver creates a drm_bridge and a drm_connector for the LVDS to DP++
+ * display bridge of the GE B850v3. There are two physical bridges on the video
+ * signal pipeline: a STDP4028(LVDS to DP) and a STDP2690(DP

Re: net/ipv4: deadlock in ip_ra_control

[Dmitry Vyukov]

On Wed, Mar 1, 2017 at 6:18 PM, Cong Wang  wrote:
> On Wed, Mar 1, 2017 at 2:44 AM, Dmitry Vyukov  wrote:
>> Hello,
>>
>> I've got the following deadlock report while running syzkaller fuzzer
>> on linux-next/51788aebe7cae79cb334ad50641347465fc188fd:
>>
>> ==
>> [ INFO: possible circular locking dependency detected ]
>> 4.10.0-next-20170301+ #1 Not tainted
>> ---
>> syz-executor1/3394 is trying to acquire lock:
>>  (sk_lock-AF_INET){+.+.+.}, at: [] lock_sock
>> include/net/sock.h:1460 [inline]
>>  (sk_lock-AF_INET){+.+.+.}, at: []
>> do_ip_setsockopt.isra.12+0x21c/0x3540 net/ipv4/ip_sockglue.c:652
>>
>> but task is already holding lock:
>>  (rtnl_mutex){+.+.+.}, at: [] rtnl_lock+0x17/0x20
>> net/core/rtnetlink.c:70
>>
>> which lock already depends on the new lock.
>>
>>
>> the existing dependency chain (in reverse order) is:
>>
>> -> #1 (rtnl_mutex){+.+.+.}:
>>validate_chain kernel/locking/lockdep.c:2265 [inline]
>>__lock_acquire+0x2149/0x3430 kernel/locking/lockdep.c:3338
>>lock_acquire+0x2a1/0x630 kernel/locking/lockdep.c:3753
>>__mutex_lock_common kernel/locking/mutex.c:754 [inline]
>>__mutex_lock+0x172/0x1730 kernel/locking/mutex.c:891
>>mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:906
>>rtnl_lock+0x17/0x20 net/core/rtnetlink.c:70
>>mrtsock_destruct+0x86/0x2c0 net/ipv4/ipmr.c:1281
>>ip_ra_control+0x459/0x600 net/ipv4/ip_sockglue.c:372
>>do_ip_setsockopt.isra.12+0x1064/0x3540 net/ipv4/ip_sockglue.c:1161
>>ip_setsockopt+0x3a/0xb0 net/ipv4/ip_sockglue.c:1264
>>raw_setsockopt+0xb7/0xd0 net/ipv4/raw.c:839
>>sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2725
>>SYSC_setsockopt net/socket.c:1786 [inline]
>>SyS_setsockopt+0x25c/0x390 net/socket.c:1765
>>entry_SYSCALL_64_fastpath+0x1f/0xc2
>>
>> -> #0 (sk_lock-AF_INET){+.+.+.}:
>>check_prev_add kernel/locking/lockdep.c:1828 [inline]
>>check_prevs_add+0xa8f/0x19f0 kernel/locking/lockdep.c:1938
>>validate_chain kernel/locking/lockdep.c:2265 [inline]
>>__lock_acquire+0x2149/0x3430 kernel/locking/lockdep.c:3338
>>lock_acquire+0x2a1/0x630 kernel/locking/lockdep.c:3753
>>lock_sock_nested+0xcb/0x120 net/core/sock.c:2530
>>lock_sock include/net/sock.h:1460 [inline]
>>do_ip_setsockopt.isra.12+0x21c/0x3540 net/ipv4/ip_sockglue.c:652
>>ip_setsockopt+0x3a/0xb0 net/ipv4/ip_sockglue.c:1264
>>tcp_setsockopt+0x82/0xd0 net/ipv4/tcp.c:2721
>>sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2725
>>SYSC_setsockopt net/socket.c:1786 [inline]
>>SyS_setsockopt+0x25c/0x390 net/socket.c:1765
>>entry_SYSCALL_64_fastpath+0x1f/0xc2
>>
>
> Please try the attached patch (compile only).


Pushed the patch to the bots.
Thanks

Re: [PATCH V11 10/10] arm/arm64: KVM: add guest SEA support

[Marc Zyngier]

On 01/03/17 02:31, Xiongfeng Wang wrote:

[lot of things]

> If an SEA is injected into guest OS, the guest OS will jump to the SEA
> exception entry when the context switched to guest OS. And the CPSR and
> FAR_EL1 are recovered according to the content of vcpu. Then the guest
> OS can signal a process or panic. If another guest process read the
> error data, another SEA will be generated and it will be single too.
> 
> Without QEMU involved, the drawback is that no APEI table can be mocked
> up in guest OS, and no memory_failure() will be called. So the memory of
> error data will be released into buddy system and assigned to another
> process. If the error was caused by instantaneous radiation or
> electromagnetic, the memory is usable again if it is written with a
> correct data. If the memory has wore out and a correct data is written,
> the ECC error may occurs again with high possibility. Before a 2-bit ECC
> error is reported, much more 1-bit errors will be reported. This is
> report to host os, the host os can determine the memory node has worn
> out and hot-plug out the memory node, and guest os may be terminated if
> its memory data can't be migrated.
> 
> Of course, it is better to get QEMU involved, so the memory_failure can
> be executed in guest OS. But before that implemented, can we add SEA
> injection in kvm_handle_guest_abort()?

No. I will strongly object to that. This is a platform decision to
forward SEAs, not an architectural one. The core KVM code is only
concerned about implementing the ARM architecture, and not something
that is firmware dependent.

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...

BUSINESS REQUEST………

[MrDalami Musa]

Greetings,

I am a banker with Bank of Africa (BOA)  Ouagadougou Burkina Faso. I am in a 
better position to transfer about $22.3 million US Dollars into a foreign 
account. If you are willing and capable to work with me to receive this fund 
into a personal or company's account, I will give you the full detailed 
information. No risk is involved as it will pass through normal banking 
procedures.

Thanks

Mr Dalami Musa

[PATCH 1/3] cpufreq: schedutil: move cached_raw_freq to struct sugov_policy

[Viresh Kumar]

cached_raw_freq applies to the entire cpufreq policy and not individual
CPUs. Apart from wasting per-cpu memory, it is actually wrong to keep it
in struct sugov_cpu as we may end up comparing next_freq with a stale
cached_raw_freq of a random CPU.

Move cached_raw_freq to struct sugov_policy.

Signed-off-by: Viresh Kumar 
---
 kernel/sched/cpufreq_schedutil.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c
index 306d97e7b57c..721f4e011366 100644
--- a/kernel/sched/cpufreq_schedutil.c
+++ b/kernel/sched/cpufreq_schedutil.c
@@ -35,6 +35,7 @@ struct sugov_policy {
u64 last_freq_update_time;
s64 freq_update_delay_ns;
unsigned int next_freq;
+   unsigned int cached_raw_freq;
 
/* The next fields are only needed if fast switch cannot be used. */
struct irq_work irq_work;
@@ -51,7 +52,6 @@ struct sugov_cpu {
struct update_util_data update_util;
struct sugov_policy *sg_policy;
 
-   unsigned int cached_raw_freq;
unsigned long iowait_boost;
unsigned long iowait_boost_max;
u64 last_update;
@@ -145,9 +145,9 @@ static unsigned int get_next_freq(struct sugov_cpu *sg_cpu, 
unsigned long util,
 
freq = (freq + (freq >> 2)) * util / max;
 
-   if (freq == sg_cpu->cached_raw_freq && sg_policy->next_freq != UINT_MAX)
+   if (freq == sg_policy->cached_raw_freq && sg_policy->next_freq != 
UINT_MAX)
return sg_policy->next_freq;
-   sg_cpu->cached_raw_freq = freq;
+   sg_policy->cached_raw_freq = freq;
return cpufreq_driver_resolve_freq(policy, freq);
 }
 
@@ -579,6 +579,7 @@ static int sugov_start(struct cpufreq_policy *policy)
sg_policy->next_freq = UINT_MAX;
sg_policy->work_in_progress = false;
sg_policy->need_freq_update = false;
+   sg_policy->cached_raw_freq = 0;
 
for_each_cpu(cpu, policy->cpus) {
struct sugov_cpu *sg_cpu = &per_cpu(sugov_cpu, cpu);
@@ -589,7 +590,6 @@ static int sugov_start(struct cpufreq_policy *policy)
sg_cpu->max = 0;
sg_cpu->flags = SCHED_CPUFREQ_RT;
sg_cpu->last_update = 0;
-   sg_cpu->cached_raw_freq = 0;
sg_cpu->iowait_boost = 0;
sg_cpu->iowait_boost_max = policy->cpuinfo.max_freq;
cpufreq_add_update_util_hook(cpu, &sg_cpu->update_util,
-- 
2.7.1.410.g6faf27b

[PATCH] radix tree test suite: Fix build with --as-needed

[Michael Ellerman]

Currently the radix tree test suite doesn't build with toolchains that
use --as-needed by default, for example Ubuntu's:

  cc -I. -I../../include -g -O2 -Wall -D_LGPL_SOURCE -fsanitize=address 
-lpthread -lurcu main.o ... -o main
  /usr/bin/ld: regression1.o: undefined reference to symbol 
'pthread_join@@GLIBC_2.17'
  /lib/powerpc64le-linux-gnu/libpthread.so.0: error adding symbols: DSO missing 
from command line
  collect2: error: ld returned 1 exit status

This is caused by the custom makefile rules placing LDFLAGS before the
.o files that need the libraries.

We could fix it by using --no-as-needed, or rewriting the custom rules.
But we can also just drop the custom rules and move the libraries to
LDLIBS, and then the default rules work correctly - with the one caveat
that we need to add -fsanitize=address to LDFLAGS because that must be
passed to the linker as well as the compiler.

Signed-off-by: Michael Ellerman 
---
 tools/testing/radix-tree/Makefile | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/tools/testing/radix-tree/Makefile 
b/tools/testing/radix-tree/Makefile
index ecea846e7660..4831cb89cbfb 100644
--- a/tools/testing/radix-tree/Makefile
+++ b/tools/testing/radix-tree/Makefile
@@ -1,6 +1,7 @@
 
 CFLAGS += -I. -I../../include -g -O2 -Wall -D_LGPL_SOURCE -fsanitize=address
-LDFLAGS += -lpthread -lurcu
+LDFLAGS += -fsanitize=address
+LDLIBS += -lpthread -lurcu
 TARGETS = main idr-test multiorder
 CORE_OFILES := radix-tree.o idr.o linux.o test.o find_bit.o
 OFILES = main.o $(CORE_OFILES) regression1.o regression2.o regression3.o \
@@ -13,13 +14,10 @@ endif
 targets: $(TARGETS)
 
 main:  $(OFILES)
-   $(CC) $(CFLAGS) $(LDFLAGS) $^ -o main
 
 idr-test: idr-test.o $(CORE_OFILES)
-   $(CC) $(CFLAGS) $(LDFLAGS) $^ -o idr-test
 
 multiorder: multiorder.o $(CORE_OFILES)
-   $(CC) $(CFLAGS) $(LDFLAGS) $^ -o multiorder
 
 clean:
$(RM) $(TARGETS) *.o radix-tree.c idr.c
-- 
2.7.4

Re: [PATCH/RFC] arm64: pmu: add Qualcomm Technologies extensions

[Marc Zyngier]

On 01/03/17 21:36, Leeder, Neil wrote:
> Hi Mark,
> Thanks for the quick response.
> 
> On 3/1/2017 1:10 PM, Mark Rutland wrote:
>> Hi Neil,
>>
>> On Wed, Mar 01, 2017 at 11:18:05AM -0500, Neil Leeder wrote:
>>> Adds CPU PMU perf events support for Qualcomm Technologies' Falkor CPU.
>>>
>>> The Qualcomm Technologies CPU PMU is named qcom_pmuv3 and provides
>>> extensions to the architected PMU events.
>>
>> Is this is a strict superset of PMUv3 (that could validly be treated as
>> just PMUv3), or do those IMP DEF parts need to be poked to use this at
>> all?
>>
>> What is reported by ID_AA64DFR0_EL1.PMUVer on these CPUs?
> 
> It's a strict superset. If you don't use any of the extensions than it 
> behaves as a PMUv3 for architected events. ID_AA64DFR0_EL1.PMUVer = 1.
> 
>> Quite frankly, I'm less than thrilled about the prospect of
>> IMPLEMENTATION DEFINED CPU PMUs that fall outside of the architected PMU
>> model, especially for ACPI systems where the raison d'être is standards
>> and uniformity, and where we have no sensible mechanism to provide
>> information regarding IMPLEMENTATION DEFINED functionality.
>>
>> This has knock-on effects for other things, like userspace PMU access
>> and/or virtualization, and this multiplies the support effort.
>>
>> KVM already has (architected) PMU support, and without a corresponding
>> KVM patch this is at best insufficient. I don't imagine the KVM folk
>> will be too thrilled about the prospect of emulating an IMPLEMENTATION
>> DEFINED CPU feature like this.
> 
> Does KVM handle ARMv7 PMU implementations? If so, do you know what it 
> does for the scorpion_* and krait_* implementations in 
> arch/arm/kernel/perf_events_v7.c? These extensions in ARMv8 are very 
> similar to the krait extensions, with some 64-bit tweaks, so could be 
> handled by KVM the same way it handles the ARMv7 cases.

No, KVM doesn't handle the ARMv7 PMU at all. I'm not aware of the
virtualization extensions being available on Scorpion or Krait, which
makes it a moot point. What it handles is the PMUv3 architecture.

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...

Re: mm allocation failure and hang when running xfstests generic/269 on xfs

[Xiong Zhou]

On Thu, Mar 02, 2017 at 09:42:23AM +0100, Michal Hocko wrote:
> On Thu 02-03-17 12:17:47, Anshuman Khandual wrote:
> > On 03/02/2017 10:49 AM, Xiong Zhou wrote:
> > > On Wed, Mar 01, 2017 at 04:37:31PM -0800, Christoph Hellwig wrote:
> > >> On Wed, Mar 01, 2017 at 12:46:34PM +0800, Xiong Zhou wrote:
> > >>> Hi,
> > >>>
> > >>> It's reproduciable, not everytime though. Ext4 works fine.
> > >> On ext4 fsstress won't run bulkstat because it doesn't exist.  Either
> > >> way this smells like a MM issue to me as there were not XFS changes
> > >> in that area recently.
> > > Yap.
> > > 
> > > First bad commit:
> > > 
> > > commit 5d17a73a2ebeb8d1c6924b91e53ab2650fe86ffb
> > > Author: Michal Hocko 
> > > Date:   Fri Feb 24 14:58:53 2017 -0800
> > > 
> > > vmalloc: back off when the current task is killed
> > > 
> > > Reverting this commit on top of
> > >   e5d56ef Merge tag 'watchdog-for-linus-v4.11'
> > > survives the tests.
> > 
> > Does fsstress test or the system hang ? I am not familiar with this
> > code but If it's the test which is getting hung and its hitting this
> > new check introduced by the above commit that means the requester is
> > currently being killed by OOM killer for some other memory allocation
> > request.
> 
> Well, not exactly. It is sufficient for it to be _killed_ by SIGKILL.
> And for that it just needs to do a group_exit when one thread was still
> in the kernel (see zap_process). While I can change this check to
> actually do the oom specific check I believe a more generic
> fatal_signal_pending is the right thing to do here. I am still not sure
> what is the actual problem here, though. Could you be more specific
> please?

It's blocking the test and system-shutdown. fsstress wont exit.

For anyone interested, a simple ugly reproducer:

cat > fst.sh < local.config < -- 
> Michal Hocko
> SUSE Labs

Re: [PATCH] tpm: select CONFIG_CRYPTO

[Jarkko Sakkinen]

On Tue, Feb 28, 2017 at 10:24:45PM +0100, Peter Huewe wrote:
> 
> 
> Am 28. Februar 2017 22:12:55 MEZ schrieb Arnd Bergmann :
> >We get a newly introduced harmless warning when CONFIG_CRYPTO is
> >disabled:
> >
> >warning: (TCG_TPM && TRUSTED_KEYS && IMA) selects CRYPTO_HASH_INFO
> >which has unmet direct dependencies (CRYPTO)
> >
> >This adds another select to avoid the warning, consistent with other
> >users
> >of the crypto code.
> >
> >Fixes: c1f92b4b04ad ("tpm: enhance TPM 2.0 PCR extend to support
> >multiple banks")
> >Signed-off-by: Arnd Bergmann 
> Lgtm
> 
> Reviewed-by: Peter Huewe 

Reviewed-by: Jarkko Sakkinen 

/Jarkko

> >---
> > drivers/char/tpm/Kconfig | 1 +
> > 1 file changed, 1 insertion(+)
> >
> >diff --git a/drivers/char/tpm/Kconfig b/drivers/char/tpm/Kconfig
> >index af985cca413c..d520ac51c11c 100644
> >--- a/drivers/char/tpm/Kconfig
> >+++ b/drivers/char/tpm/Kconfig
> >@@ -6,6 +6,7 @@ menuconfig TCG_TPM
> > tristate "TPM Hardware Support"
> > depends on HAS_IOMEM
> > select SECURITYFS
> >+select CRYPTO
> > select CRYPTO_HASH_INFO
> > ---help---
> >   If you have a TPM security chip in your system, which
> 
> -- 
> Sent from my mobile

pull-request: wireless-drivers 2017-03-02

[Kalle Valo]

Hi Dave,

only one patch this time, the new version of ath10k patch we reverted
earlier. I was supposed to send you this earlier but it got delayed
because I'm on vacation, so sorry about that. I'm hoping this is ok to
take also even the merge window is closed as the changes to the first
version of the patch are minimal.

Please let me know if there are any problems.

Kalle

The following changes since commit 8313064c2e75542201e557e2b496668811c2484a:

  Merge tag 'nfsd-4.11' of git://linux-nfs.org/~bfields/linux (2017-02-28 
15:39:09 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git 
tags/wireless-drivers-for-davem-2017-03-02

for you to fetch changes up to 1657b8f84ed9fc1d2a100671f1d42d6286f20073:

  ath10k: search SMBIOS for OEM board file extension (2017-03-02 10:48:41 +0200)


wireless-drivers fixes for 4.11

Add back a fixed version of an ath10k patch which was reverted during
the merge window.


Waldemar Rymarkiewicz (1):
  ath10k: search SMBIOS for OEM board file extension

 drivers/net/wireless/ath/ath10k/core.c | 101 -
 drivers/net/wireless/ath/ath10k/core.h |  19 +++
 2 files changed, 117 insertions(+), 3 deletions(-)

-- 
Kalle Valo

Re: [PATCH v2 1/5] pinctrl: sunxi: refactor pinctrl choice selecting for ARM64

[Maxime Ripard]

On Thu, Mar 02, 2017 at 02:01:07AM +0800, Icenowy Zheng wrote:
> ARM64 Allwinner SoCs used to have every pinctrl driver selected in
> ARCH_SUNXI. Change this to make their default value to (ARM64 &&
> ARCH_SUNXI).
> 
> Signed-off-by: Icenowy Zheng 
> Reviewed-by: Andre Przywara 

Acked-by: Maxime Ripard 

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: [RFC PATCH 2/2] mtd: devices: m25p80: Enable spi-nor bounce buffer support

[Frode Isaksen]

On 01/03/2017 17:55, Boris Brezillon wrote:
> On Wed, 1 Mar 2017 17:16:30 +0530
> Vignesh R  wrote:
>
>> On Wednesday 01 March 2017 04:13 PM, Cyrille Pitchen wrote:
>>> Le 01/03/2017 à 05:54, Vignesh R a écrit :  

 On Wednesday 01 March 2017 03:11 AM, Richard Weinberger wrote:  
> Vignesh,
>
> Am 27.02.2017 um 13:08 schrieb Vignesh R:  
>> Many SPI controller drivers use DMA to read/write from m25p80 compatible
>> flashes. Therefore enable bounce buffers support provided by spi-nor
>> framework to take care of handling vmalloc'd buffers which may not be
>> DMA'able.
>>
>> Signed-off-by: Vignesh R 
>> ---
>>  drivers/mtd/devices/m25p80.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
>> index c4df3b1bded0..d05acf22eadf 100644
>> --- a/drivers/mtd/devices/m25p80.c
>> +++ b/drivers/mtd/devices/m25p80.c
>> @@ -241,6 +241,7 @@ static int m25p_probe(struct spi_device *spi)
>>  else
>>  flash_name = spi->modalias;
>>  
>> +nor->flags |= SNOR_F_USE_BOUNCE_BUFFER;  
> Isn't there a better way to detect whether a bounce buffer is needed or 
> not?  
  
>>> I agree with Richard: the bounce buffer should be enabled only if needed
>>> by the SPI controller.
>>>   
 Yes, I can poke the spi->master struct to see of dma channels are
 populated and request SNOR_F_USE_BOUNCE_BUFFER accordingly:

 -   nor->flags |= SNOR_F_USE_BOUNCE_BUFFER;
 +   if (spi->master->dma_tx || spi->master->dma_rx)
 +   nor->flags |= SNOR_F_USE_BOUNCE_BUFFER;
 +
  
>>> However I don't agree with this solution: master->dma_{tx|rx} can be set
>>> for SPI controllers which already rely on spi_map_msg() to handle
>>> vmalloc'ed memory during DMA transfers.
>>> Such SPI controllers don't need the spi-nor bounce buffer.
>>>
>>> spi_map_msg() can build a scatter-gather list from vmalloc'ed buffer
>>> then map this sg list with dma_map_sg(). AFAIK, It is safe to do so for
>>> architectures using PIPT caches since the possible cache aliases issue
>>> present for VIPT or VIVT caches is always avoided for PIPT caches.
>>>
>>> For instance, the drivers/spi/spi-atmel.c driver relies on spi_map_sg()
>>> to be called from the SPI sub-system to handle vmalloc'ed buffers and
>>> both master->dma_tx and master->dma_rx are set by the this driver.
>>>
>>>
>>> By the way, Is there any case where the same physical page is actually
>>> mapped into two different virtual addresses for the buffers allocated by
>>> the MTD sub-system? Because for a long time now I wonder whether the
>>> cache aliases issue is a real or only theoretical issue but I have no
>>> answer to that question.
>>>   
>> I have atleast one evidence of VIVT aliasing causing problem. Please see
>> this thread on DMA issues with davinci-spi driver
>> https://www.spinics.net/lists/arm-kernel/msg563420.html
>> https://www.spinics.net/lists/arm-kernel/msg563445.html
>>
>>> Then my next question: is spi_map_msg() enough in every case, even with
>>> VIPT or VIVT caches?
>>>   
>> Not really, I am debugging another issue with UBIFS on DRA74 EVM (ARM
>> cortex-a15) wherein pages allocated by vmalloc are in highmem region
>> that are not addressable using 32 bit addresses and is backed by LPAE.
>> So, a 32 bit DMA cannot access these buffers at all.
>> When dma_map_sg() is called to map these pages by spi_map_buf() the
>> physical address is just truncated to 32 bit in pfn_to_dma() (as part of
>> dma_map_sg() call). This results in random crashes as DMA starts
>> accessing random memory during SPI read.
>>
>> IMO, there may be more undiscovered caveat with using dma_map_sg() for
>> non kmalloc'd buffers and its better that spi-nor starts handling these
>> buffers instead of relying on spi_map_msg() and working around every
>> time something pops up.
>>
> Ok, I had a closer look at the SPI framework, and it seems there's a
> way to tell to the core that a specific transfer cannot use DMA
> (->can_dam()). The first thing you should do is fix the spi-davinci
> driver:
>
> 1/ implement ->can_dma()
> 2/ patch davinci_spi_bufs() to take the decision to do DMA or not on a
>per-xfer basis and not on a per-device basis
>
> Then we can start thinking about how to improve perfs by using a bounce
> buffer for large transfers, but I'm still not sure this should be done
> at the MTD level...
This has already been done, see 
http://lists.infradead.org/pipermail/linux-arm-kernel/2017-February/489761.html.
 I return false for can_dma() if the rx or tx buffer is a vmalloc'ed one.
In that case the transfer gos back to PIO and you loose performance, but no 
data corruption.

Thanks,
Frode

subdevice config into pointer (was Re: [PATCH 1/4] v4l2: device_register_subdev_nodes: allow calling multiple times)

[Pavel Machek]

Hi!

> Making the sub-device bus configuration a pointer should be in a separate
> patch. It makes sense since the entire configuration is not valid for all
> sub-devices attached to the ISP anymore. I think it originally was a
> separate patch, but they probably have been merged at some point. I can't
> find it right now anyway.

Something like this?
Pavel

commit df9141c66678b549fac9d143bd55ed0b242cf36e
Author: Pavel 
Date:   Wed Mar 1 13:27:56 2017 +0100

Turn bus in struct isp_async_subdev into pointer; some of our subdevs
(flash, focus) will not need bus configuration.

Signed-off-by: Pavel Machek 

diff --git a/drivers/media/platform/omap3isp/isp.c 
b/drivers/media/platform/omap3isp/isp.c
index 8a456d4..36bd359 100644
--- a/drivers/media/platform/omap3isp/isp.c
+++ b/drivers/media/platform/omap3isp/isp.c
@@ -2030,12 +2030,18 @@ enum isp_of_phy {
 static int isp_fwnode_parse(struct device *dev, struct fwnode_handle *fwn,
struct isp_async_subdev *isd)
 {
-   struct isp_bus_cfg *buscfg = &isd->bus;
+   struct isp_bus_cfg *buscfg;
struct v4l2_fwnode_endpoint vfwn;
unsigned int i;
int ret;
bool csi1 = false;
 
+   buscfg = devm_kzalloc(dev, sizeof(*isd->bus), GFP_KERNEL);
+   if (!buscfg)
+   return -ENOMEM;
+
+   isd->bus = buscfg;
+
ret = v4l2_fwnode_endpoint_parse(fwn, &vfwn);
if (ret)
return ret;
@@ -2246,7 +2252,7 @@ static int isp_subdev_notifier_bound(struct 
v4l2_async_notifier *async,
container_of(asd, struct isp_async_subdev, asd);
 
isd->sd = subdev;
-   isd->sd->host_priv = &isd->bus;
+   isd->sd->host_priv = isd->bus;
 
return 0;
 }
diff --git a/drivers/media/platform/omap3isp/isp.h 
b/drivers/media/platform/omap3isp/isp.h
index 7e6f663..c0b9d1d 100644
--- a/drivers/media/platform/omap3isp/isp.h
+++ b/drivers/media/platform/omap3isp/isp.h
@@ -228,7 +228,7 @@ struct isp_device {
 
 struct isp_async_subdev {
struct v4l2_subdev *sd;
-   struct isp_bus_cfg bus;
+   struct isp_bus_cfg *bus;
struct v4l2_async_subdev asd;
 };
 
diff --git a/drivers/media/platform/omap3isp/ispcsiphy.c 
b/drivers/media/platform/omap3isp/ispcsiphy.c
index f20abe8..be23408 100644
--- a/drivers/media/platform/omap3isp/ispcsiphy.c
+++ b/drivers/media/platform/omap3isp/ispcsiphy.c
@@ -202,7 +202,7 @@ static int omap3isp_csiphy_config(struct isp_csiphy *phy)
struct isp_async_subdev *isd =
container_of(pipe->external->asd,
 struct isp_async_subdev, asd);
-   buscfg = &isd->bus;
+   buscfg = isd->bus;
}
 
if (buscfg->interface == ISP_INTERFACE_CCP2B_PHY1


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


signature.asc
Description: Digital signature

Re: [PATCH] omap3isp: add support for CSI1 bus

[Pavel Machek]

Hi!

> > >> +
> > >> +static int isp_of_parse_node_endpoint(struct device *dev,
> > >> +  struct device_node *node,
> > >> +  struct isp_async_subdev *isd)
> > >> +{
> > >> +struct isp_bus_cfg *buscfg;
> > >> +struct v4l2_of_endpoint vep;
> > >> +int ret;
> > >> +
> > >> +isd->bus = devm_kzalloc(dev, sizeof(*isd->bus), GFP_KERNEL);
> > > 
> > > Why do you now need to allocate this manually ?
> > 
> > bus is now a pointer.
> 
> I've seen that, but why have you changed it ?

subdev support. Needs to go into separate patch. Will be done shortly.

> > >> +++ b/drivers/media/platform/omap3isp/ispccp2.c
> > >> @@ -160,6 +163,33 @@ static int ccp2_if_enable(struct isp_ccp2_device
> > >> *ccp2, u8 enable) return ret;
> > >> 
> > >>  }
> > >> 
> > >> +if (isp->revision == ISP_REVISION_2_0) {
> > > 
> > > The isp_csiphy.c code checks phy->isp->phy_type for the same purpose,
> > > shouldn't you use that too ?
> > 
> > Do you want me to do phy->isp->phy_type == ISP_PHY_TYPE_3430 check
> > here? Can do...
> 
> Yes that's what I meant.

Ok, that's something I can do.

But code is still somewhat "interesting". Code in omap3isp_csiphy_acquire()
assumes csi2, and I don't need most of it.. so I'll just not use it,
but it looks strange. I'll post new patch shortly.

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


signature.asc
Description: Digital signature

Re: [PATCH] devicetree: Add video bus switch

[Pavel Machek]

On Mon 2017-02-13 12:20:35, Sakari Ailus wrote:
> Hi Pavel,
> 
> On Mon, Feb 13, 2017 at 10:54:20AM +0100, Pavel Machek wrote:
> > Hi!
> > 
> > > > Take a look at the wikipedia. If you do "one at a time" at 100Hz, you
> > > > can claim it is time-domain multiplex. But we are plain switching the
> > > > cameras. It takes second (or so) to setup the pipeline.
> > > > 
> > > > This is not multiplex.
> > > 
> > > The functionality is still the same, isn't it? Does it change what it is 
> > > if
> > > the frequency might be 100 Hz or 0,01 Hz?
> > 
> > Well. In your living your you can have a switch, which is switch at
> > much less than 0.01Hz. You can also have a dimmer, which is a PWM,
> > which is switch at 100Hz or so. So yes, I'd say switch and mux are
> > different things.
> 
> Light switches are mostly on/off switches. It'd be interesting to have a
> light switch that you could use to light either of the light bulbs in a room
> but not to switch both of them on at the same time. Or off... :-)
> 
> I wonder if everyone would be happy with a statement saying that it's a
> on / on switch which is used to implement a multiplexer?

I believe the difference is the timescale. If it switches "slow" it is
a switch. If it switches fast, it is a dimmer, mux, or something

Anyway, someone else was faster, so they get to name their creation...

Pavel

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


signature.asc
Description: Digital signature

[PATCH resend] timers, sched_clock: Update timeout for clock wrap

[David Engraf]

The scheduler clock framework may not use the correct timeout for the clock
wrap. This happens when a new clock driver calls sched_clock_register()
after the kernel called sched_clock_postinit(). In this case the clock wrap
timeout is too long thus sched_clock_poll() is called too late and the clock
already wrapped.

On my ARM system the scheduler was no longer scheduling any other task than
the idle task because the sched_clock() wrapped.

Signed-off-by: David Engraf 
---
 kernel/time/sched_clock.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/kernel/time/sched_clock.c b/kernel/time/sched_clock.c
index a26036d..382b159 100644
--- a/kernel/time/sched_clock.c
+++ b/kernel/time/sched_clock.c
@@ -205,6 +205,11 @@ sched_clock_register(u64 (*read)(void), int bits, unsigned 
long rate)
 
update_clock_read_data(&rd);
 
+   if (sched_clock_timer.function != NULL) {
+   /* update timeout for clock wrap */
+   hrtimer_start(&sched_clock_timer, cd.wrap_kt, HRTIMER_MODE_REL);
+   }
+
r = rate;
if (r >= 400) {
r /= 100;
-- 
2.9.3

Re: [PATCH fixes v3] pinctrl: Really force states during suspend/resume

[Andy Shevchenko]

On Wed, Mar 1, 2017 at 8:32 PM, Florian Fainelli  wrote:
> In case a platform only defaults a "default" set of pins, but not a
> "sleep" set of pins, and this particular platform suspends and resumes
> in a way that the pin states are not preserved by the hardware, when we
> resume, we would call pinctrl_single_resume() -> pinctrl_force_default()
> -> pinctrl_select_state() and the first thing we do is check that the
> pins state is the same as before, and do nothing.
>
> In order to fix this, decouple the actual state change from
> pinctrl_select_state() and move it pinctrl_commit_state(), while keeping
> the p->state == state check in pinctrl_select_state() not to change the
> caller assumptions. pinctrl_force_sleep() and pinctrl_force_default()
> are updated to bypass the state check by calling pinctrl_commit_state().
>
> Fixes: 6e5e959dde0d ("pinctrl: API changes to support multiple states per 
> device")
> Signed-off-by: Florian Fainelli 

This change is indeed beautiful and clean.

FWIW:
Reviewed-by: Andy Shevchenko 


> ---
> Changes in v3:
>
> - move the state check to pinctrl_select_state
>
> Changes in v2:
>
> - rename __pinctrl_select_state to pinctrl_commit_state
>
>  drivers/pinctrl/core.c | 24 +---
>  1 file changed, 17 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
> index fb38e208f32d..735d8f7f9d71 100644
> --- a/drivers/pinctrl/core.c
> +++ b/drivers/pinctrl/core.c
> @@ -992,19 +992,16 @@ struct pinctrl_state *pinctrl_lookup_state(struct 
> pinctrl *p,
>  EXPORT_SYMBOL_GPL(pinctrl_lookup_state);
>
>  /**
> - * pinctrl_select_state() - select/activate/program a pinctrl state to HW
> + * pinctrl_commit_state() - select/activate/program a pinctrl state to HW
>   * @p: the pinctrl handle for the device that requests configuration
>   * @state: the state handle to select/activate/program
>   */
> -int pinctrl_select_state(struct pinctrl *p, struct pinctrl_state *state)
> +static int pinctrl_commit_state(struct pinctrl *p, struct pinctrl_state 
> *state)
>  {
> struct pinctrl_setting *setting, *setting2;
> struct pinctrl_state *old_state = p->state;
> int ret;
>
> -   if (p->state == state)
> -   return 0;
> -
> if (p->state) {
> /*
>  * For each pinmux setting in the old state, forget SW's 
> record
> @@ -1068,6 +1065,19 @@ int pinctrl_select_state(struct pinctrl *p, struct 
> pinctrl_state *state)
>
> return ret;
>  }
> +
> +/**
> + * pinctrl_select_state() - select/activate/program a pinctrl state to HW
> + * @p: the pinctrl handle for the device that requests configuration
> + * @state: the state handle to select/activate/program
> + */
> +int pinctrl_select_state(struct pinctrl *p, struct pinctrl_state *state)
> +{
> +   if (p->state == state)
> +   return 0;
> +
> +   return pinctrl_commit_state(p, state);
> +}
>  EXPORT_SYMBOL_GPL(pinctrl_select_state);
>
>  static void devm_pinctrl_release(struct device *dev, void *res)
> @@ -1236,7 +1246,7 @@ void pinctrl_unregister_map(struct pinctrl_map const 
> *map)
>  int pinctrl_force_sleep(struct pinctrl_dev *pctldev)
>  {
> if (!IS_ERR(pctldev->p) && !IS_ERR(pctldev->hog_sleep))
> -   return pinctrl_select_state(pctldev->p, pctldev->hog_sleep);
> +   return pinctrl_commit_state(pctldev->p, pctldev->hog_sleep);
> return 0;
>  }
>  EXPORT_SYMBOL_GPL(pinctrl_force_sleep);
> @@ -1248,7 +1258,7 @@ EXPORT_SYMBOL_GPL(pinctrl_force_sleep);
>  int pinctrl_force_default(struct pinctrl_dev *pctldev)
>  {
> if (!IS_ERR(pctldev->p) && !IS_ERR(pctldev->hog_default))
> -   return pinctrl_select_state(pctldev->p, pctldev->hog_default);
> +   return pinctrl_commit_state(pctldev->p, pctldev->hog_default);
> return 0;
>  }
>  EXPORT_SYMBOL_GPL(pinctrl_force_default);
> --
> 2.9.3
>



-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2 1/2] pinctrl: rockchip：Add input schmitt support

[Kever Yang]

Hi David,

On 03/02/2017 03:11 PM, David Wu wrote:

From: "david.wu" 


You do not need to add this when you send mail for yourself,
it's need when you send mail for others.



To prevent external signal crosstalk, some pins need to
enable input schmitt, like i2c pins, 32k-input pin and so on.

Signed-off-by: david.wu 


Better to use "David Wu" for full name, you can correct this in your 
gitconfig file.


Thanks,
- Kever

---
changes in v2:
  - check the return value (Heiko)

  drivers/pinctrl/pinctrl-rockchip.c | 73 ++
  1 file changed, 73 insertions(+)

diff --git a/drivers/pinctrl/pinctrl-rockchip.c 
b/drivers/pinctrl/pinctrl-rockchip.c
index a20ce9f..9b8d516 100644
--- a/drivers/pinctrl/pinctrl-rockchip.c
+++ b/drivers/pinctrl/pinctrl-rockchip.c
@@ -308,6 +308,9 @@ struct rockchip_pin_ctrl {
int *reg, u8 *bit);
void(*iomux_recalc)(u8 bank_num, int pin, int *reg,
u8 *bit, int *mask);
+   int (*schmitt_calc_reg)(struct rockchip_pin_bank *bank,
+   int pin_num, struct regmap **regmap,
+   int *reg, u8 *bit);
  };
  
  struct rockchip_pin_config {

@@ -1355,6 +1358,57 @@ static int rockchip_set_pull(struct rockchip_pin_bank 
*bank,
return ret;
  }
  
+static int rockchip_get_schmitt(struct rockchip_pin_bank *bank, int pin_num)

+{
+   struct rockchip_pinctrl *info = bank->drvdata;
+   struct rockchip_pin_ctrl *ctrl = info->ctrl;
+   struct regmap *regmap;
+   int reg, ret;
+   u8 bit;
+   u32 data;
+
+   ret = ctrl->schmitt_calc_reg(bank, pin_num, ®map, ®, &bit);
+   if (ret)
+   return ret;
+
+   ret = regmap_read(regmap, reg, &data);
+   if (ret)
+   return ret;
+
+   data >>= bit;
+   return data & 0x1;
+}
+
+static int rockchip_set_schmitt(struct rockchip_pin_bank *bank,
+   int pin_num, int enable)
+{
+   struct rockchip_pinctrl *info = bank->drvdata;
+   struct rockchip_pin_ctrl *ctrl = info->ctrl;
+   struct regmap *regmap;
+   int reg, ret;
+   unsigned long flags;
+   u8 bit;
+   u32 data, rmask;
+
+   dev_dbg(info->dev, "setting input schmitt of GPIO%d-%d to %d\n",
+   bank->bank_num, pin_num, enable);
+
+   ret = ctrl->schmitt_calc_reg(bank, pin_num, ®map, ®, &bit);
+   if (ret)
+   return ret;
+
+   spin_lock_irqsave(&bank->slock, flags);
+
+   /* enable the write to the equivalent lower bits */
+   data = BIT(bit + 16) | (enable << bit);
+   rmask = BIT(bit + 16) | BIT(bit);
+
+   ret = regmap_update_bits(regmap, reg, rmask, data);
+   spin_unlock_irqrestore(&bank->slock, flags);
+
+   return ret;
+}
+
  /*
   * Pinmux_ops handling
   */
@@ -1574,6 +1628,15 @@ static int rockchip_pinconf_set(struct pinctrl_dev 
*pctldev, unsigned int pin,
if (rc < 0)
return rc;
break;
+   case PIN_CONFIG_INPUT_SCHMITT_ENABLE:
+   if (!info->ctrl->schmitt_calc_reg)
+   return -ENOTSUPP;
+
+   rc = rockchip_set_schmitt(bank,
+ pin - bank->pin_base, arg);
+   if (rc < 0)
+   return rc;
+   break;
default:
return -ENOTSUPP;
break;
@@ -1634,6 +1697,16 @@ static int rockchip_pinconf_get(struct pinctrl_dev 
*pctldev, unsigned int pin,
  
  		arg = rc;

break;
+   case PIN_CONFIG_INPUT_SCHMITT_ENABLE:
+   if (!info->ctrl->schmitt_calc_reg)
+   return -ENOTSUPP;
+
+   rc = rockchip_get_schmitt(bank, pin - bank->pin_base);
+   if (rc < 0)
+   return rc;
+
+   arg = rc;
+   break;
default:
return -ENOTSUPP;
break;

Re: [PATCH v2 3/5] dt-bindings: fix for Allwinner H5 pinctrl's compatible

[Maxime Ripard]

On Thu, Mar 02, 2017 at 02:01:09AM +0800, Icenowy Zheng wrote:
> The compatible for Allwinner H5 pin controller is wrong written as
> allwinner,sun50i-h5-r-pinctrl, however, it's really a generic pinctrl
> rather than a "r" one.
> 
> Fix this compatible string.
> 
> Signed-off-by: Icenowy Zheng 

Acked-by: Maxime Ripard 

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: [PATCH 2/2 RESEND] drm/vc4: Fix OOPSes from trying to cache a partially constructed BO.

[Boris Brezillon]

On Wed,  1 Mar 2017 10:56:02 -0800
Eric Anholt  wrote:

> If a CMA allocation failed, the partially constructed BO would be
> unreferenced through the normal path, and we might choose to put it in
> the BO cache.  If we then reused it before it expired from the cache,
> the kernel would OOPS.
> 
> Signed-off-by: Eric Anholt 
> Fixes: c826a6e10644 ("drm/vc4: Add a BO cache.")

Reviewed-by: Boris Brezillon 

> ---
>  drivers/gpu/drm/vc4/vc4_bo.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
> index e5c7aa935b4b..af29432a6471 100644
> --- a/drivers/gpu/drm/vc4/vc4_bo.c
> +++ b/drivers/gpu/drm/vc4/vc4_bo.c
> @@ -317,6 +317,14 @@ void vc4_free_object(struct drm_gem_object *gem_bo)
>   goto out;
>   }
>  
> + /* If this object was partially constructed but CMA allocation
> +  * had failed, just free it.
> +  */
> + if (!bo->base.vaddr) {
> + vc4_bo_destroy(bo);
> + goto out;
> + }
> +
>   cache_list = vc4_get_cache_list_for_size(dev, gem_bo->size);
>   if (!cache_list) {
>   vc4_bo_destroy(bo);

[PATCH V3 0/4] Add Spreadtrum SP9860G support

[Chunyan Zhang]

SC9860 is a Spreadtrum SoC with eight Cortex A53, which are divided
into 4 Big cores and 4 little cores.

This patch-set provides a basic configuration for SC9860 in device tree
to make it run to console.  After this we will continue to submit other
device drivers step by step, which are using on most of Spreadtrum's SoCs.

Changes from v2:
* Addressed comments from Mathieu
  - Removed CoreSight devices' lables from DT;
  - Added another level of imbrication for ETFs which have more than one port;
* Addressed comments from Rob
  - Switched to use SPDX-License-Identifier tag instead;
  - Moved the 26m fixed clock node to top level in DT;
  - Splited the patch into two, since they were revising two dt-bindings;
  - Removed redundant space from sprd-usrt.txt;
  - Removed useless property from the sprd_uart example of DT configuration.

Changes from v1:
* Removed useless idle-state node 'deep_sleep' from DT
* Removed useless property 'sc-id' from DT
* Removed 'clock-frequency' property from the node 'timer'
* Added another compatible string '"arm,cortex-a53-pmu"' and property
  'interrupt-affinity' for pmu
* Kept using the existed compatible string of sprd_serial driver, and added
  a new one for sc9860 in DT.

Thanks,
Chunyan

Chunyan Zhang (2):
  dt-bindings: arm: Add bindings for SP9860G
  dt-bindings: serial: add a new compatible string for SC9860

Orson Zhai (1):
  arm64: dts: Add basic DT to support Spreadtrum's SP9860G

Wei Qiao (1):
  serial: sprd: adjust TIMEOUT to a big value

 Documentation/devicetree/bindings/arm/sprd.txt |  13 +-
 .../devicetree/bindings/serial/sprd-uart.txt   |  15 +-
 arch/arm64/boot/dts/sprd/Makefile  |   3 +-
 arch/arm64/boot/dts/sprd/sc9860.dtsi   | 545 +
 arch/arm64/boot/dts/sprd/sp9860g-1h10.dts  |  56 +++
 arch/arm64/boot/dts/sprd/whale2.dtsi   |  71 +++
 drivers/tty/serial/sprd_serial.c   |   2 +-
 7 files changed, 697 insertions(+), 8 deletions(-)
 create mode 100644 arch/arm64/boot/dts/sprd/sc9860.dtsi
 create mode 100644 arch/arm64/boot/dts/sprd/sp9860g-1h10.dts
 create mode 100644 arch/arm64/boot/dts/sprd/whale2.dtsi

-- 
2.7.4

RE: [PATCH 3/3] PCI: Xilinx NWL PCIe: Fix Error for multi function device for legacy interrupts.

[Bharat Kumar Gogada]

Hi,

Any one is working on fix for this issue ? 

Regards,
Bharat

> -Original Message-
> From: Bjorn Helgaas [mailto:helg...@kernel.org]
> Sent: Tuesday, September 13, 2016 8:35 PM
> To: Marc Zyngier 
> Cc: Bharat Kumar Gogada ; r...@kernel.org;
> bhelg...@google.com; colin.k...@canonical.com; Soren Brinkmann
> ; Michal Simek ; a...@arndb.de;
> linux-arm-ker...@lists.infradead.org; linux-...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Ravikiran Gummaluri 
> Subject: Re: [PATCH 3/3] PCI: Xilinx NWL PCIe: Fix Error for multi function 
> device
> for legacy interrupts.
> 
> On Tue, Sep 13, 2016 at 08:41:28AM +0100, Marc Zyngier wrote:
> > On 12/09/16 23:02, Bjorn Helgaas wrote:
> > > On Thu, Sep 01, 2016 at 05:19:55AM +, Bharat Kumar Gogada wrote:
> > >>> Hi Bharat,
> >  @@ -561,7 +561,7 @@ static int
> >  nwl_pcie_init_irq_domain(struct nwl_pcie
> > >>> *pcie)
> >  }
> > 
> >  pcie->legacy_irq_domain =
> irq_domain_add_linear(legacy_intc_node,
> >  -   INTX_NUM,
> >  +   INTX_NUM
> >  + + 1,
> >  
> >  &legacy_domain_ops,
> >  pcie);
> > >>>
> > >>> This feels like the wrong thing to do. You have INTX_NUM irqs,
> > >>> so the domain allocation should reflect this. On the other
> > >>> hand, the way the driver currently deals with mappings is
> > >>> quite broken (consistently adding 1 to
> > > the HW interrupt).
> > >>>
> > >> Hi Marc,
> > >>
> > >> Without above change I get following crash in kernel while booting.
> > >>
> > >> [2.441684] error: hwirq 0x4 is too large for dummy
> > >>
> > >> [2.441694] [ cut here ]
> > >>
> > >> [2.441698] WARNING: at kernel/irq/irqdomain.c:344
> > >>
> > >> [2.441702] Modules linked in:
> > >>
> > >> [2.441706]
> > >>
> > >> [2.441714] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.4.0 #8
> > >>
> > >> [2.441718] Hardware name: xlnx,zynqmp (DT)
> > >>
> > >> [2.441723] task: ffc071886b80 ti: ffc071888000 task.ti:
> > > ffc071888000
> > >>
> > >> [2.441732] PC is at irq_domain_associate+0x138/0x1c0
> > >>
> > >> [2.441738] LR is at irq_domain_associate+0x138/0x1c0
> > >>
> > >> In kernel/irq/irqdomain.c function irq_domain_associate
> > >>
> > >> if (WARN(hwirq >= domain->hwirq_max,
> > >>  "error: hwirq 0x%x is too large for %s\n",
> > >> (int)hwirq, domain-
> >  name))
> > >> return -EINVAL;
> > >>
> > >> Here the hwirq and hwirq_max are equal to 4 without the above
> > >> condition
> > > (INTX_NUM + 1) due to which crash is coming.
> > >> This is happening as the legacy interrupts are starting from 1 
> > >> (INTA).
> > >
> > > I understood that. I'm still persisting in saying that you have the 
> > > wrong
> fix.
> > >
> > > Your domain should always allocate many interrupts as you have
> > > interrupt sources. These interrupts (hwirq) should be numbered
> > > from 0 to (n-
> > >>> 1).
> > 
> >  Agreed, but here comes the problem the hwirq for legacy
> >  interrupts will start at 0x1 to 0x4 (INTA to INTD) and these
> >  values are as per PCIe specification for legacy interrupts. So
> >  these cannot be numbered from 0. So when 0x4 (INTD) for a
> >  multi-function device comes the crash occurs.
> > >>>
> > >>> So who provides this hwirq? Who calls irq_domain_associate() with
> > >>> hwirq set to 4?
> > >>>
> > >> PCIe subsystem invokes pcibios_add_device function in
> arch/arm64/kernel/pci.c for every pci device.
> > >> The purpose of this function is to assign dev->irq using
> of_irq_parse_and_map_pci.
> > >> of_irq_parse_and_map_pci invokes of_irq_parse_pci where it reads
> > >> PCI_INTERRUPT_PIN from configuration space and saves it in parameter of
> struct of_phandle_args.
> > >> This structure is passed to irq_create_of_mapping where it invokes
> irq_create_fwspec_mapping.
> > >> irq_create_fwspec_mapping invokes irq_domain_translate and gets
> > >> hwirq, here the above saved PCI_INTERRUPT_PIN value is assigned to hwirq
> (*hwirq = fwspec->param[0]).
> > >> And then using this hwirq irq_create_mapping -> irq_domain_associate
> were invoked and mapping is created for virtual irq with this hwirq.
> > >> So for any end point PCI_INTERRUPT_PIN value starts from 0x1 to 0x4 and
> so hwirq starts from 0x1 to 0x4.
> > >>
> > >> So the values are more generic w.r.t to protocol, that's why hwirq will
> range from 0x1 to 0x4.
> > >> And then if you check pcie-altera.c they are doing this adding one in 
> > >> their
> handler an

Re: [PATCH 1/2 RESEND] drm/vc4: Fulfill user BO creation requests from the kernel BO cache.

[Boris Brezillon]

On Wed,  1 Mar 2017 10:56:01 -0800
Eric Anholt  wrote:

> The from_cache flag was actually "the BO is invisible to userspace",
> so we can repurpose it to just zero out a cached BO and return it to
> userspace.
> 
> Improves wall time for a loop of 5 glsl-algebraic-add-add-1 by
> -1.44989% +/- 0.862891% (n=28, 1 outlier removed from each that
> appeared to be other system noise)
> 
> Note that there's an intel-gpu-tools test to check for the proper
> zeroing behavior here, which we continue to pass.
> 
> Signed-off-by: Eric Anholt 

Reviewed-by: Boris Brezillon 

> ---
>  drivers/gpu/drm/vc4/vc4_bo.c | 13 +++--
>  1 file changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
> index 7abcd9c5dbe2..e5c7aa935b4b 100644
> --- a/drivers/gpu/drm/vc4/vc4_bo.c
> +++ b/drivers/gpu/drm/vc4/vc4_bo.c
> @@ -211,21 +211,22 @@ struct drm_gem_object *vc4_create_object(struct 
> drm_device *dev, size_t size)
>  }
>  
>  struct vc4_bo *vc4_bo_create(struct drm_device *dev, size_t unaligned_size,
> -  bool from_cache)
> +  bool allow_unzeroed)
>  {
>   size_t size = roundup(unaligned_size, PAGE_SIZE);
>   struct vc4_dev *vc4 = to_vc4_dev(dev);
>   struct drm_gem_cma_object *cma_obj;
> + struct vc4_bo *bo;
>  
>   if (size == 0)
>   return ERR_PTR(-EINVAL);
>  
>   /* First, try to get a vc4_bo from the kernel BO cache. */
> - if (from_cache) {
> - struct vc4_bo *bo = vc4_bo_get_from_cache(dev, size);
> -
> - if (bo)
> - return bo;
> + bo = vc4_bo_get_from_cache(dev, size);
> + if (bo) {
> + if (!allow_unzeroed)
> + memset(bo->base.vaddr, 0, bo->base.base.size);
> + return bo;
>   }
>  
>   cma_obj = drm_gem_cma_create(dev, size);

[PATCH] Revert "usb: gadget: uvc: Add missing call for additional setup data"

[Roger Quadros]

This reverts commit 4fbac5206afd01b717d4bdc58793d471f3391b4b.

This commit breaks g_webcam when used with uvc-gadget [1].

The user space application (e.g. uvc-gadget) is responsible for
sending response to UVC class specific requests on control endpoint
in uvc_send_response() in uvc_v4l2.c.

The bad commit was causing a duplicate response to be sent with
incorrect response data thus causing UVC probe to fail at the host
and broken control transfer endpoint at the gadget.

[1] - git://git.ideasonboard.org/uvc-gadget.git

Cc:  # v4.9+
Signed-off-by: Roger Quadros 
---
 drivers/usb/gadget/function/f_uvc.c | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/drivers/usb/gadget/function/f_uvc.c 
b/drivers/usb/gadget/function/f_uvc.c
index 27ed51b..29b41b5 100644
--- a/drivers/usb/gadget/function/f_uvc.c
+++ b/drivers/usb/gadget/function/f_uvc.c
@@ -258,13 +258,6 @@ uvc_function_setup(struct usb_function *f, const struct 
usb_ctrlrequest *ctrl)
memcpy(&uvc_event->req, ctrl, sizeof(uvc_event->req));
v4l2_event_queue(&uvc->vdev, &v4l2_event);
 
-   /* Pass additional setup data to userspace */
-   if (uvc->event_setup_out && uvc->event_length) {
-   uvc->control_req->length = uvc->event_length;
-   return usb_ep_queue(uvc->func.config->cdev->gadget->ep0,
-   uvc->control_req, GFP_ATOMIC);
-   }
-
return 0;
 }
 
-- 
2.7.4

Re: [PATCH] ARM: dump: Add domain to output

[Kees Cook]

On Wed, Mar 1, 2017 at 11:55 PM, Kees Cook  wrote:
> This adds the memory domain (on non-LPAE) to the PMD and PTE dumps. This
> isn't in the regular PMD bits because I couldn't find a clean way to
> fall back to retain some of the PMD bits when reporting PTE. So this is
> special-cased currently.

Ugh, please ignore this. Further testing shows this doesn't work
right... I'll keep poking at it.

-Kees

-- 
Kees Cook
Pixel Security

[PATCH v2] staging: speakup: Comparison to NULL could be written

[Arushi Singhal]

Fixed coding style for null comparisons in speakup driver to be more
consistant with the rest of the kernel coding style.

Signed-off-by: Arushi Singhal 
---
 changes in v2
 - fixed coding style error and upto the coding style.

 drivers/staging/speakup/fakekey.c  |  2 +-
 drivers/staging/speakup/kobjects.c |  2 +-
 drivers/staging/speakup/main.c | 38 +++---
 3 files changed, 21 insertions(+), 21 deletions(-)

diff --git a/drivers/staging/speakup/fakekey.c 
b/drivers/staging/speakup/fakekey.c
index d76da0a1382c..294c74b47224 100644
--- a/drivers/staging/speakup/fakekey.c
+++ b/drivers/staging/speakup/fakekey.c
@@ -56,7 +56,7 @@ int speakup_add_virtual_keyboard(void)
 
 void speakup_remove_virtual_keyboard(void)
 {
-   if (virt_keyboard != NULL) {
+   if (virt_keyboard) {
input_unregister_device(virt_keyboard);
virt_keyboard = NULL;
}
diff --git a/drivers/staging/speakup/kobjects.c 
b/drivers/staging/speakup/kobjects.c
index 5d871ec3693c..2fef55569bfd 100644
--- a/drivers/staging/speakup/kobjects.c
+++ b/drivers/staging/speakup/kobjects.c
@@ -391,7 +391,7 @@ static ssize_t synth_store(struct kobject *kobj, struct 
kobj_attribute *attr,
len--;
new_synth_name[len] = '\0';
spk_strlwr(new_synth_name);
-   if ((synth != NULL) && (!strcmp(new_synth_name, synth->name))) {
+   if (synth && !strcmp(new_synth_name, synth->name)) {
pr_warn("%s already in use\n", new_synth_name);
} else if (synth_init(new_synth_name) != 0) {
pr_warn("failed to init synth %s\n", new_synth_name);
diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c
index c2f70ef5b9b3..a12ec2b061fe 100644
--- a/drivers/staging/speakup/main.c
+++ b/drivers/staging/speakup/main.c
@@ -299,7 +299,7 @@ static void speakup_shut_up(struct vc_data *vc)
spk_shut_up |= 0x01;
spk_parked &= 0xfe;
speakup_date(vc);
-   if (synth != NULL)
+   if (synth)
spk_do_flush();
 }
 
@@ -441,7 +441,7 @@ static void speak_char(u_char ch)
synth_printf("%s", spk_str_caps_stop);
return;
}
-   if (cp == NULL) {
+   if (!cp) {
pr_info("speak_char: cp == NULL!\n");
return;
}
@@ -1157,7 +1157,7 @@ static void do_handle_shift(struct vc_data *vc, u_char 
value, char up_flag)
 {
unsigned long flags;
 
-   if (synth == NULL || up_flag || spk_killed)
+   if (!synth || up_flag || spk_killed)
return;
spin_lock_irqsave(&speakup_info.spinlock, flags);
if (cursor_track == read_all_mode) {
@@ -1195,7 +1195,7 @@ static void do_handle_latin(struct vc_data *vc, u_char 
value, char up_flag)
spin_unlock_irqrestore(&speakup_info.spinlock, flags);
return;
}
-   if (synth == NULL || spk_killed) {
+   if (!synth || spk_killed) {
spin_unlock_irqrestore(&speakup_info.spinlock, flags);
return;
}
@@ -1279,7 +1279,7 @@ void spk_reset_default_chars(void)
 
/* First, free any non-default */
for (i = 0; i < 256; i++) {
-   if ((spk_characters[i] != NULL)
+   if (spk_characters[i]
&& (spk_characters[i] != spk_default_chars[i]))
kfree(spk_characters[i]);
}
@@ -1321,10 +1321,10 @@ static int speakup_allocate(struct vc_data *vc)
int vc_num;
 
vc_num = vc->vc_num;
-   if (speakup_console[vc_num] == NULL) {
+   if (!speakup_console[vc_num]) {
speakup_console[vc_num] = kzalloc(sizeof(*speakup_console[0]),
  GFP_ATOMIC);
-   if (speakup_console[vc_num] == NULL)
+   if (!speakup_console[vc_num])
return -ENOMEM;
speakup_date(vc);
} else if (!spk_parked)
@@ -1373,7 +1373,7 @@ static void kbd_fakekey2(struct vc_data *vc, int command)
 
 static void read_all_doc(struct vc_data *vc)
 {
-   if ((vc->vc_num != fg_console) || synth == NULL || spk_shut_up)
+   if ((vc->vc_num != fg_console) || !synth || spk_shut_up)
return;
if (!synth_supports_indexing())
return;
@@ -1487,7 +1487,7 @@ static int pre_handle_cursor(struct vc_data *vc, u_char 
value, char up_flag)
spin_lock_irqsave(&speakup_info.spinlock, flags);
if (cursor_track == read_all_mode) {
spk_parked &= 0xfe;
-   if (synth == NULL || up_flag || spk_shut_up) {
+   if (!synth || up_flag || spk_shut_up) {
spin_unlock_irqrestore(&speakup_info.spinlock, flags);
return NOTIFY_STOP;
}
@@ -1509,7 +1509,7 @@ static void do_handle_cursor(struct vc_data *vc, u_char 
value, char up_flag)
 
spin_lock_irqsave(

Re: mm allocation failure and hang when running xfstests generic/269 on xfs

[Michal Hocko]

On Thu 02-03-17 12:17:47, Anshuman Khandual wrote:
> On 03/02/2017 10:49 AM, Xiong Zhou wrote:
> > On Wed, Mar 01, 2017 at 04:37:31PM -0800, Christoph Hellwig wrote:
> >> On Wed, Mar 01, 2017 at 12:46:34PM +0800, Xiong Zhou wrote:
> >>> Hi,
> >>>
> >>> It's reproduciable, not everytime though. Ext4 works fine.
> >> On ext4 fsstress won't run bulkstat because it doesn't exist.  Either
> >> way this smells like a MM issue to me as there were not XFS changes
> >> in that area recently.
> > Yap.
> > 
> > First bad commit:
> > 
> > commit 5d17a73a2ebeb8d1c6924b91e53ab2650fe86ffb
> > Author: Michal Hocko 
> > Date:   Fri Feb 24 14:58:53 2017 -0800
> > 
> > vmalloc: back off when the current task is killed
> > 
> > Reverting this commit on top of
> >   e5d56ef Merge tag 'watchdog-for-linus-v4.11'
> > survives the tests.
> 
> Does fsstress test or the system hang ? I am not familiar with this
> code but If it's the test which is getting hung and its hitting this
> new check introduced by the above commit that means the requester is
> currently being killed by OOM killer for some other memory allocation
> request.

Well, not exactly. It is sufficient for it to be _killed_ by SIGKILL.
And for that it just needs to do a group_exit when one thread was still
in the kernel (see zap_process). While I can change this check to
actually do the oom specific check I believe a more generic
fatal_signal_pending is the right thing to do here. I am still not sure
what is the actual problem here, though. Could you be more specific
please?

-- 
Michal Hocko
SUSE Labs

[tip:efi/urgent] efi/libstub: Treat missing SecureBoot variable as Secure Boot disabled

[tip-bot for Ard Biesheuvel]

Commit-ID:  52e51f16407b7b34e26affb500a21e250d9fce0b
Gitweb: http://git.kernel.org/tip/52e51f16407b7b34e26affb500a21e250d9fce0b
Author: Ard Biesheuvel 
AuthorDate: Wed, 1 Mar 2017 19:04:35 +
Committer:  Ingo Molnar 
CommitDate: Thu, 2 Mar 2017 08:11:18 +0100

efi/libstub: Treat missing SecureBoot variable as Secure Boot disabled

The newly refactored code that infers the firmware's Secure Boot state
prints the following error when the EFI variable 'SecureBoot' does not
exist:

  EFI stub: ERROR: Could not determine UEFI Secure Boot status.

However, this variable is only guaranteed to be defined on a system that
is Secure Boot capable to begin with, and so it is not an error if it is
missing. So report Secure Boot as being disabled in this case, without
printing any error messages.

Signed-off-by: Ard Biesheuvel 
Cc: Linus Torvalds 
Cc: Matt Fleming 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-...@vger.kernel.org
Link: 
http://lkml.kernel.org/r/1488395076-29712-2-git-send-email-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar 
---
 drivers/firmware/efi/libstub/secureboot.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/firmware/efi/libstub/secureboot.c 
b/drivers/firmware/efi/libstub/secureboot.c
index 6def402..5da36e5 100644
--- a/drivers/firmware/efi/libstub/secureboot.c
+++ b/drivers/firmware/efi/libstub/secureboot.c
@@ -45,6 +45,8 @@ enum efi_secureboot_mode 
efi_get_secureboot(efi_system_table_t *sys_table_arg)
size = sizeof(secboot);
status = get_efi_var(efi_SecureBoot_name, &efi_variable_guid,
 NULL, &size, &secboot);
+   if (status == EFI_NOT_FOUND)
+   return efi_secureboot_mode_disabled;
if (status != EFI_SUCCESS)
goto out_efi_err;
 
@@ -78,7 +80,5 @@ secure_boot_enabled:
 
 out_efi_err:
pr_efi_err(sys_table_arg, "Could not determine UEFI Secure Boot 
status.\n");
-   if (status == EFI_NOT_FOUND)
-   return efi_secureboot_mode_disabled;
return efi_secureboot_mode_unknown;
 }

[tip:x86/urgent] x86/hpet: Prevent might sleep splat on resume

[tip-bot for Thomas Gleixner]

Commit-ID:  bb1a2c26165640ba2cbcfe06c81e9f9d6db4e643
Gitweb: http://git.kernel.org/tip/bb1a2c26165640ba2cbcfe06c81e9f9d6db4e643
Author: Thomas Gleixner 
AuthorDate: Wed, 1 Mar 2017 21:10:17 +0100
Committer:  Thomas Gleixner 
CommitDate: Thu, 2 Mar 2017 09:33:47 +0100

x86/hpet: Prevent might sleep splat on resume

Sergey reported a might sleep warning triggered from the hpet resume
path. It's caused by the call to disable_irq() from interrupt disabled
context.

The problem with the low level resume code is that it is not accounted as a
special system_state like we do during the boot process. Calling the same
code during system boot would not trigger the warning. That's inconsistent
at best.

In this particular case it's trivial to replace the disable_irq() with
disable_hardirq() because this particular code path is solely used from
system resume and the involved hpet interrupts can never be force threaded.


Reported-and-tested-by: Sergey Senozhatsky 
Signed-off-by: Thomas Gleixner 
Cc: Peter Zijlstra 
Cc: "Rafael J. Wysocki" 
Cc: Sergey Senozhatsky 
Cc: Borislav Petkov 
Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1703012108460.3684@nanos
Signed-off-by: Thomas Gleixner 

---
 arch/x86/kernel/hpet.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c
index dc6ba5b..89ff7af 100644
--- a/arch/x86/kernel/hpet.c
+++ b/arch/x86/kernel/hpet.c
@@ -354,7 +354,7 @@ static int hpet_resume(struct clock_event_device *evt, int 
timer)
 
irq_domain_deactivate_irq(irq_get_irq_data(hdev->irq));
irq_domain_activate_irq(irq_get_irq_data(hdev->irq));
-   disable_irq(hdev->irq);
+   disable_hardirq(hdev->irq);
irq_set_affinity(hdev->irq, cpumask_of(hdev->cpu));
enable_irq(hdev->irq);
}

Re: [PATCH v2 1/2] extcon: cros-ec: Add extcon-cros-ec driver to support display out.

[Chanwoo Choi]

Hi,

On 2017년 03월 01일 20:19, Enric Balletbo i Serra wrote:
> From: Benson Leung 
> 
> This is the driver for the USB Type C cable detection mechanism
> built into the ChromeOS Embedded Controller on systems that
> have USB Type-C ports.
> 
> At present, this allows for the presence of display out, but in
> future, it may also be used to notify host and device type cables
> and the presence of power.
> 
> Signed-off-by: Benson Leung 
> Signed-off-by: Enric Balletbo i Serra 
> ---
> Changes since v1:
>  Requested by Chanwoo Choi
>  - Rename files changing _ for -
>  - Remove the unneeded blank line on bottom of header.
>  - Remove kobject.h and cros_ec_commands.h includes.
>  - Remove the debug message as is not necessary.
>  - Use the tab for indentation instead of space for if sentence.
>  - Define each variable on different lines when the variables should be
>initialized.
>  - Remove EXTCON_USB and EXTCON_USB_HOST as are not really used for now.
>  - Add one blank line to split out between state and property setting.
>  - Add the author information (header and module)
> 
>  Enric Balletbo
>  - As Rob suggested to rename the compatible name to something indicating that
>is USB Type C related I also renamed the file names, extcon-cros-ec ->
>extcon-usbc-cros-ec, I think it's more clear.
> 
>  drivers/extcon/Kconfig   |   7 +
>  drivers/extcon/Makefile  |   1 +
>  drivers/extcon/extcon-usbc-cros-ec.c | 415 
> +++
>  include/linux/mfd/cros_ec_commands.h |  75 +++
>  4 files changed, 498 insertions(+)
>  create mode 100644 drivers/extcon/extcon-usbc-cros-ec.c
> 

Looks good to me.
Acked-by: Chanwoo Choi 

I think this patch should be handled with patches[1].
[1] https://lkml.org/lkml/2017/2/14/655

I think that one maintainer among following subsystems
(mfd, chrome h/w platform, rtc and extcon)
will apply their git repository, and then one maintainer
will send the pull request of immutable branch for these patches.

-- 
Best Regards,
Chanwoo Choi
Samsung Electronics

[tip:efi/urgent] efi/arm: Fix boot crash with CONFIG_CPUMASK_OFFSTACK=y

[tip-bot for Ard Biesheuvel]

Commit-ID:  d1eb98143c56f24fef125f5bbed49ae0b52fb7d6
Gitweb: http://git.kernel.org/tip/d1eb98143c56f24fef125f5bbed49ae0b52fb7d6
Author: Ard Biesheuvel 
AuthorDate: Wed, 1 Mar 2017 19:05:54 +
Committer:  Ingo Molnar 
CommitDate: Thu, 2 Mar 2017 08:11:19 +0100

efi/arm: Fix boot crash with CONFIG_CPUMASK_OFFSTACK=y

On ARM and arm64, we use a dedicated mm_struct to map the UEFI
Runtime Services regions, which allows us to map those regions
on demand, and in a way that is guaranteed to be compatible
with incoming kernels across kexec.

As it turns out, we don't fully initialize the mm_struct in the
same way as process mm_structs are initialized on fork(), which
results in the following crash on ARM if CONFIG_CPUMASK_OFFSTACK=y
is enabled:

  ...
  EFI Variables Facility v0.08 2004-May-17
  Unable to handle kernel NULL pointer dereference at virtual address 
  [...]
  Process swapper/0 (pid: 1)
  ...
  __memzero()
  check_and_switch_context()
  virt_efi_get_next_variable()
  efivar_init()
  efivars_sysfs_init()
  do_one_initcall()
  ...

This is due to a missing call to mm_init_cpumask(), so add it.

Signed-off-by: Ard Biesheuvel 
Cc:  # v4.5+
Cc: Linus Torvalds 
Cc: Matt Fleming 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-...@vger.kernel.org
Link: 
http://lkml.kernel.org/r/1488395154-29786-1-git-send-email-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar 
---
 drivers/firmware/efi/arm-runtime.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/firmware/efi/arm-runtime.c 
b/drivers/firmware/efi/arm-runtime.c
index 349dc3e..974c5a3 100644
--- a/drivers/firmware/efi/arm-runtime.c
+++ b/drivers/firmware/efi/arm-runtime.c
@@ -65,6 +65,7 @@ static bool __init efi_virtmap_init(void)
bool systab_found;
 
efi_mm.pgd = pgd_alloc(&efi_mm);
+   mm_init_cpumask(&efi_mm);
init_new_context(NULL, &efi_mm);
 
systab_found = false;

[tip:locking/urgent] locking/ww_mutex: Replace cpu_relax() with cond_resched() for tests

[tip-bot for Chris Wilson]

Commit-ID:  2b232e0c3b3a09f3e33750aa20e314f1b80e5361
Gitweb: http://git.kernel.org/tip/2b232e0c3b3a09f3e33750aa20e314f1b80e5361
Author: Chris Wilson 
AuthorDate: Tue, 28 Feb 2017 09:40:11 +
Committer:  Ingo Molnar 
CommitDate: Thu, 2 Mar 2017 09:00:38 +0100

locking/ww_mutex: Replace cpu_relax() with cond_resched() for tests

When busy-spinning on a ww_mutex_trylock(), we depend upon the other
thread advancing and releasing the lock. This can not happen on a single
CPU unless we relinquish it:

  [ ] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [kworker/0:1:18]
  ...
  [ ] Call Trace:
  [ ]  mutex_trylock()
  [ ]  test_mutex_work+0x31/0x56
  [ ]  process_one_work+0x1b4/0x2f9
  [ ]  worker_thread+0x1b0/0x27c
  [ ]  kthread+0xd1/0xd3
  [ ]  ret_from_fork+0x19/0x30

Reported-by: Fengguang Wu 
Signed-off-by: Chris Wilson 
Signed-off-by: Peter Zijlstra (Intel) 
Cc: Andrew Morton 
Cc: Linus Torvalds 
Cc: Paul E. McKenney 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Fixes: f2a5fec17395 ("locking/ww_mutex: Begin kselftests for ww_mutex")
Link: http://lkml.kernel.org/r/20170228094011.2595-1-ch...@chris-wilson.co.uk
Signed-off-by: Ingo Molnar 
---
 kernel/locking/test-ww_mutex.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/locking/test-ww_mutex.c b/kernel/locking/test-ww_mutex.c
index da6c9a3..3eb39c5 100644
--- a/kernel/locking/test-ww_mutex.c
+++ b/kernel/locking/test-ww_mutex.c
@@ -50,7 +50,7 @@ static void test_mutex_work(struct work_struct *work)
 
if (mtx->flags & TEST_MTX_TRY) {
while (!ww_mutex_trylock(&mtx->mutex))
-   cpu_relax();
+   cond_resched();
} else {
ww_mutex_lock(&mtx->mutex, NULL);
}
@@ -88,7 +88,7 @@ static int __test_mutex(unsigned int flags)
ret = -EINVAL;
break;
}
-   cpu_relax();
+   cond_resched();
} while (time_before(jiffies, timeout));
} else {
ret = wait_for_completion_timeout(&mtx.done, TIMEOUT);

[tip:locking/urgent] locking/ww_mutex: Adjust the lock number for stress test

[tip-bot for Boqun Feng]

Commit-ID:  857811a37129f5d2ba162d7be3986eff44724014
Gitweb: http://git.kernel.org/tip/857811a37129f5d2ba162d7be3986eff44724014
Author: Boqun Feng 
AuthorDate: Wed, 1 Mar 2017 23:01:38 +0800
Committer:  Ingo Molnar 
CommitDate: Thu, 2 Mar 2017 09:00:39 +0100

locking/ww_mutex: Adjust the lock number for stress test

Because there are only 12 bits in held_lock::references, so we only
support 4095 nested lock held in the same time, adjust the lock number
for ww_mutex stress test to kill one lockdep splat:

  [ ] [ BUG: bad unlock balance detected! ]
  [ ] kworker/u2:0/5 is trying to release lock (ww_class_mutex) at:
  [ ] ww_mutex_unlock()
  [ ] but there are no more locks to release!
  ...

Signed-off-by: Boqun Feng 
Signed-off-by: Peter Zijlstra (Intel) 
Cc: Andrew Morton 
Cc: Chris Wilson 
Cc: Fengguang Wu 
Cc: Linus Torvalds 
Cc: Nicolai Hähnle 
Cc: Paul E. McKenney 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/20170301150138.hdixnmafzfsox...@tardis.cn.ibm.com
Signed-off-by: Ingo Molnar 
---
 kernel/locking/test-ww_mutex.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/locking/test-ww_mutex.c b/kernel/locking/test-ww_mutex.c
index 3eb39c5..6b7abb3 100644
--- a/kernel/locking/test-ww_mutex.c
+++ b/kernel/locking/test-ww_mutex.c
@@ -627,7 +627,7 @@ static int __init test_ww_mutex_init(void)
if (ret)
return ret;
 
-   ret = stress(4096, hweight32(STRESS_ALL)*ncpus, 1<<12, STRESS_ALL);
+   ret = stress(4095, hweight32(STRESS_ALL)*ncpus, 1<<12, STRESS_ALL);
if (ret)
return ret;
 

[PATCH 0/3] cupfreq: schedutil: Minor fix and cleanups

[Viresh Kumar]

Hi,

The first patch fixes an issue and the other two do cleanups. I have run
hackbench with these patches and no regressions were noticed.

--
viresh

Viresh Kumar (3):
  cpufreq: schedutil: move cached_raw_freq to struct sugov_policy
  cpufreq: schedutil: Pass sg_policy to get_next_freq()
  cpufreq: schedutil: remove redundant code from
sugov_next_freq_shared()

 kernel/sched/cpufreq_schedutil.c | 37 +
 1 file changed, 13 insertions(+), 24 deletions(-)

-- 
2.7.1.410.g6faf27b

Re: [GIT PULL] vfs patches for 4.11

[Amir Goldstein]

On Mon, Feb 20, 2017 at 7:17 PM, Al Viro  wrote:
> On Mon, Feb 20, 2017 at 05:19:00PM +0100, Miklos Szeredi wrote:
>> Hi Al,
>>
>> Please pull from:
>>
>>   git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git for-viro
>>
>> Amir Goldstein (4):
>>   vfs: create vfs helper vfs_tmpfile()
>>   vfs: deny fallocate() on directory
>>   vfs: deny copy_file_range() for non regular files
>>   vfs: wrap write f_ops with file_{start,end}_write()
>
> The last one could have a better summary, but anyway - pulled.

Al,

Please excuse my impatience, but do you plan to send these out to
Linus for 4.11?

If not, Miklos, could possibly ask Linus to pull overlayfs-next, which have been
soaking in linux-next for a while now.

overlayfs-next contains only my 4 VFS patches above, which are not that
controversial IMO.

It'd be nice to get rid of the "big copy up lock" for 4.11.

Thanks,
Amir.

[PATCH 3/3] cpufreq: schedutil: remove redundant code from sugov_next_freq_shared()

[Viresh Kumar]

The same code is present both within and outside the loop and it doesn't
look like it provides any additional benefit. Remove the special
handling of sg_cpu and let it happen within the loop.

With this change we will do two extra comparisons for the sg_cpu in the
loop, but the loop will do one less comparison for every other CPU in
the policy.

While at it, also remove the excess parameters of sugov_next_freq_shared().

Signed-off-by: Viresh Kumar 
---
 kernel/sched/cpufreq_schedutil.c | 18 --
 1 file changed, 4 insertions(+), 14 deletions(-)

diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c
index 570925ea7253..ec56537429a8 100644
--- a/kernel/sched/cpufreq_schedutil.c
+++ b/kernel/sched/cpufreq_schedutil.c
@@ -216,30 +216,20 @@ static void sugov_update_single(struct update_util_data 
*hook, u64 time,
sugov_update_commit(sg_policy, time, next_f);
 }
 
-static unsigned int sugov_next_freq_shared(struct sugov_cpu *sg_cpu,
-  unsigned long util, unsigned long 
max,
-  unsigned int flags)
+static unsigned int sugov_next_freq_shared(struct sugov_cpu *sg_cpu)
 {
struct sugov_policy *sg_policy = sg_cpu->sg_policy;
struct cpufreq_policy *policy = sg_policy->policy;
unsigned int max_f = policy->cpuinfo.max_freq;
u64 last_freq_update_time = sg_policy->last_freq_update_time;
+   unsigned long util = 0, max = 1;
unsigned int j;
 
-   if (flags & SCHED_CPUFREQ_RT_DL)
-   return max_f;
-
-   sugov_iowait_boost(sg_cpu, &util, &max);
-
for_each_cpu(j, policy->cpus) {
-   struct sugov_cpu *j_sg_cpu;
+   struct sugov_cpu *j_sg_cpu = &per_cpu(sugov_cpu, j);
unsigned long j_util, j_max;
s64 delta_ns;
 
-   if (j == smp_processor_id())
-   continue;
-
-   j_sg_cpu = &per_cpu(sugov_cpu, j);
/*
 * If the CPU utilization was last updated before the previous
 * frequency update and the time elapsed between the last update
@@ -288,7 +278,7 @@ static void sugov_update_shared(struct update_util_data 
*hook, u64 time,
sg_cpu->last_update = time;
 
if (sugov_should_update_freq(sg_policy, time)) {
-   next_f = sugov_next_freq_shared(sg_cpu, util, max, flags);
+   next_f = sugov_next_freq_shared(sg_cpu);
sugov_update_commit(sg_policy, time, next_f);
}
 
-- 
2.7.1.410.g6faf27b

Re: Still OOM problems with 4.9er/4.10er kernels

[Minchan Kim]

Hi Michal,

On Tue, Feb 28, 2017 at 09:12:24AM +0100, Michal Hocko wrote:
> On Tue 28-02-17 14:17:23, Minchan Kim wrote:
> > On Mon, Feb 27, 2017 at 10:44:49AM +0100, Michal Hocko wrote:
> > > On Mon 27-02-17 18:02:36, Minchan Kim wrote:
> > > [...]
> > > > >From 9779a1c5d32e2edb64da5cdfcd6f9737b94a247a Mon Sep 17 00:00:00 2001
> > > > From: Minchan Kim 
> > > > Date: Mon, 27 Feb 2017 17:39:06 +0900
> > > > Subject: [PATCH] mm: use up highatomic before OOM kill
> > > > 
> > > > Not-Yet-Signed-off-by: Minchan Kim 
> > > > ---
> > > >  mm/page_alloc.c | 14 --
> > > >  1 file changed, 4 insertions(+), 10 deletions(-)
> > > > 
> > > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > > > index 614cd0397ce3..e073cca4969e 100644
> > > > --- a/mm/page_alloc.c
> > > > +++ b/mm/page_alloc.c
> > > > @@ -3549,16 +3549,6 @@ should_reclaim_retry(gfp_t gfp_mask, unsigned 
> > > > order,
> > > > *no_progress_loops = 0;
> > > > else
> > > > (*no_progress_loops)++;
> > > > -
> > > > -   /*
> > > > -* Make sure we converge to OOM if we cannot make any progress
> > > > -* several times in the row.
> > > > -*/
> > > > -   if (*no_progress_loops > MAX_RECLAIM_RETRIES) {
> > > > -   /* Before OOM, exhaust highatomic_reserve */
> > > > -   return unreserve_highatomic_pageblock(ac, true);
> > > > -   }
> > > > -
> > > > /*
> > > >  * Keep reclaiming pages while there is a chance this will lead
> > > >  * somewhere.  If none of the target zones can satisfy our 
> > > > allocation
> > > > @@ -3821,6 +3811,10 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned 
> > > > int order,
> > > > if (read_mems_allowed_retry(cpuset_mems_cookie))
> > > > goto retry_cpuset;
> > > >  
> > > > +   /* Before OOM, exhaust highatomic_reserve */
> > > > +   if (unreserve_highatomic_pageblock(ac, true))
> > > > +   goto retry;
> > > > +
> > > 
> > > OK, this can help for higher order requests when we do not exhaust all
> > > the retries and fail on compaction but I fail to see how can this help
> > > for order-0 requets which was what happened in this case. I am not
> > > saying this is wrong, though.
> > 
> > The should_reclaim_retry can return false although no_progress_loop is less
> > than MAX_RECLAIM_RETRIES unless eligible zones has enough reclaimable pages
> > by the progress_loop.
> 
> Yes, sorry I should have been more clear. I was talking about this
> particular case where we had a lot of reclaimable pages (a lot of
> anonymous with the swap available).

This reports shows two problems. Why we see OOM 1) enough *free* pages and
2) enough *freeable* pages.

I just pointed out 1) and sent the patch to solve it.

About 2), one of my imaginary scenario is inactive anon list is full of
pinned pages so VM can unmap them successfully in shrink_page_list but fail
to free due to increased page refcount. In that case, the page will be added
to inactive anonymous LRU list again without activating so inactive_list_is_low
on anonymous LRU is always false. IOW, there is no deactivation from active 
list.

It's just my picture without no clue. ;-)

FW: RE: Re: FW: RE: Re: Subject: [PATCH v3] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

[Ajay Kaher]

> On Wed, 1 Mar 2017, Alan Stern wrote:
>> On Wed, 1 Mar 2017, Ajay Kaher wrote:
>>> On Mon, 22 Feb 2017, Ajay Kaher wrote:
>>> 
 
> Alan, as per my understanding I have shifted the lock from
> release_usb_class() to destroy_usb_class() in patch v3. 
> If it is not right, please explain in detail which race condition
> I have missed and also share your suggestions.
> 
 
 Have you considered what would happen if destroy_usb_class() ran, but 
 some other CPU was still holding a reference to usb_class?  And what if 
 the last reference gets dropped later on, while init_usb_class() is 
 running?
>>> 
>>> Access of usb_class->kref is only from either init_usb_class()
>>> or destroy_usb_class(), and both these functions are now protected
>>> with Mutex Locking in patch v3, so there is no chance of race condition
>>> as per above scenarios.
>>> 
 Maybe that's not possible here, but it is possible in general for 
 refcounted objects.  So yes, this code is probably okay, but it isn't 
 good form.
>>> 
>>> As per my understanding, I found to be one of the best possible solution
>>> for this problem and this solutiuon don't have any side effect.
>> 
>> Alan, I had shared modified Patch v3 as per your inputs to prevent
>> the race condition during simultaneously calling of init_usb_class().
>> If you think there is scope to improve the patch, please share your inputs.
> 
> Under the circumstances, your patch is acceptable.
> 
> If you really want to make the point crystal clear, you could replace 
> usb_class->kref with an ordinary integer counter.  Then it would be 
> obvious that there are no references other than the ones taken by 
> init_usb_class() and released by destroy_usb_class().
 
usb_class->kref is not accessible outside the file.c
as usb_class is _static_ inside the file.c and
pointer of usb_class->kref is not passed anywhere.

Hence as you wanted, there are no references of usb_class->kref
other than taken by init_usb_class() and released by destroy_usb_class().

 
thanks,
ajay kaher
 
 
Signed-off-by: Ajay Kaher
 
---
 
 drivers/usb/core/file.c |6 ++
 1 file changed, 6 insertions(+)
 
diff --git a/drivers/usb/core/file.c b/drivers/usb/core/file.c
index 822ced9..a12d184 100644
--- a/drivers/usb/core/file.c
+++ b/drivers/usb/core/file.c
@@ -27,6 +27,7 @@
 #define MAX_USB_MINORS 256
 static const struct file_operations *usb_minors[MAX_USB_MINORS];
 static DECLARE_RWSEM(minor_rwsem);
+static DEFINE_MUTEX(init_usb_class_mutex);
 
 static int usb_open(struct inode *inode, struct file *file)
 {
@@ -109,8 +110,10 @@ static void release_usb_class(struct kref *kref)
 
 static void destroy_usb_class(void)
 {
+   mutex_lock(&init_usb_class_mutex);
if (usb_class)
kref_put(&usb_class->kref, release_usb_class);
+   mutex_unlock(&init_usb_class_mutex);
 }
 
 int usb_major_init(void)
@@ -171,7 +174,10 @@ int usb_register_dev(struct usb_interface *intf,
if (intf->minor >= 0)
return -EADDRINUSE;
 
+   mutex_lock(&init_usb_class_mutex);
retval = init_usb_class();
+   mutex_unlock(&init_usb_class_mutex);
+
if (retval)
return retval;
 
 
 
Thanks and Regards,
Ajay Kaher

Re: [RFC v2 2/3] kcmp: Add KCMP_EPOLL_TFD mode to compare epoll target files

[Cyrill Gorcunov]

On Wed, Mar 01, 2017 at 03:05:09PM -0800, Andrei Vagin wrote:
> 
> I rewrote this function and I think it looks more readable now. What do you
> think?
>

Agreed! I'll prepare new version for the whole set and resend.
Thank you!

Re: [PATCH v2 4/4] acpi: Move the verification of duplicate proc_id from booting time to hot-plug time

[Dou Liyang]

Hi tglx,

At 03/01/2017 07:26 PM, Thomas Gleixner wrote:

On Mon, 20 Feb 2017, Dou Liyang wrote:

Please make your subject line short and a precise summary phrase, not an
overlong sentence.


After we revert the the mapping of "cpuid <-> nodeid" fixed at the
booting time. and do it at the hot-plug time. we should also do the
verification of duplicate proc_id at the time.


The revert is completely irrelevant to this change, really. The reference
is just confusing.



Yes, Maybe I should split them like before.



The patch rename the verfication function and move it to
drivers/acpi::acpi_processor_get_info.


See previous mails 

Let me give you another changelog example:



Thanks again.


Subject: acpi/processor: Check for duplicate processor ids at hotplug time

  The check for duplicate processor ids happens at boot time based on the
  ACPI table contents, but the final sanity checks for a processor happen
  at hotplug time.

  At hotplug time, where the physical information is available, which might
  differ from the ACPI table information, a check for duplicate processor
  ids is missing.

  Add it to the hotplug checks and rename the function so it better
  reflects its purpose.

Hmm?


Yes, thanks again. I learned a lot in that patchset.





-bool __init acpi_processor_validate_proc_id(int proc_id)
+bool duplicate_processor_id(int proc_id)


Please keep the acpi_ prefix. acpi_duplicate_processor_id().


OK, I will.

Thanks,

Liyang.


Thanks,

tglx

[PATCH 2/3] cpufreq: schedutil: Pass sg_policy to get_next_freq()

[Viresh Kumar]

get_next_freq() uses sg_cpu only to get sg_policy, which the callers of
get_next_freq() already have. Pass sg_policy instead of sg_cpu to
get_next_freq(), to make it more efficient.

Signed-off-by: Viresh Kumar 
---
 kernel/sched/cpufreq_schedutil.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c
index 721f4e011366..570925ea7253 100644
--- a/kernel/sched/cpufreq_schedutil.c
+++ b/kernel/sched/cpufreq_schedutil.c
@@ -115,7 +115,7 @@ static void sugov_update_commit(struct sugov_policy 
*sg_policy, u64 time,
 
 /**
  * get_next_freq - Compute a new frequency for a given cpufreq policy.
- * @sg_cpu: schedutil cpu object to compute the new frequency for.
+ * @sg_policy: schedutil policy object to compute the new frequency for.
  * @util: Current CPU utilization.
  * @max: CPU capacity.
  *
@@ -135,10 +135,9 @@ static void sugov_update_commit(struct sugov_policy 
*sg_policy, u64 time,
  * next_freq (as calculated above) is returned, subject to policy min/max and
  * cpufreq driver limitations.
  */
-static unsigned int get_next_freq(struct sugov_cpu *sg_cpu, unsigned long util,
- unsigned long max)
+static unsigned int get_next_freq(struct sugov_policy *sg_policy,
+ unsigned long util, unsigned long max)
 {
-   struct sugov_policy *sg_policy = sg_cpu->sg_policy;
struct cpufreq_policy *policy = sg_policy->policy;
unsigned int freq = arch_scale_freq_invariant() ?
policy->cpuinfo.max_freq : policy->cur;
@@ -212,7 +211,7 @@ static void sugov_update_single(struct update_util_data 
*hook, u64 time,
} else {
sugov_get_util(&util, &max);
sugov_iowait_boost(sg_cpu, &util, &max);
-   next_f = get_next_freq(sg_cpu, util, max);
+   next_f = get_next_freq(sg_policy, util, max);
}
sugov_update_commit(sg_policy, time, next_f);
 }
@@ -266,7 +265,7 @@ static unsigned int sugov_next_freq_shared(struct sugov_cpu 
*sg_cpu,
sugov_iowait_boost(j_sg_cpu, &util, &max);
}
 
-   return get_next_freq(sg_cpu, util, max);
+   return get_next_freq(sg_policy, util, max);
 }
 
 static void sugov_update_shared(struct update_util_data *hook, u64 time,
-- 
2.7.1.410.g6faf27b

Re: [PATCH v2 0/4] fujitsu_init() cleanup

[Michał Kępień]

> On Wed, Mar 01, 2017 at 09:10:40AM +0100, Micha?? K??pie?? wrote:
> > These patches should make fujitsu_init() a bit more palatable.  No
> > changes are made to platform device code yet, for clarity these will be
> > posted in a separate series after this one gets applied.
> 
> Thanks for these.  As for the other series you posted I will endeavour to
> review and test within the next 48 hours.  I note the particular testing
> requirements of patch 2/4.
> 
> Could you confirm which git tree you've based these off?

Sure, both series posted yesterday are based on dvhart/testing as that
is where Alan's reworked series is currently applied.  I posted them as
separate series for consistency with previous submissions and also
because they are independent, i.e. can be applied in any order.

-- 
Best regards,
Michał Kępień

Re: [PATCH v2 2/4] Revert"x86/acpi: Enable MADT APIs to return disabled apicids"

[Dou Liyang]

Hi tglx,

At 03/01/2017 06:52 PM, Thomas Gleixner wrote:

On Mon, 20 Feb 2017, Dou Liyang wrote:


After we never do the last mapping of "cpuid <-> nodeid" at booting time. we
also no need to enable MADT APIs to return disabled apicid.

So, The patch work for reverting the commit 8ad893faf2:
"x86/acpi: Enable MADT APIs to return disabled apicids"


Again, this changelog is confusing. A simple:

  Remove the leftovers of the boot time 'cpuid <-> nodeid' mapping approach.

would be sufficient and entirely clear.



Yes, I see, I will rewrite it in next version.

Thanks.

Liyang.


Thanks,

tglx

Re: [PATCH v2 3/4] acpi: Fix the check handle in case of declaring processors using the Device operator

[Dou Liyang]

Hi tglx,

At 03/01/2017 07:12 PM, Thomas Gleixner wrote:

On Mon, 20 Feb 2017, Dou Liyang wrote:


In ACPI spec, we can declare processors using both Processor and
Device operator. And before we use the ACPI table, we should check
the correctness for all processors in ACPI namespace.

But, Currently, the check handle is just include only the processors
which are declared by Processor operator. It misses the processors
declared by Device operator.

The patch adds the case of Device operator.


See the comments in the previous mails. They apply here as well.

Though this changelog is actively confusing. The subject line says:

  acpi: Fix the check handle in case of declaring processors using the Device
operator

Aside of being a way too long subject, it suggests that there is just a
missing check for the case where a processor is declared via the Device
operator. But that's not what the patch is doing.

It implements the distinction between Device and Processor operator, which
is missing in acpi_processor_ids_walk() right now.

So the proper changelog (if I understand the patch correctly) would be:

Subject: acpi/processor: Implement DEVICE operator for processor enumeration

  ACPI allows to declare processors either with the PROCESSOR or with the
  DEVICE operator. The current implementation handles only the PROCESSOR
  operator.

  On a system which uses the DEVICE operator for processor enumeration the
  evaluation fails.

  Check for the ACPI type of the ACPI handle and evaluate PROCESSOR and
  DEVICE types seperately.

Hmm?



Yes, you are right. I didn't explain clearly.
I will modify in my next version.


 {
acpi_status status;
+   acpi_object_type acpi_type;
+   unsigned long long uid;
union acpi_object object = { 0 };
struct acpi_buffer buffer = { sizeof(union acpi_object), &object };

-   status = acpi_evaluate_object(handle, NULL, NULL, &buffer);
-   if (ACPI_FAILURE(status))
-   acpi_handle_info(handle, "Not get the processor object\n");
-   else
-   processor_validated_ids_update(object.processor.proc_id);
+   status = acpi_get_type(handle, &acpi_type);


Shouldn't the status be checked here?


oops, Yes. Need to be checked.




+   switch (acpi_type) {
+   case ACPI_TYPE_PROCESSOR:
+   status = acpi_evaluate_object(handle, NULL, NULL, &buffer);
+   if (ACPI_FAILURE(status))
+   acpi_handle_info(handle, "Not get the processor 
object\n");
+   else
+   processor_validated_ids_update(
+   object.processor.proc_id);
+   break;
+   case ACPI_TYPE_DEVICE:
+   status = acpi_evaluate_integer(handle, "_UID", NULL, &uid);
+   if (ACPI_FAILURE(status))
+   return false;
+   processor_validated_ids_update(uid);
+   break;
+   default:
+   return false;


This is inconsistent vs. the failure handling in the PROCESSOR and DEVICE
case and the default case does not give any information either.

What about this:

switch (acpi_type) {
case ACPI_TYPE_PROCESSOR:
status = acpi_evaluate_object(handle, NULL, NULL, &buffer);
if (ACPI_FAILURE(status))
goto err;
uid = object.processor.proc_id;
break;

case ACPI_TYPE_DEVICE:
status = acpi_evaluate_integer(handle, "_UID", NULL, &uid);
if (ACPI_FAILURE(status))
goto err;
break;
default:
goto err;
}

processor_validated_ids_update(uid);
return true;

err:
acpi_handle_info(handle, "Invalid processor object\n");
return false;
}



Looks good than mine.

Thanks,
Liyang.


Thanks,

tglx

Re: [PATCH v2 1/4] Revert"x86/acpi: Set persistent cpuid <-> nodeid mapping when booting"

[Dou Liyang]

Hi tglx,

Thank you very much for your guidance! It makes me more profound
understanding of the changelog. And you also rewrote my changelog for
giving me an example.

I am so grateful that you can help me so carefully.
Once I heard the charm of the open source community, Now i can
really feel it. I love it so much.

I will try to improve myself and help others.  :)

Thanks,
Liyang.

At 03/01/2017 06:51 PM, Thomas Gleixner wrote:

On Mon, 20 Feb 2017, Dou Liyang wrote:


Currently, We make the mapping of "cpuid <-> nodeid" fixed at the booting time.
It keeps consistent with the WorkQueue and avoids some bugs which may be caused
by the dynamic assignment.

But, The ACPI table is unreliable and it is very risky that we use the entity
which isn't related to a physical device at booting time.

Now, we revert our patches. Do the last mapping of "cpuid <-> nodeid" at
hot-plug time, not at booting time where we did some useless work.
It also can make the mapping of "cpuid <-> nodeid" fixed and avoid excessive
use of the ACPI table.

The patch revert the commit dc6db24d24:
  "x86/acpi: Set persistent cpuid <-> nodeid mapping when booting".


That changelog needs some massaging. Something like this:

  The mapping of "cpuid <-> nodeid" is established at boot time via ACPI
  tables to keep associations of workqueues and other node related items
  consistent across cpu hotplug.

  But, ACPI tables are unreliable and failures with that boot time mapping
  have been reported on machines where the ACPI table and the physical
  information which is retrieved at actual hotplug is inconsistent.

  Revert the mapping implementation so it can be replaced with a less error
  prone approach.

This clearly describes:

  1) The context

  2) The problem

  3) The solution (revert)

You don't have to explain what the new solution will be in the changelog of
the revert. For the revert it's only relevant WHY we do the revert.

Please avoid writing changelogs in 'we' form. Write it pure technical, like
a manual.

Also avoid phrases like: "The patch/This patch". We all know already that
this is a patch, otherwise it wouldn't have been sent.

Documentation/process/submitting-patches.rst says:

  Describe your changes in imperative mood, e.g. "make xyzzy do frotz"
  instead of "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy
  to do frotz", as if you are giving orders to the codebase to change
  its behaviour.

Thanks,

tglx

Re: [PATCHv2] perf tools: Force uncore events to system wide monitoring

[Jiri Olsa]

On Thu, Mar 02, 2017 at 08:44:10AM +0100, Jiri Olsa wrote:
> On Wed, Mar 01, 2017 at 06:36:39PM -0300, Arnaldo Carvalho de Melo wrote:
> 
> SNIP
> 
> >   [acme@jouet linux]$ perf stat usleep 1
> > 
> >Performance counter stats for 'usleep 1':
> > 
> >   2.022049  task-clock:u (msec)   #0.181 CPUs utilized  
> > 
> >  0  context-switches:u#0.000 K/sec  
> > 
> >  0  cpu-migrations:u  #0.000 K/sec  
> > 
> > 48  page-faults:u #0.024 M/sec  
> > 
> >  2,177,301  cycles:u  #1.077 GHz
> > 
> >245,106  instructions:u#0.11  insn per cycle 
> > 
> > 48,000  branches:u#   23.738 M/sec  
> > 
> >  3,936  branch-misses:u   #8.20% of all 
> > branches
> > 
> >0.011181563 seconds time elapsed
> > 
> >   [acme@jouet linux]$
> > 
> > -
> > 
> > Seems related to the auto :u done when the user can't do kernel profiling, 
> > etc.
> > 
> > Re-applying your patch, to triple check:
> > 
> > [acme@jouet linux]$ perf stat usleep 1 2>&1 | head -2
> > Error:
> > You may not have permission to collect system-wide stats.
> > [acme@jouet linux]$
> > 
> > 
> > 
> > Waiting for v3 :-)
> 
> oh my... I'll check

could you please try with attched change

thanks,
jirka


---
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 1320352cda04..f53f449d864d 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -2374,7 +2374,8 @@ static void setup_system_wide(int forks)
return;
}
 
-   target.system_wide = true;
+   if (evsel_list->nr_entries)
+   target.system_wide = true;
}
 }