Lånetilbud

[Central Trust Loan Limited]

God dag,

Dette er Central Trust Lån Aksjeselskaper tilby lån.

Central Trust lån selskaper tilbyr fleksible og rimelige lån til ethvert 
formål, for å hjelpe deg å nå dine finansielle mål. vi lån med lav rente på 3%. 
Her er noen viktige trekk ved personlig lån fra midler sirkel utlån selskaper 
tilbys. Her er de Låne Faktorer vi samarbeider med de ledende britiske meglere 
som har tilgang til toppen långivere og være i stand til å finne den beste 
økonomiske løsningen til en rimelig price.Please, hvis du er interessert kan du 
kontakte oss via denne e-post: Centraltrust_ltd@webadicta .org


Etter reaksjonen vil du motta en søknad om kreditt fyll. Ingen sosial sikkerhet 
og ingen kredittsjekk, 100% garantert.

Det er en ære for oss hvis du tillater oss til tjeneste.


informasjon Needed

Dine navn:
Adresse:
telefon:
Lånebeløp Needed:
Varighet:
Okkupasjon:
Månedlig inntekt:
Kjønn:
Fødselsdato:
Status:
Land:
Hensikt:

Møt dine økonomiske behov er vår stolthet.

Vennlig hilsen
David Donald

Lånetilbud

[Central Trust Loan Limited]

God dag,

Dette er Central Trust Lån Aksjeselskaper tilby lån.

Central Trust lån selskaper tilbyr fleksible og rimelige lån til ethvert 
formål, for å hjelpe deg å nå dine finansielle mål. vi lån med lav rente på 3%. 
Her er noen viktige trekk ved personlig lån fra midler sirkel utlån selskaper 
tilbys. Her er de Låne Faktorer vi samarbeider med de ledende britiske meglere 
som har tilgang til toppen långivere og være i stand til å finne den beste 
økonomiske løsningen til en rimelig price.Please, hvis du er interessert kan du 
kontakte oss via denne e-post: Centraltrust_ltd@webadicta .org


Etter reaksjonen vil du motta en søknad om kreditt fyll. Ingen sosial sikkerhet 
og ingen kredittsjekk, 100% garantert.

Det er en ære for oss hvis du tillater oss til tjeneste.


informasjon Needed

Dine navn:
Adresse:
telefon:
Lånebeløp Needed:
Varighet:
Okkupasjon:
Månedlig inntekt:
Kjønn:
Fødselsdato:
Status:
Land:
Hensikt:

Møt dine økonomiske behov er vår stolthet.

Vennlig hilsen
David Donald

Re: [Nouveau] [PATCH v3] drm/nouveau/fb/nv50: set DMA mask before mapping scratch page

[Alexandre Courbot]

On Fri, Jul 8, 2016 at 1:59 AM, Ard Biesheuvel
 wrote:
> The 100c08 scratch page is mapped using dma_map_page() before the TTM
> layer has had a chance to set the DMA mask. This means we are still
> running with the default of 32 when this code executes, and this causes
> problems for platforms with no memory below 4 GB (such as AMD Seattle)
>
> So move the dma_map_page() to the .init hook, and set the streaming DMA
> mask based on the MMU subdev parameters before performing the call.
>
> Signed-off-by: Ard Biesheuvel 
> ---
> I am sure there is a much better way to address this, but this fixes the
> problem I get on AMD Seattle with a GeForce 210 PCIe card:
>
>nouveau :02:00.0: enabling device ( -> 0003)
>nouveau :02:00.0: NVIDIA GT218 (0a8280b1)
>nouveau :02:00.0: bios: version 70.18.a6.00.00
>nouveau :02:00.0: fb ctor failed, -14
>nouveau: probe of :02:00.0 failed with error -14
>
> v2: replace incorrect comparison of dma_addr_t type var against NULL
> v3: rework code to get rid of DMA_ERROR_CODE references, which is not
> defined on all architectures
>
>  drivers/gpu/drm/nouveau/nvkm/subdev/fb/nv50.c | 40 ++--
>  1 file changed, 29 insertions(+), 11 deletions(-)

I think the same problem exists in fb/gf100.c, would be nice to fix it
there as well.

I have faced similar issues on Tegra before. I wonder whether this
could not be addressed the same way I did, i.e. by setting a
temporary, fail-safe DMA mask in nvkm_device_pci_new()? That would
allow all subdevs to map pages to the device safely in their init.
With your solution, each subdev in that scenario needs to set a DMA
mask to be safe.

Not sure whether that's practical as I suppose you want to make the
DMA mask larger than 32 bits?

If you absolutely need to do this in the device, can we move the DMA
mask setting logic in nouveau_ttm into its own function and call it
from the FB driver to make sure the mask is correctly set? Maybe this
could even be made a MMU function and called during MMU ctor or init
(in the latter case we would also need to reorder MMU init to make it
happen before FB and INSTMEM).

Re: [Nouveau] [PATCH v3] drm/nouveau/fb/nv50: set DMA mask before mapping scratch page

[Alexandre Courbot]

On Fri, Jul 8, 2016 at 1:59 AM, Ard Biesheuvel
 wrote:
> The 100c08 scratch page is mapped using dma_map_page() before the TTM
> layer has had a chance to set the DMA mask. This means we are still
> running with the default of 32 when this code executes, and this causes
> problems for platforms with no memory below 4 GB (such as AMD Seattle)
>
> So move the dma_map_page() to the .init hook, and set the streaming DMA
> mask based on the MMU subdev parameters before performing the call.
>
> Signed-off-by: Ard Biesheuvel 
> ---
> I am sure there is a much better way to address this, but this fixes the
> problem I get on AMD Seattle with a GeForce 210 PCIe card:
>
>nouveau :02:00.0: enabling device ( -> 0003)
>nouveau :02:00.0: NVIDIA GT218 (0a8280b1)
>nouveau :02:00.0: bios: version 70.18.a6.00.00
>nouveau :02:00.0: fb ctor failed, -14
>nouveau: probe of :02:00.0 failed with error -14
>
> v2: replace incorrect comparison of dma_addr_t type var against NULL
> v3: rework code to get rid of DMA_ERROR_CODE references, which is not
> defined on all architectures
>
>  drivers/gpu/drm/nouveau/nvkm/subdev/fb/nv50.c | 40 ++--
>  1 file changed, 29 insertions(+), 11 deletions(-)

I think the same problem exists in fb/gf100.c, would be nice to fix it
there as well.

I have faced similar issues on Tegra before. I wonder whether this
could not be addressed the same way I did, i.e. by setting a
temporary, fail-safe DMA mask in nvkm_device_pci_new()? That would
allow all subdevs to map pages to the device safely in their init.
With your solution, each subdev in that scenario needs to set a DMA
mask to be safe.

Not sure whether that's practical as I suppose you want to make the
DMA mask larger than 32 bits?

If you absolutely need to do this in the device, can we move the DMA
mask setting logic in nouveau_ttm into its own function and call it
from the FB driver to make sure the mask is correctly set? Maybe this
could even be made a MMU function and called during MMU ctor or init
(in the latter case we would also need to reorder MMU init to make it
happen before FB and INSTMEM).

[v5.1 PATCH 5/5] drm/rockchip: cdn-dp: add cdn DP support for rk3399

[Chris Zhong]

Add support for cdn DP controller which is embedded in the rk3399
SoCs. The DP is compliant with DisplayPort Specification,
Version 1.3, This IP is compatible with the rockchip type-c PHY IP.
There is a uCPU in DP controller, it need a firmware to work,
please put the firmware file to /lib/firmware/cdn/dptx.bin. The
uCPU in charge of aux communication and link training, the host use
mailbox to communicate with the ucpu.
The dclk pin_pol of vop must not be invert for DP.

Signed-off-by: Chris Zhong 

---

Changes in v5.1:
- modify according to Sean Paul's comments

Changes in v5:
- alphabetical order
- do not use long, use u32 or u64
- return MODE_CLOCK_HIGH when requested > actual
- Optimized Coding Style
- add a formula to get better tu size and symbol value.

Changes in v4:
- use phy framework to control DP phy
- support 2 phys

Changes in v3:
- use EXTCON_DISP_DP and EXTCON_DISP_DP_ALT cable to get dp port state.
- reset spdif before config it
- modify the firmware clk to 100Mhz
- retry load firmware if fw file is requested too early

Changes in v2:
- Alphabetic order
- remove excess error message
- use define clk_rate
- check all return value
- remove dev_set_name(dp->dev, "cdn-dp");
- use schedule_delayed_work
- remove never-called functions
- remove some unnecessary ()

Changes in v1:
- use extcon API
- use hdmi-codec for the DP Asoc
- do not initialize the "ret"
- printk a err log when drm_of_encoder_active_endpoint_id
- modify the dclk pin_pol to a single line

 drivers/gpu/drm/rockchip/Kconfig|   9 +
 drivers/gpu/drm/rockchip/Makefile   |   1 +
 drivers/gpu/drm/rockchip/cdn-dp-core.c  | 840 ++
 drivers/gpu/drm/rockchip/cdn-dp-core.h  |  99 +++
 drivers/gpu/drm/rockchip/cdn-dp-reg.c   | 898 
 drivers/gpu/drm/rockchip/cdn-dp-reg.h   | 479 +++
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  11 +-
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h |   9 +
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c |   2 +
 9 files changed, 2345 insertions(+), 3 deletions(-)
 create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-core.c
 create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-core.h
 create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-reg.c
 create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-reg.h

diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index d30bdc3..a04446a 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -25,6 +25,15 @@ config ROCKCHIP_ANALOGIX_DP
  for the Analogix Core DP driver. If you want to enable DP
  on RK3288 based SoC, you should selet this option.
 
+config ROCKCHIP_CDN_DP
+tristate "Rockchip cdn DP"
+depends on DRM_ROCKCHIP
+help
+ This selects support for Rockchip SoC specific extensions
+ for the cdn DP driver. If you want to enable Dp on
+ RK3399 based SoC, you should select this
+ option.
+
 config ROCKCHIP_DW_HDMI
 tristate "Rockchip specific extensions for Synopsys DW HDMI"
 depends on DRM_ROCKCHIP
diff --git a/drivers/gpu/drm/rockchip/Makefile 
b/drivers/gpu/drm/rockchip/Makefile
index 05d0713..abdecd5 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -7,6 +7,7 @@ rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o \
 rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += rockchip_drm_fbdev.o
 
 obj-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
+obj-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o
 obj-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
 obj-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
 obj-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c 
b/drivers/gpu/drm/rockchip/cdn-dp-core.c
new file mode 100644
index 000..a425207
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -0,0 +1,840 @@
+/*
+ * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
+ * Author: Chris Zhong 
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "cdn-dp-core.h"
+#include "cdn-dp-reg.h"
+#include "rockchip_drm_vop.h"
+
+#define connector_to_dp(c) \
+   container_of(c, struct cdn_dp_device, connector)
+
+#define encoder_to_dp(c) \
+   container_of(c, struct cdn_dp_device, 

[v5.1 PATCH 5/5] drm/rockchip: cdn-dp: add cdn DP support for rk3399

[Chris Zhong]

Add support for cdn DP controller which is embedded in the rk3399
SoCs. The DP is compliant with DisplayPort Specification,
Version 1.3, This IP is compatible with the rockchip type-c PHY IP.
There is a uCPU in DP controller, it need a firmware to work,
please put the firmware file to /lib/firmware/cdn/dptx.bin. The
uCPU in charge of aux communication and link training, the host use
mailbox to communicate with the ucpu.
The dclk pin_pol of vop must not be invert for DP.

Signed-off-by: Chris Zhong 

---

Changes in v5.1:
- modify according to Sean Paul's comments

Changes in v5:
- alphabetical order
- do not use long, use u32 or u64
- return MODE_CLOCK_HIGH when requested > actual
- Optimized Coding Style
- add a formula to get better tu size and symbol value.

Changes in v4:
- use phy framework to control DP phy
- support 2 phys

Changes in v3:
- use EXTCON_DISP_DP and EXTCON_DISP_DP_ALT cable to get dp port state.
- reset spdif before config it
- modify the firmware clk to 100Mhz
- retry load firmware if fw file is requested too early

Changes in v2:
- Alphabetic order
- remove excess error message
- use define clk_rate
- check all return value
- remove dev_set_name(dp->dev, "cdn-dp");
- use schedule_delayed_work
- remove never-called functions
- remove some unnecessary ()

Changes in v1:
- use extcon API
- use hdmi-codec for the DP Asoc
- do not initialize the "ret"
- printk a err log when drm_of_encoder_active_endpoint_id
- modify the dclk pin_pol to a single line

 drivers/gpu/drm/rockchip/Kconfig|   9 +
 drivers/gpu/drm/rockchip/Makefile   |   1 +
 drivers/gpu/drm/rockchip/cdn-dp-core.c  | 840 ++
 drivers/gpu/drm/rockchip/cdn-dp-core.h  |  99 +++
 drivers/gpu/drm/rockchip/cdn-dp-reg.c   | 898 
 drivers/gpu/drm/rockchip/cdn-dp-reg.h   | 479 +++
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  11 +-
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h |   9 +
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c |   2 +
 9 files changed, 2345 insertions(+), 3 deletions(-)
 create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-core.c
 create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-core.h
 create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-reg.c
 create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-reg.h

diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index d30bdc3..a04446a 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -25,6 +25,15 @@ config ROCKCHIP_ANALOGIX_DP
  for the Analogix Core DP driver. If you want to enable DP
  on RK3288 based SoC, you should selet this option.
 
+config ROCKCHIP_CDN_DP
+tristate "Rockchip cdn DP"
+depends on DRM_ROCKCHIP
+help
+ This selects support for Rockchip SoC specific extensions
+ for the cdn DP driver. If you want to enable Dp on
+ RK3399 based SoC, you should select this
+ option.
+
 config ROCKCHIP_DW_HDMI
 tristate "Rockchip specific extensions for Synopsys DW HDMI"
 depends on DRM_ROCKCHIP
diff --git a/drivers/gpu/drm/rockchip/Makefile 
b/drivers/gpu/drm/rockchip/Makefile
index 05d0713..abdecd5 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -7,6 +7,7 @@ rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o \
 rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += rockchip_drm_fbdev.o
 
 obj-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
+obj-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o
 obj-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
 obj-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
 obj-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c 
b/drivers/gpu/drm/rockchip/cdn-dp-core.c
new file mode 100644
index 000..a425207
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -0,0 +1,840 @@
+/*
+ * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
+ * Author: Chris Zhong 
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "cdn-dp-core.h"
+#include "cdn-dp-reg.h"
+#include "rockchip_drm_vop.h"
+
+#define connector_to_dp(c) \
+   container_of(c, struct cdn_dp_device, connector)
+
+#define encoder_to_dp(c) \
+   container_of(c, struct cdn_dp_device, encoder)
+
+/* dp grf register offset */
+#define 

[PATCH] drm: mediatek: add Maintainers entry for Mediatek DRM drivers

[CK Hu]

Add CK Hu and Philipp Zabel as maintainers for Mediatek DRM drivers.

Signed-off-by: CK Hu 
---
 MAINTAINERS |8 
 1 file changed, 8 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 7304d2e..2a04cdc 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3973,6 +3973,14 @@ S:   Orphan / Obsolete
 F: drivers/gpu/drm/i810/
 F: include/uapi/drm/i810_drm.h
 
+DRM DRIVERS FOR MEDIATEK
+M: CK Hu 
+M: Philipp Zabel 
+L: dri-de...@lists.freedesktop.org
+S: Supported
+F: drivers/gpu/drm/mediatek/
+F: Documentation/devicetree/bindings/display/mediatek/
+
 DRM DRIVER FOR MSM ADRENO GPU
 M: Rob Clark 
 L: linux-arm-...@vger.kernel.org
-- 
1.7.9.5

[PATCH] drm: mediatek: add Maintainers entry for Mediatek DRM drivers

[CK Hu]

Add CK Hu and Philipp Zabel as maintainers for Mediatek DRM drivers.

Signed-off-by: CK Hu 
---
 MAINTAINERS |8 
 1 file changed, 8 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 7304d2e..2a04cdc 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3973,6 +3973,14 @@ S:   Orphan / Obsolete
 F: drivers/gpu/drm/i810/
 F: include/uapi/drm/i810_drm.h
 
+DRM DRIVERS FOR MEDIATEK
+M: CK Hu 
+M: Philipp Zabel 
+L: dri-de...@lists.freedesktop.org
+S: Supported
+F: drivers/gpu/drm/mediatek/
+F: Documentation/devicetree/bindings/display/mediatek/
+
 DRM DRIVER FOR MSM ADRENO GPU
 M: Rob Clark 
 L: linux-arm-...@vger.kernel.org
-- 
1.7.9.5

Darlehen bieten jetzt bewerben

[UK CREDIT LTD LOAN]

Schönen Tag,
 
   
Wir UK CREDIT LTD KREDITFinanzGesellschaft mit Sitz in Großbritannien durch die 
Operationen und eine gute Kundenbasis auf der ganzen Welt. Wir bieten Darlehen 
zu niedrigen Zinssatz von 3%. Liebe Leser werden darauf hingewiesen, dass 
dieses Angebot ernst gesinnten Individuum, Unternehmen und Konzerne. Holen Sie 
sich ein Darlehen Ihre finanziellen Probleme zu lösen wie Rechnungen zahlen 
sich aus, ein neues Geschäft, die Wiederherstellung Antiquitätengeschäft. 
Interessierte Einzelpersonen, Firmen und Unternehmen kontaktieren Sie uns bitte 
über diese E-Mail: ukcreditloa...@gmail.com




Verpassen Sie nicht diese Gelegenheit, lassen Sie vorbei. Holen Sie sich ein 
Darlehen Ihre finanziellen Probleme zu lösen. Wenn Sie in ein Darlehen 
interessiert
Ausfüllen und sofort das Darlehen Antragsformular zurückschicken.



Die Namen sind: ...
Adresse: ...
Telefon: ...
Darlehensbetrag erforderlich: ...
Dauer: ...
Beruf: ...
Monatliches Einkommen Level: ...
Nicht ...
Geburtsdatum: 
Status: ..
Land: .
Postleitzahl: .
Zweck: ..
KONTAKTIERE UNS.


Danke für dein Verständnis



Treffen Sie Ihre finanziellen Bedürfnisse ist unsere Ziele



GEORGE WILLIAMS.

Darlehen bieten jetzt bewerben

[UK CREDIT LTD LOAN]

Schönen Tag,
 
   
Wir UK CREDIT LTD KREDITFinanzGesellschaft mit Sitz in Großbritannien durch die 
Operationen und eine gute Kundenbasis auf der ganzen Welt. Wir bieten Darlehen 
zu niedrigen Zinssatz von 3%. Liebe Leser werden darauf hingewiesen, dass 
dieses Angebot ernst gesinnten Individuum, Unternehmen und Konzerne. Holen Sie 
sich ein Darlehen Ihre finanziellen Probleme zu lösen wie Rechnungen zahlen 
sich aus, ein neues Geschäft, die Wiederherstellung Antiquitätengeschäft. 
Interessierte Einzelpersonen, Firmen und Unternehmen kontaktieren Sie uns bitte 
über diese E-Mail: ukcreditloa...@gmail.com




Verpassen Sie nicht diese Gelegenheit, lassen Sie vorbei. Holen Sie sich ein 
Darlehen Ihre finanziellen Probleme zu lösen. Wenn Sie in ein Darlehen 
interessiert
Ausfüllen und sofort das Darlehen Antragsformular zurückschicken.



Die Namen sind: ...
Adresse: ...
Telefon: ...
Darlehensbetrag erforderlich: ...
Dauer: ...
Beruf: ...
Monatliches Einkommen Level: ...
Nicht ...
Geburtsdatum: 
Status: ..
Land: .
Postleitzahl: .
Zweck: ..
KONTAKTIERE UNS.


Danke für dein Verständnis



Treffen Sie Ihre finanziellen Bedürfnisse ist unsere Ziele



GEORGE WILLIAMS.

Re: [PATCH v4 4/4] drm/rockchip: analogix_dp: implement PSR function

[Yakir Yang]

Sean,

On 07/14/2016 11:26 PM, Sean Paul wrote:

On Thu, Jul 14, 2016 at 12:15:58PM +0800, Yakir Yang wrote:

Alway enable the PSR function for Rockchip analogix_dp driver. If panel
don't support PSR, then the core analogix_dp would ignore this setting.

Signed-off-by: Yakir Yang 

Reviewed-by: Sean Paul 


Thanks :-D

- Yakir


---
Changes in v4:
- Return 'void' instead of 'int' in analogix_dp_psr_set(). (Sean)
- Pull the 10ms delay time out into a #define. (Sean)
- Improved the code of analogix_dp_psr_work(). (Sean)
- Indented with spaces for new numbers in rockchip_dp_device struct. (Stéphane, 
reviewed at Google gerrit)
 
[https://chromium-review.googlesource.com/#/c/349085/33/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c@83]

Changes in v3:
- split the common psr logic into a seperate driver, make this to a
   simple sub-psr device driver.

Changes in v2:
- remove vblank notify out (Daniel)
- create a psr_active() callback in vop data struct.

  drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 57 +
  1 file changed, 57 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index e81e19a..aa916f4 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -32,6 +32,7 @@
  #include 
  
  #include "rockchip_drm_drv.h"

+#include "rockchip_drm_psr.h"
  #include "rockchip_drm_vop.h"
  
  #define RK3288_GRF_SOC_CON6		0x25c

@@ -41,6 +42,9 @@
  
  #define HIWORD_UPDATE(val, mask)	(val | (mask) << 16)
  
+#define PSR_SET_DELAY_TIME		msecs_to_jiffies(10)

+#define PSR_WAIT_LINE_FLAG_TIMEOUT_MS  100
+
  #define to_dp(nm) container_of(nm, struct rockchip_dp_device, nm)
  
  /**

@@ -68,11 +72,55 @@ struct rockchip_dp_device {
struct regmap*grf;
struct reset_control *rst;
  
+	struct delayed_work  psr_work;

+   unsigned int psr_state;
+
const struct rockchip_dp_chip_data *data;
  
  	struct analogix_dp_plat_data plat_data;

  };
  
+static void analogix_dp_psr_set(struct drm_encoder *encoder, bool enabled)

+{
+   struct rockchip_dp_device *dp = to_dp(encoder);
+
+   dev_dbg(dp->dev, "%s PSR...\n", enabled ? "Entry" : "Exit");
+
+   if (enabled)
+   dp->psr_state = EDP_VSC_PSR_STATE_ACTIVE;
+   else
+   dp->psr_state = ~EDP_VSC_PSR_STATE_ACTIVE;
+
+   schedule_delayed_work(>psr_work, PSR_SET_DELAY_TIME);
+}
+
+static void analogix_dp_psr_work(struct work_struct *work)
+{
+   struct rockchip_dp_device *dp =
+   container_of(work, typeof(*dp), psr_work.work);
+   struct drm_crtc *crtc = dp->encoder.crtc;
+   int psr_state = dp->psr_state;
+   int vact_end;
+   int ret;
+
+   if (!crtc)
+   return;
+
+   vact_end = crtc->mode.vtotal - crtc->mode.vsync_start + 
crtc->mode.vdisplay;
+
+   ret = rockchip_drm_wait_line_flag(dp->encoder.crtc, vact_end,
+ PSR_WAIT_LINE_FLAG_TIMEOUT_MS);
+   if (ret) {
+   dev_err(dp->dev, "line flag interrupt did not arrive\n");
+   return;
+   }
+
+   if (psr_state == EDP_VSC_PSR_STATE_ACTIVE)
+   analogix_dp_enable_psr(dp->dev);
+   else
+   analogix_dp_disable_psr(dp->dev);
+}
+
  static int rockchip_dp_pre_init(struct rockchip_dp_device *dp)
  {
reset_control_assert(dp->rst);
@@ -340,12 +388,21 @@ static int rockchip_dp_bind(struct device *dev, struct 
device *master,
dp->plat_data.power_off = rockchip_dp_powerdown;
dp->plat_data.get_modes = rockchip_dp_get_modes;
  
+	dp->psr_state = ~EDP_VSC_PSR_STATE_ACTIVE;

+   INIT_DELAYED_WORK(>psr_work, analogix_dp_psr_work);
+
+   rockchip_drm_psr_register(>encoder, analogix_dp_psr_set);
+
return analogix_dp_bind(dev, dp->drm_dev, >plat_data);
  }
  
  static void rockchip_dp_unbind(struct device *dev, struct device *master,

   void *data)
  {
+   struct rockchip_dp_device *dp = dev_get_drvdata(dev);
+
+   rockchip_drm_psr_unregister(>encoder);
+
return analogix_dp_unbind(dev, master, data);
  }
  
--

1.9.1


___
dri-devel mailing list
dri-de...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 4/4] drm/rockchip: analogix_dp: implement PSR function

[Yakir Yang]

Sean,

On 07/14/2016 11:26 PM, Sean Paul wrote:

On Thu, Jul 14, 2016 at 12:15:58PM +0800, Yakir Yang wrote:

Alway enable the PSR function for Rockchip analogix_dp driver. If panel
don't support PSR, then the core analogix_dp would ignore this setting.

Signed-off-by: Yakir Yang 

Reviewed-by: Sean Paul 


Thanks :-D

- Yakir


---
Changes in v4:
- Return 'void' instead of 'int' in analogix_dp_psr_set(). (Sean)
- Pull the 10ms delay time out into a #define. (Sean)
- Improved the code of analogix_dp_psr_work(). (Sean)
- Indented with spaces for new numbers in rockchip_dp_device struct. (Stéphane, 
reviewed at Google gerrit)
 
[https://chromium-review.googlesource.com/#/c/349085/33/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c@83]

Changes in v3:
- split the common psr logic into a seperate driver, make this to a
   simple sub-psr device driver.

Changes in v2:
- remove vblank notify out (Daniel)
- create a psr_active() callback in vop data struct.

  drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 57 +
  1 file changed, 57 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index e81e19a..aa916f4 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -32,6 +32,7 @@
  #include 
  
  #include "rockchip_drm_drv.h"

+#include "rockchip_drm_psr.h"
  #include "rockchip_drm_vop.h"
  
  #define RK3288_GRF_SOC_CON6		0x25c

@@ -41,6 +42,9 @@
  
  #define HIWORD_UPDATE(val, mask)	(val | (mask) << 16)
  
+#define PSR_SET_DELAY_TIME		msecs_to_jiffies(10)

+#define PSR_WAIT_LINE_FLAG_TIMEOUT_MS  100
+
  #define to_dp(nm) container_of(nm, struct rockchip_dp_device, nm)
  
  /**

@@ -68,11 +72,55 @@ struct rockchip_dp_device {
struct regmap*grf;
struct reset_control *rst;
  
+	struct delayed_work  psr_work;

+   unsigned int psr_state;
+
const struct rockchip_dp_chip_data *data;
  
  	struct analogix_dp_plat_data plat_data;

  };
  
+static void analogix_dp_psr_set(struct drm_encoder *encoder, bool enabled)

+{
+   struct rockchip_dp_device *dp = to_dp(encoder);
+
+   dev_dbg(dp->dev, "%s PSR...\n", enabled ? "Entry" : "Exit");
+
+   if (enabled)
+   dp->psr_state = EDP_VSC_PSR_STATE_ACTIVE;
+   else
+   dp->psr_state = ~EDP_VSC_PSR_STATE_ACTIVE;
+
+   schedule_delayed_work(>psr_work, PSR_SET_DELAY_TIME);
+}
+
+static void analogix_dp_psr_work(struct work_struct *work)
+{
+   struct rockchip_dp_device *dp =
+   container_of(work, typeof(*dp), psr_work.work);
+   struct drm_crtc *crtc = dp->encoder.crtc;
+   int psr_state = dp->psr_state;
+   int vact_end;
+   int ret;
+
+   if (!crtc)
+   return;
+
+   vact_end = crtc->mode.vtotal - crtc->mode.vsync_start + 
crtc->mode.vdisplay;
+
+   ret = rockchip_drm_wait_line_flag(dp->encoder.crtc, vact_end,
+ PSR_WAIT_LINE_FLAG_TIMEOUT_MS);
+   if (ret) {
+   dev_err(dp->dev, "line flag interrupt did not arrive\n");
+   return;
+   }
+
+   if (psr_state == EDP_VSC_PSR_STATE_ACTIVE)
+   analogix_dp_enable_psr(dp->dev);
+   else
+   analogix_dp_disable_psr(dp->dev);
+}
+
  static int rockchip_dp_pre_init(struct rockchip_dp_device *dp)
  {
reset_control_assert(dp->rst);
@@ -340,12 +388,21 @@ static int rockchip_dp_bind(struct device *dev, struct 
device *master,
dp->plat_data.power_off = rockchip_dp_powerdown;
dp->plat_data.get_modes = rockchip_dp_get_modes;
  
+	dp->psr_state = ~EDP_VSC_PSR_STATE_ACTIVE;

+   INIT_DELAYED_WORK(>psr_work, analogix_dp_psr_work);
+
+   rockchip_drm_psr_register(>encoder, analogix_dp_psr_set);
+
return analogix_dp_bind(dev, dp->drm_dev, >plat_data);
  }
  
  static void rockchip_dp_unbind(struct device *dev, struct device *master,

   void *data)
  {
+   struct rockchip_dp_device *dp = dev_get_drvdata(dev);
+
+   rockchip_drm_psr_unregister(>encoder);
+
return analogix_dp_unbind(dev, master, data);
  }
  
--

1.9.1


___
dri-devel mailing list
dri-de...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/1] tracing, bpf: Implement function bpf_probe_write

[Alexei Starovoitov]

On Wed, Jul 13, 2016 at 01:31:57PM -0700, Sargun Dhillon wrote:
> 
> 
> On Wed, 13 Jul 2016, Alexei Starovoitov wrote:
> 
> > On Wed, Jul 13, 2016 at 03:36:11AM -0700, Sargun Dhillon wrote:
> >> Provides BPF programs, attached to kprobes a safe way to write to
> >> memory referenced by probes. This is done by making probe_kernel_write
> >> accessible to bpf functions via the bpf_probe_write helper.
> >
> > not quite :)
> >
> >> Signed-off-by: Sargun Dhillon 
> >> ---
> >>  include/uapi/linux/bpf.h  |  3 +++
> >>  kernel/trace/bpf_trace.c  | 20 
> >>  samples/bpf/bpf_helpers.h |  2 ++
> >>  3 files changed, 25 insertions(+)
> >>
> >> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> >> index 406459b..355b565 100644
> >> --- a/include/uapi/linux/bpf.h
> >> +++ b/include/uapi/linux/bpf.h
> >> @@ -313,6 +313,9 @@ enum bpf_func_id {
> >>   */
> >>   BPF_FUNC_skb_get_tunnel_opt,
> >>   BPF_FUNC_skb_set_tunnel_opt,
> >> +
> >> + BPF_FUNC_probe_write, /* int bpf_probe_write(void *dst, void *src,
> >> int size) */
> >> +
> >
> > the patch is against some old kernel.
> > Please always make the patch against net-next tree and cc netdev list.
> >
> Sorry, I did this against Linus's tree, not net-next. Will fix.
> 
> >> +static u64 bpf_probe_write(u64 r1, u64 r2, u64 r3, u64 r4, u64 r5)
> >> +{
> >> + void *dst = (void *) (long) r1;
> >> + void *unsafe_ptr = (void *) (long) r2;
> >> + int  size = (int) r3;
> >> +
> >> + return probe_kernel_write(dst, unsafe_ptr, size);
> >> +}
> >
> > the patch is whitepsace mangled. Please see 
> > Documentation/networking/netdev-FAQ.txt
> Also will fix.
> 
> >
> > the main issue though that we cannot simply allow bpf to do probe_write,
> > since it may crash the kernel.
> > What might be ok is to allow writing into memory of current
> > user space process only. This way bpf prog will keep kernel safety 
> > guarantees,
> > yet it will be able to modify user process memory when necessary.
> > Since bpf+tracing is root only, it doesn't pose security risk.
> >
> >
> 
> Doesn't probe_write prevent you from writing to protected memory and 
> generate an EFAULT? Or are you worried about the situation where a bpf 
> program writes to some other chunk of kernel memory, or writes bad data 
> to said kernel memory?
> 
> I guess when I meant "safe" -- it's safer than allowing arbitrary memcpy. 
> I don't see a good way to ensure safety otherwise as we don't know 
> which registers point to memory that it's reasonable for probes to 
> manipulate. It's not like skb_store_bytes where we can check the pointer 
> going in is the same pointer that's referenced, and with a super 
> restricted datatype.

exactly. probe_write can write anywhere in the kernel and that
will cause crashes. If we allow that bpf becomes no different than
kernel module.

> Perhaps, it would be a good idea to describe an example where I used this:
> #include 
> #include 
> #include 
> 
> 
> int trace_inet_stream_connect(struct pt_regs *ctx)
> {
>   if (!PT_REGS_PARM2(ctx)) {
>   return 0;
>   }
>   struct sockaddr uaddr = {};
>   struct sockaddr_in *addr_in;
>   bpf_probe_read(, sizeof(struct sockaddr), (void 
> *)PT_REGS_PARM2(ctx));
>   if (uaddr.sa_family == AF_INET) {
>   // Simple cast causes LLVM weirdness
>   addr_in = 
>   char fmt[] = "Connecting on port: %d\n";
>   bpf_trace_printk(fmt, sizeof(fmt), ntohs(addr_in->sin_port));
>   if (ntohs(addr_in->sin_port) == 80) {
>   addr_in->sin_port = htons(443);
>   bpf_probe_write((void *)PT_REGS_PARM2(ctx), , 
> sizeof(uaddr));
>   }
>   }
> return 0;
> };
> 
> There are two reasons I want to do this:
> 1) Debugging - sometimes, it makes sense to divert a program's syscalls in 
> order to allow for better debugging
> 2) Network Functions - I wrote a load balancer which intercepts 
> inet_stream_connect & tcp_set_state. We can manipulate the destination 
> address as neccessary at connect time. This also has the nice side effect 
> that getpeername() returns the real IP that a server is connected to, and 
> the performance is far better than doing "network load balancing"
> 
> (I realize this is a total hack, better approaches would be appreciated)

nice. interesting idea.
Have you considered ld_preload hack to do port rewrite?

> If we allowed manipulation of the current task's user memory by exposing 
> copy_to_user, that could also work if I attach the probe to sys_connect, 
> I could overwrite the address there before it gets copied into 
> kernel space, but that could lead to its own weirdness.

we cannot simply call copy_to_user from the bpf either,
but yeah, something semantically equivalent to copy_to_user should
solve your port rewriting case, right?
Could you explain little bit more on 'syscall divert' ideas?

Re: [PATCH 1/1] tracing, bpf: Implement function bpf_probe_write

[Alexei Starovoitov]

On Wed, Jul 13, 2016 at 01:31:57PM -0700, Sargun Dhillon wrote:
> 
> 
> On Wed, 13 Jul 2016, Alexei Starovoitov wrote:
> 
> > On Wed, Jul 13, 2016 at 03:36:11AM -0700, Sargun Dhillon wrote:
> >> Provides BPF programs, attached to kprobes a safe way to write to
> >> memory referenced by probes. This is done by making probe_kernel_write
> >> accessible to bpf functions via the bpf_probe_write helper.
> >
> > not quite :)
> >
> >> Signed-off-by: Sargun Dhillon 
> >> ---
> >>  include/uapi/linux/bpf.h  |  3 +++
> >>  kernel/trace/bpf_trace.c  | 20 
> >>  samples/bpf/bpf_helpers.h |  2 ++
> >>  3 files changed, 25 insertions(+)
> >>
> >> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> >> index 406459b..355b565 100644
> >> --- a/include/uapi/linux/bpf.h
> >> +++ b/include/uapi/linux/bpf.h
> >> @@ -313,6 +313,9 @@ enum bpf_func_id {
> >>   */
> >>   BPF_FUNC_skb_get_tunnel_opt,
> >>   BPF_FUNC_skb_set_tunnel_opt,
> >> +
> >> + BPF_FUNC_probe_write, /* int bpf_probe_write(void *dst, void *src,
> >> int size) */
> >> +
> >
> > the patch is against some old kernel.
> > Please always make the patch against net-next tree and cc netdev list.
> >
> Sorry, I did this against Linus's tree, not net-next. Will fix.
> 
> >> +static u64 bpf_probe_write(u64 r1, u64 r2, u64 r3, u64 r4, u64 r5)
> >> +{
> >> + void *dst = (void *) (long) r1;
> >> + void *unsafe_ptr = (void *) (long) r2;
> >> + int  size = (int) r3;
> >> +
> >> + return probe_kernel_write(dst, unsafe_ptr, size);
> >> +}
> >
> > the patch is whitepsace mangled. Please see 
> > Documentation/networking/netdev-FAQ.txt
> Also will fix.
> 
> >
> > the main issue though that we cannot simply allow bpf to do probe_write,
> > since it may crash the kernel.
> > What might be ok is to allow writing into memory of current
> > user space process only. This way bpf prog will keep kernel safety 
> > guarantees,
> > yet it will be able to modify user process memory when necessary.
> > Since bpf+tracing is root only, it doesn't pose security risk.
> >
> >
> 
> Doesn't probe_write prevent you from writing to protected memory and 
> generate an EFAULT? Or are you worried about the situation where a bpf 
> program writes to some other chunk of kernel memory, or writes bad data 
> to said kernel memory?
> 
> I guess when I meant "safe" -- it's safer than allowing arbitrary memcpy. 
> I don't see a good way to ensure safety otherwise as we don't know 
> which registers point to memory that it's reasonable for probes to 
> manipulate. It's not like skb_store_bytes where we can check the pointer 
> going in is the same pointer that's referenced, and with a super 
> restricted datatype.

exactly. probe_write can write anywhere in the kernel and that
will cause crashes. If we allow that bpf becomes no different than
kernel module.

> Perhaps, it would be a good idea to describe an example where I used this:
> #include 
> #include 
> #include 
> 
> 
> int trace_inet_stream_connect(struct pt_regs *ctx)
> {
>   if (!PT_REGS_PARM2(ctx)) {
>   return 0;
>   }
>   struct sockaddr uaddr = {};
>   struct sockaddr_in *addr_in;
>   bpf_probe_read(, sizeof(struct sockaddr), (void 
> *)PT_REGS_PARM2(ctx));
>   if (uaddr.sa_family == AF_INET) {
>   // Simple cast causes LLVM weirdness
>   addr_in = 
>   char fmt[] = "Connecting on port: %d\n";
>   bpf_trace_printk(fmt, sizeof(fmt), ntohs(addr_in->sin_port));
>   if (ntohs(addr_in->sin_port) == 80) {
>   addr_in->sin_port = htons(443);
>   bpf_probe_write((void *)PT_REGS_PARM2(ctx), , 
> sizeof(uaddr));
>   }
>   }
> return 0;
> };
> 
> There are two reasons I want to do this:
> 1) Debugging - sometimes, it makes sense to divert a program's syscalls in 
> order to allow for better debugging
> 2) Network Functions - I wrote a load balancer which intercepts 
> inet_stream_connect & tcp_set_state. We can manipulate the destination 
> address as neccessary at connect time. This also has the nice side effect 
> that getpeername() returns the real IP that a server is connected to, and 
> the performance is far better than doing "network load balancing"
> 
> (I realize this is a total hack, better approaches would be appreciated)

nice. interesting idea.
Have you considered ld_preload hack to do port rewrite?

> If we allowed manipulation of the current task's user memory by exposing 
> copy_to_user, that could also work if I attach the probe to sys_connect, 
> I could overwrite the address there before it gets copied into 
> kernel space, but that could lead to its own weirdness.

we cannot simply call copy_to_user from the bpf either,
but yeah, something semantically equivalent to copy_to_user should
solve your port rewriting case, right?
Could you explain little bit more on 'syscall divert' ideas?

Re: [git pull] stm class/intel_th: Updates for char-misc-linus

[Greg KH]

On Thu, Jul 14, 2016 at 01:20:25PM +0300, Alexander Shishkin wrote:
> Greg KH <gre...@linuxfoundation.org> writes:
> 
> > On Fri, Jul 01, 2016 at 12:15:37PM +0300, Alexander Shishkin wrote:
> >> Hi Greg,
> >> 
> >> These are fixes I have queued for the v4.7. Please consider pulling into
> >> char-misc-linus.
> >> 
> >> The following changes since commit 
> >> 60cef77f9ba419fec6c41bc4e3fecb9bf426f664:
> >> 
> >>   intel_th: pci: Add Kaby Lake PCH-H support (2016-06-30 15:39:15 +0300)
> >> 
> >> are available in the git repository at:
> >> 
> >>   git://git.kernel.org/pub/scm/linux/kernel/git/ash/stm.git 
> >> tags/stm-fixes-for-greg-20160630
> >
> > It's too late for 4.7, can you resend these with stable@ tags so it gets
> > into a 4.7-stable release?
> 
> Done.
> 
> The following changes since commit af8c34ce6ae32addda3788d54a7e340cad22516b:
> 
>   Linux 4.7-rc2 (2016-06-05 14:31:26 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/ash/stm.git 
> tags/stm-for-greg-20160714

Pulled and pushed out.

thanks,

greg k-h

Re: [git pull] stm class/intel_th: Updates for char-misc-linus

[Greg KH]

On Thu, Jul 14, 2016 at 01:20:25PM +0300, Alexander Shishkin wrote:
> Greg KH  writes:
> 
> > On Fri, Jul 01, 2016 at 12:15:37PM +0300, Alexander Shishkin wrote:
> >> Hi Greg,
> >> 
> >> These are fixes I have queued for the v4.7. Please consider pulling into
> >> char-misc-linus.
> >> 
> >> The following changes since commit 
> >> 60cef77f9ba419fec6c41bc4e3fecb9bf426f664:
> >> 
> >>   intel_th: pci: Add Kaby Lake PCH-H support (2016-06-30 15:39:15 +0300)
> >> 
> >> are available in the git repository at:
> >> 
> >>   git://git.kernel.org/pub/scm/linux/kernel/git/ash/stm.git 
> >> tags/stm-fixes-for-greg-20160630
> >
> > It's too late for 4.7, can you resend these with stable@ tags so it gets
> > into a 4.7-stable release?
> 
> Done.
> 
> The following changes since commit af8c34ce6ae32addda3788d54a7e340cad22516b:
> 
>   Linux 4.7-rc2 (2016-06-05 14:31:26 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/ash/stm.git 
> tags/stm-for-greg-20160714

Pulled and pushed out.

thanks,

greg k-h

Re: [PATCH 2/2] workqueue:Fix affinity of an unbound worker of a node with 1 online CPU

[Gautham R Shenoy]

Hi Tejun,

On Thu, Jun 16, 2016 at 03:39:05PM -0400, Tejun Heo wrote:
> On Thu, Jun 16, 2016 at 02:45:48PM +0200, Peter Zijlstra wrote:
> > Subject: workqueue: Fix setting affinity of unbound worker threads
> > From: Peter Zijlstra 
> > Date: Thu Jun 16 14:38:42 CEST 2016
> > 
> > With commit e9d867a67fd03ccc ("sched: Allow per-cpu kernel threads to
> > run on online && !active"), __set_cpus_allowed_ptr() expects that only
> > strict per-cpu kernel threads can have affinity to an online CPU which
> > is not yet active.
> > 
> > This assumption is currently broken in the CPU_ONLINE notification
> > handler for the workqueues where restore_unbound_workers_cpumask()
> > calls set_cpus_allowed_ptr() when the first cpu in the unbound
> > worker's pool->attr->cpumask comes online. Since
> > set_cpus_allowed_ptr() is called with pool->attr->cpumask in which
> > only one CPU is online which is not yet active, we get the following
> > WARN_ON during an CPU online operation.
> 
> Applied to wq/for-4.7-fixes.

Did this patch get missed by any chance? It is not in
the master branch of
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git yet.

We're still hitting the WARN_ON() during boot-up on the mainline kernel.
> Thanks.
> 
> -- 
> tejun
> 

--
Thanks and Regards
gautham.

Re: [PATCH 2/2] workqueue:Fix affinity of an unbound worker of a node with 1 online CPU

[Gautham R Shenoy]

Hi Tejun,

On Thu, Jun 16, 2016 at 03:39:05PM -0400, Tejun Heo wrote:
> On Thu, Jun 16, 2016 at 02:45:48PM +0200, Peter Zijlstra wrote:
> > Subject: workqueue: Fix setting affinity of unbound worker threads
> > From: Peter Zijlstra 
> > Date: Thu Jun 16 14:38:42 CEST 2016
> > 
> > With commit e9d867a67fd03ccc ("sched: Allow per-cpu kernel threads to
> > run on online && !active"), __set_cpus_allowed_ptr() expects that only
> > strict per-cpu kernel threads can have affinity to an online CPU which
> > is not yet active.
> > 
> > This assumption is currently broken in the CPU_ONLINE notification
> > handler for the workqueues where restore_unbound_workers_cpumask()
> > calls set_cpus_allowed_ptr() when the first cpu in the unbound
> > worker's pool->attr->cpumask comes online. Since
> > set_cpus_allowed_ptr() is called with pool->attr->cpumask in which
> > only one CPU is online which is not yet active, we get the following
> > WARN_ON during an CPU online operation.
> 
> Applied to wq/for-4.7-fixes.

Did this patch get missed by any chance? It is not in
the master branch of
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git yet.

We're still hitting the WARN_ON() during boot-up on the mainline kernel.
> Thanks.
> 
> -- 
> tejun
> 

--
Thanks and Regards
gautham.

Re: [PATCH v4] acpi, nfit: treat virtual ramdisk SPA as pmem region

[Dan Williams]

On Thu, Jul 14, 2016 at 9:05 PM, Lee, Chun-Yi  wrote:
> This patch adds logic to treat virtual ramdisk SPA as pmem region, then
> ramdisk's /dev/pmem* device can be mounted with iso9660.
>
> It's useful to work with the httpboot in EFI firmware to pull a remote
> ISO file to the local memory region for booting and installation.
>
> Wiki page of UEFI HTTPBoot with OVMF:
> https://en.opensuse.org/UEFI_HTTPBoot_with_OVMF
>
> The ramdisk function in EDK2/OVMF generates a ACPI0012 root device that
> it contains empty _STA but without _DSM:
>
> DefinitionBlock ("ssdt2.aml", "SSDT", 2, "INTEL ", "RamDisk ", 0x1000)
> {
> Scope (\_SB)
> {
> Device (NVDR)
> {
> Name (_HID, "ACPI0012")  // _HID: Hardware ID
> Name (_STR, Unicode ("NVDIMM Root Device"))  // _STR: Description 
> String
> Method (_STA, 0, NotSerialized)  // _STA: Status
> {
> Return (0x0F)
> }
> }
> }
> }
>
> In section 5.2.25.2 of ACPI 6.1 spec, it mentions that the "SPA Range
> Structure Index" of virtual SPA shall be set to zero. That means virtual SPA
> will not be associated by any NVDIMM region mapping.
>
> The VCD's SPA Range Structure in NFIT is similar to virtual disk region
> as following:
>
> [028h 0040   2]Subtable Type :  [System Physical Address 
> Range]
> [02Ah 0042   2]   Length : 0038
>
> [02Ch 0044   2]  Range Index : 
> [02Eh 0046   2]Flags (decoded below) : 
>Add/Online Operation Only : 0
>   Proximity Domain Valid : 0
> [030h 0048   4] Reserved : 
> [034h 0052   4] Proximity Domain : 
> [038h 0056  16]   Address Range GUID : 
> 77AB535A-45FC-624B-5560-F7B281D1F96E
> [048h 0072   8]   Address Range Base : B6ABD018
> [050h 0080   8] Address Range Length : 0550
> [058h 0088   8] Memory Map Attribute : 
>
> The way to not associate a SPA range is to never reference it from a "flush 
> hint",
> "interleave", or "control region" table.
>
> After testing on OVMF, pmem driver can support the region that it doesn't
> assoicate to any NVDIMM mapping. So, treat VCD like pmem is a idea to get
> a pmem block device that it contains iso.
>
> v4:
> Instoduce nfit_spa_is_virtual() to check virtual ramdisk SPA and create
> pmem region.
>
> v3:
> To simplify patch, removed useless VCD region in libnvdimm.
>
> v2:
> Removed the code for setting VCD to a read-only region.
>
> Cc: Gary Lin 
> Cc: Dan Williams 
> Cc: Ross Zwisler 
> Cc: "Rafael J. Wysocki" 
> Cc: Linda Knippers 
> Signed-off-by: Lee, Chun-Yi 

Applied, thanks.

Re: [PATCH v4] acpi, nfit: treat virtual ramdisk SPA as pmem region

[Dan Williams]

On Thu, Jul 14, 2016 at 9:05 PM, Lee, Chun-Yi  wrote:
> This patch adds logic to treat virtual ramdisk SPA as pmem region, then
> ramdisk's /dev/pmem* device can be mounted with iso9660.
>
> It's useful to work with the httpboot in EFI firmware to pull a remote
> ISO file to the local memory region for booting and installation.
>
> Wiki page of UEFI HTTPBoot with OVMF:
> https://en.opensuse.org/UEFI_HTTPBoot_with_OVMF
>
> The ramdisk function in EDK2/OVMF generates a ACPI0012 root device that
> it contains empty _STA but without _DSM:
>
> DefinitionBlock ("ssdt2.aml", "SSDT", 2, "INTEL ", "RamDisk ", 0x1000)
> {
> Scope (\_SB)
> {
> Device (NVDR)
> {
> Name (_HID, "ACPI0012")  // _HID: Hardware ID
> Name (_STR, Unicode ("NVDIMM Root Device"))  // _STR: Description 
> String
> Method (_STA, 0, NotSerialized)  // _STA: Status
> {
> Return (0x0F)
> }
> }
> }
> }
>
> In section 5.2.25.2 of ACPI 6.1 spec, it mentions that the "SPA Range
> Structure Index" of virtual SPA shall be set to zero. That means virtual SPA
> will not be associated by any NVDIMM region mapping.
>
> The VCD's SPA Range Structure in NFIT is similar to virtual disk region
> as following:
>
> [028h 0040   2]Subtable Type :  [System Physical Address 
> Range]
> [02Ah 0042   2]   Length : 0038
>
> [02Ch 0044   2]  Range Index : 
> [02Eh 0046   2]Flags (decoded below) : 
>Add/Online Operation Only : 0
>   Proximity Domain Valid : 0
> [030h 0048   4] Reserved : 
> [034h 0052   4] Proximity Domain : 
> [038h 0056  16]   Address Range GUID : 
> 77AB535A-45FC-624B-5560-F7B281D1F96E
> [048h 0072   8]   Address Range Base : B6ABD018
> [050h 0080   8] Address Range Length : 0550
> [058h 0088   8] Memory Map Attribute : 
>
> The way to not associate a SPA range is to never reference it from a "flush 
> hint",
> "interleave", or "control region" table.
>
> After testing on OVMF, pmem driver can support the region that it doesn't
> assoicate to any NVDIMM mapping. So, treat VCD like pmem is a idea to get
> a pmem block device that it contains iso.
>
> v4:
> Instoduce nfit_spa_is_virtual() to check virtual ramdisk SPA and create
> pmem region.
>
> v3:
> To simplify patch, removed useless VCD region in libnvdimm.
>
> v2:
> Removed the code for setting VCD to a read-only region.
>
> Cc: Gary Lin 
> Cc: Dan Williams 
> Cc: Ross Zwisler 
> Cc: "Rafael J. Wysocki" 
> Cc: Linda Knippers 
> Signed-off-by: Lee, Chun-Yi 

Applied, thanks.

RE: Purpose of pci_remap_iospace

[Bharat Kumar Gogada]

> On Thu, Jul 14, 2016 at 01:32:13PM +, Bharat Kumar Gogada wrote:
>
> [...]
>
> > Hi Lorenzo,
> >
> > I missed something in my device tree now I corrected it.
> >
> > ranges = <0x0100 0x 0xe000 0x 0xe000 0
> 0x0001   //io
>
> You have not missed anything, you changed the PCI bus address at which
> your host bridge responds to IO space and it must match your configuration.
> At what PCI bus address your host bridge maps IO space ?
>
Our host bridge does not have dedicted address space mapped for IO transactions.
For generation of IO transactions it requires some register read and write 
operations
in bridge logic.

So the above PCI address does not come in to picture also, is there alternate 
way to handle IO
Bars with our kind of hardware architecture.

Thanks & Regards,
Bharat


This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be proprietary, 
privileged or copyrighted under applicable law. If you are not the intended 
recipient, do not read, copy, or forward this email message or any attachments. 
Delete this email message and any attachments immediately.

RE: Purpose of pci_remap_iospace

[Bharat Kumar Gogada]

> On Thu, Jul 14, 2016 at 01:32:13PM +, Bharat Kumar Gogada wrote:
>
> [...]
>
> > Hi Lorenzo,
> >
> > I missed something in my device tree now I corrected it.
> >
> > ranges = <0x0100 0x 0xe000 0x 0xe000 0
> 0x0001   //io
>
> You have not missed anything, you changed the PCI bus address at which
> your host bridge responds to IO space and it must match your configuration.
> At what PCI bus address your host bridge maps IO space ?
>
Our host bridge does not have dedicted address space mapped for IO transactions.
For generation of IO transactions it requires some register read and write 
operations
in bridge logic.

So the above PCI address does not come in to picture also, is there alternate 
way to handle IO
Bars with our kind of hardware architecture.

Thanks & Regards,
Bharat


This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be proprietary, 
privileged or copyrighted under applicable law. If you are not the intended 
recipient, do not read, copy, or forward this email message or any attachments. 
Delete this email message and any attachments immediately.

[PATCH] usb: ohci-platform: use helper variables in probe function

[Rafał Miłecki]

Probing function was using >dev and dev->dev.of_node over 20 times
so I believe it made sense to use helper variables for both of them.
To avoid some uncommon variable name for struct device I first replaced
existing dev variable with pdev.

Signed-off-by: Rafał Miłecki 
---
 drivers/usb/host/ohci-platform.c | 66 +++-
 1 file changed, 32 insertions(+), 34 deletions(-)

diff --git a/drivers/usb/host/ohci-platform.c b/drivers/usb/host/ohci-platform.c
index 898b740..d768c87 100644
--- a/drivers/usb/host/ohci-platform.c
+++ b/drivers/usb/host/ohci-platform.c
@@ -111,11 +111,13 @@ static struct usb_ohci_pdata ohci_platform_defaults = {
.power_off =ohci_platform_power_off,
 };
 
-static int ohci_platform_probe(struct platform_device *dev)
+static int ohci_platform_probe(struct platform_device *pdev)
 {
+   struct device *dev = >dev;
+   struct device_node *np = dev->of_node;
struct usb_hcd *hcd;
struct resource *res_mem;
-   struct usb_ohci_pdata *pdata = dev_get_platdata(>dev);
+   struct usb_ohci_pdata *pdata = dev_get_platdata(dev);
struct ohci_platform_priv *priv;
struct ohci_hcd *ohci;
int err, irq, phy_num, clk = 0, rst = 0;
@@ -130,47 +132,45 @@ static int ohci_platform_probe(struct platform_device 
*dev)
if (!pdata)
pdata = _platform_defaults;
 
-   err = dma_coerce_mask_and_coherent(>dev, DMA_BIT_MASK(32));
+   err = dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(32));
if (err)
return err;
 
-   irq = platform_get_irq(dev, 0);
+   irq = platform_get_irq(pdev, 0);
if (irq < 0) {
-   dev_err(>dev, "no irq provided");
+   dev_err(dev, "no irq provided");
return irq;
}
 
-   hcd = usb_create_hcd(_platform_hc_driver, >dev,
-   dev_name(>dev));
+   hcd = usb_create_hcd(_platform_hc_driver, dev, dev_name(dev));
if (!hcd)
return -ENOMEM;
 
-   platform_set_drvdata(dev, hcd);
-   dev->dev.platform_data = pdata;
+   platform_set_drvdata(pdev, hcd);
+   dev->platform_data = pdata;
priv = hcd_to_ohci_priv(hcd);
ohci = hcd_to_ohci(hcd);
 
-   if (pdata == _platform_defaults && dev->dev.of_node) {
-   if (of_property_read_bool(dev->dev.of_node, "big-endian-regs"))
+   if (pdata == _platform_defaults && np) {
+   if (of_property_read_bool(np, "big-endian-regs"))
ohci->flags |= OHCI_QUIRK_BE_MMIO;
 
-   if (of_property_read_bool(dev->dev.of_node, "big-endian-desc"))
+   if (of_property_read_bool(np, "big-endian-desc"))
ohci->flags |= OHCI_QUIRK_BE_DESC;
 
-   if (of_property_read_bool(dev->dev.of_node, "big-endian"))
+   if (of_property_read_bool(np, "big-endian"))
ohci->flags |= OHCI_QUIRK_BE_MMIO | OHCI_QUIRK_BE_DESC;
 
-   if (of_property_read_bool(dev->dev.of_node, "no-big-frame-no"))
+   if (of_property_read_bool(np, "no-big-frame-no"))
ohci->flags |= OHCI_QUIRK_FRAME_NO;
 
-   of_property_read_u32(dev->dev.of_node, "num-ports",
->num_ports);
+   of_property_read_u32(np, "num-ports", >num_ports);
 
-   priv->num_phys = of_count_phandle_with_args(dev->dev.of_node,
-   "phys", "#phy-cells");
+   priv->num_phys = of_count_phandle_with_args(np, "phys",
+   "#phy-cells");
 
if (priv->num_phys > 0) {
-   priv->phys = devm_kcalloc(>dev, priv->num_phys,
+   priv->phys = devm_kcalloc(dev, priv->num_phys,
sizeof(struct phy *), GFP_KERNEL);
if (!priv->phys)
return -ENOMEM;
@@ -178,8 +178,8 @@ static int ohci_platform_probe(struct platform_device *dev)
priv->num_phys = 0;
 
for (phy_num = 0; phy_num < priv->num_phys; phy_num++) {
-   priv->phys[phy_num] = devm_of_phy_get_by_index(
-   >dev, dev->dev.of_node, phy_num);
+   priv->phys[phy_num] = devm_of_phy_get_by_index(dev, np,
+   phy_num);
if (IS_ERR(priv->phys[phy_num])) {
err = PTR_ERR(priv->phys[phy_num]);
goto err_put_hcd;
@@ -187,7 +187,7 @@ static int ohci_platform_probe(struct platform_device *dev)
}
 
for (clk = 0; clk < OHCI_MAX_CLKS; clk++) {
-   priv->clks[clk] = of_clk_get(dev->dev.of_node, clk);
+   priv->clks[clk] = of_clk_get(np, clk);

[PATCH] usb: ohci-platform: use helper variables in probe function

[Rafał Miłecki]

Probing function was using >dev and dev->dev.of_node over 20 times
so I believe it made sense to use helper variables for both of them.
To avoid some uncommon variable name for struct device I first replaced
existing dev variable with pdev.

Signed-off-by: Rafał Miłecki 
---
 drivers/usb/host/ohci-platform.c | 66 +++-
 1 file changed, 32 insertions(+), 34 deletions(-)

diff --git a/drivers/usb/host/ohci-platform.c b/drivers/usb/host/ohci-platform.c
index 898b740..d768c87 100644
--- a/drivers/usb/host/ohci-platform.c
+++ b/drivers/usb/host/ohci-platform.c
@@ -111,11 +111,13 @@ static struct usb_ohci_pdata ohci_platform_defaults = {
.power_off =ohci_platform_power_off,
 };
 
-static int ohci_platform_probe(struct platform_device *dev)
+static int ohci_platform_probe(struct platform_device *pdev)
 {
+   struct device *dev = >dev;
+   struct device_node *np = dev->of_node;
struct usb_hcd *hcd;
struct resource *res_mem;
-   struct usb_ohci_pdata *pdata = dev_get_platdata(>dev);
+   struct usb_ohci_pdata *pdata = dev_get_platdata(dev);
struct ohci_platform_priv *priv;
struct ohci_hcd *ohci;
int err, irq, phy_num, clk = 0, rst = 0;
@@ -130,47 +132,45 @@ static int ohci_platform_probe(struct platform_device 
*dev)
if (!pdata)
pdata = _platform_defaults;
 
-   err = dma_coerce_mask_and_coherent(>dev, DMA_BIT_MASK(32));
+   err = dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(32));
if (err)
return err;
 
-   irq = platform_get_irq(dev, 0);
+   irq = platform_get_irq(pdev, 0);
if (irq < 0) {
-   dev_err(>dev, "no irq provided");
+   dev_err(dev, "no irq provided");
return irq;
}
 
-   hcd = usb_create_hcd(_platform_hc_driver, >dev,
-   dev_name(>dev));
+   hcd = usb_create_hcd(_platform_hc_driver, dev, dev_name(dev));
if (!hcd)
return -ENOMEM;
 
-   platform_set_drvdata(dev, hcd);
-   dev->dev.platform_data = pdata;
+   platform_set_drvdata(pdev, hcd);
+   dev->platform_data = pdata;
priv = hcd_to_ohci_priv(hcd);
ohci = hcd_to_ohci(hcd);
 
-   if (pdata == _platform_defaults && dev->dev.of_node) {
-   if (of_property_read_bool(dev->dev.of_node, "big-endian-regs"))
+   if (pdata == _platform_defaults && np) {
+   if (of_property_read_bool(np, "big-endian-regs"))
ohci->flags |= OHCI_QUIRK_BE_MMIO;
 
-   if (of_property_read_bool(dev->dev.of_node, "big-endian-desc"))
+   if (of_property_read_bool(np, "big-endian-desc"))
ohci->flags |= OHCI_QUIRK_BE_DESC;
 
-   if (of_property_read_bool(dev->dev.of_node, "big-endian"))
+   if (of_property_read_bool(np, "big-endian"))
ohci->flags |= OHCI_QUIRK_BE_MMIO | OHCI_QUIRK_BE_DESC;
 
-   if (of_property_read_bool(dev->dev.of_node, "no-big-frame-no"))
+   if (of_property_read_bool(np, "no-big-frame-no"))
ohci->flags |= OHCI_QUIRK_FRAME_NO;
 
-   of_property_read_u32(dev->dev.of_node, "num-ports",
->num_ports);
+   of_property_read_u32(np, "num-ports", >num_ports);
 
-   priv->num_phys = of_count_phandle_with_args(dev->dev.of_node,
-   "phys", "#phy-cells");
+   priv->num_phys = of_count_phandle_with_args(np, "phys",
+   "#phy-cells");
 
if (priv->num_phys > 0) {
-   priv->phys = devm_kcalloc(>dev, priv->num_phys,
+   priv->phys = devm_kcalloc(dev, priv->num_phys,
sizeof(struct phy *), GFP_KERNEL);
if (!priv->phys)
return -ENOMEM;
@@ -178,8 +178,8 @@ static int ohci_platform_probe(struct platform_device *dev)
priv->num_phys = 0;
 
for (phy_num = 0; phy_num < priv->num_phys; phy_num++) {
-   priv->phys[phy_num] = devm_of_phy_get_by_index(
-   >dev, dev->dev.of_node, phy_num);
+   priv->phys[phy_num] = devm_of_phy_get_by_index(dev, np,
+   phy_num);
if (IS_ERR(priv->phys[phy_num])) {
err = PTR_ERR(priv->phys[phy_num]);
goto err_put_hcd;
@@ -187,7 +187,7 @@ static int ohci_platform_probe(struct platform_device *dev)
}
 
for (clk = 0; clk < OHCI_MAX_CLKS; clk++) {
-   priv->clks[clk] = of_clk_get(dev->dev.of_node, clk);
+   priv->clks[clk] = of_clk_get(np, clk);
  

Re: [PATCH v4 4/4] ASoC: samsung: Add machine driver for Exynos5433 based TM2 board

[Chanwoo Choi]

Hi Sylwester,

[snip]
> +static int tm2_probe(struct platform_device *pdev)
> +{
> + struct device *dev = >dev;
> + struct snd_soc_card *card = _card;
> + struct tm2_machine_priv *priv;
> + struct device_node *cpu_dai_node, *codec_dai_node;
> + int ret, i;
> +
> + if (!dev->of_node) {
> + dev_err(dev, "DT node is missing\n");
> + return -ENODEV;
> + }
> +
> + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + snd_soc_card_set_drvdata(card, priv);
> + card->dev = dev;
> +
> + priv->gpio_mic_bias = devm_gpiod_get(dev, "mic-bias",
> + GPIOF_OUT_INIT_LOW);
> + if (IS_ERR(priv->gpio_mic_bias)) {
> + dev_err(dev, "Failed to get mic bias gpio\n");
> + return PTR_ERR(priv->gpio_mic_bias);
> + }
> +
> + ret = snd_soc_of_parse_card_name(card, "model");
> + if (ret < 0) {
> + dev_err(dev, "Card name is not specified\n");
> + return ret;
> + }
> +
> + ret = snd_soc_of_parse_audio_routing(card, "samsung,audio-routing");
> + if (ret < 0) {
> + dev_err(dev, "Audio routing is not specified or invalid\n");
> + return ret;
> + }
> +
> + card->aux_dev[0].codec_of_node = of_parse_phandle(dev->of_node,
> + "audio-amplifier", 0);
> + if (!card->aux_dev[0].codec_of_node) {
> + dev_err(dev, "audio-amplifier property invalid or missing\n");
> + return -EINVAL;
> + }
> +
> + cpu_dai_node = of_parse_phandle(dev->of_node, "i2s-controller", 0);
> + if (!cpu_dai_node) {
> + dev_err(dev, "i2s-controllers property invalid or missing\n");
> + ret = -EINVAL;
> + goto err_put_amp;
> + }
> +
> + codec_dai_node = of_parse_phandle(dev->of_node, "audio-codec", 0);
> + if (!codec_dai_node) {
> + dev_err(dev, "audio-codec property invalid or missing\n");
> + ret = -EINVAL;
> + goto err_put_cpu_dai;
> + }
> +
> + for (i = 0; i < card->num_links; i++) {
> + card->dai_link[i].cpu_dai_name = NULL;
> + card->dai_link[i].cpu_name = NULL;
> + card->dai_link[i].platform_name = NULL;
> + card->dai_link[i].codec_of_node = codec_dai_node;
> + card->dai_link[i].cpu_of_node = cpu_dai_node;
> + card->dai_link[i].platform_of_node = cpu_dai_node;
> + }
> +
> + priv->codec_mclk1 = of_clk_get_by_name(codec_dai_node, "mclk1");
> + if (IS_ERR(priv->codec_mclk1)) {
> + dev_err(dev, "Failed to get mclk1 clock\n");
> + ret = PTR_ERR(priv->codec_mclk1);
> + goto err_put_codec_dai;
> + }

I think that you better to use the devm_clk_get() instead of 
of_clk_get_by_name()
because you don't need to handle the clk_put() when error happen and remove the 
this driver.

priv->codec_mclk1 = devm_clk_get(dev, "mclk1");

> +
> + /* mclk2 is optional */
> + priv->codec_mclk2 = of_clk_get_by_name(codec_dai_node, "mclk2");
> + if (IS_ERR(priv->codec_mclk2))
> + dev_info(dev, "Not using mclk2 clock\n");

priv->codec_mclk2 = devm_clk_get(dev, "mclk2");

> +
> + ret = devm_snd_soc_register_component(dev, _component,
> + tm2_ext_dai, ARRAY_SIZE(tm2_ext_dai));
> + if (ret < 0) {
> + dev_err(dev, "Failed to register component: %d\n", ret);
> + goto err_put_mclk;
> + }
> +
> + ret = devm_snd_soc_register_card(dev, card);
> + if (ret < 0) {
> + dev_err(dev, "Failed to register card: %d\n", ret);
> + goto err_put_mclk;
> + }
> +
> + return 0;
> +
> +err_put_mclk:
> + clk_put(priv->codec_mclk1);
> + if (!IS_ERR(priv->codec_mclk2))
> + clk_put(priv->codec_mclk2);

If using the devm_clk_get(), clk_put() is not needed

> +err_put_codec_dai:
> + of_node_put(codec_dai_node);
> +err_put_cpu_dai:
> + of_node_put(cpu_dai_node);
> +err_put_amp:
> + of_node_put(card->aux_dev[0].codec_of_node);
> + return ret;
> +}
> +
> +static int tm2_remove(struct platform_device *pdev)
> +{
> + struct snd_soc_card *card = _card;
> + struct tm2_machine_priv *priv = snd_soc_card_get_drvdata(card);
> +
> + clk_put(priv->codec_mclk1);
> + if (!IS_ERR(priv->codec_mclk2))
> + clk_put(priv->codec_mclk2);

ditto.

> +
> + of_node_put(card->dai_link[0].codec_of_node);
> + of_node_put(card->dai_link[0].cpu_of_node);
> + of_node_put(card->aux_dev[0].codec_of_node);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id tm2_of_match[] = {
> + { .compatible = "samsung,tm2-audio" },
> + { },
> +};
> +MODULE_DEVICE_TABLE(of, tm2_of_match);
> +
> +static struct platform_driver tm2_driver = {
> + .driver = {
> + 

Re: [PATCH v4 4/4] ASoC: samsung: Add machine driver for Exynos5433 based TM2 board

[Chanwoo Choi]

Hi Sylwester,

[snip]
> +static int tm2_probe(struct platform_device *pdev)
> +{
> + struct device *dev = >dev;
> + struct snd_soc_card *card = _card;
> + struct tm2_machine_priv *priv;
> + struct device_node *cpu_dai_node, *codec_dai_node;
> + int ret, i;
> +
> + if (!dev->of_node) {
> + dev_err(dev, "DT node is missing\n");
> + return -ENODEV;
> + }
> +
> + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + snd_soc_card_set_drvdata(card, priv);
> + card->dev = dev;
> +
> + priv->gpio_mic_bias = devm_gpiod_get(dev, "mic-bias",
> + GPIOF_OUT_INIT_LOW);
> + if (IS_ERR(priv->gpio_mic_bias)) {
> + dev_err(dev, "Failed to get mic bias gpio\n");
> + return PTR_ERR(priv->gpio_mic_bias);
> + }
> +
> + ret = snd_soc_of_parse_card_name(card, "model");
> + if (ret < 0) {
> + dev_err(dev, "Card name is not specified\n");
> + return ret;
> + }
> +
> + ret = snd_soc_of_parse_audio_routing(card, "samsung,audio-routing");
> + if (ret < 0) {
> + dev_err(dev, "Audio routing is not specified or invalid\n");
> + return ret;
> + }
> +
> + card->aux_dev[0].codec_of_node = of_parse_phandle(dev->of_node,
> + "audio-amplifier", 0);
> + if (!card->aux_dev[0].codec_of_node) {
> + dev_err(dev, "audio-amplifier property invalid or missing\n");
> + return -EINVAL;
> + }
> +
> + cpu_dai_node = of_parse_phandle(dev->of_node, "i2s-controller", 0);
> + if (!cpu_dai_node) {
> + dev_err(dev, "i2s-controllers property invalid or missing\n");
> + ret = -EINVAL;
> + goto err_put_amp;
> + }
> +
> + codec_dai_node = of_parse_phandle(dev->of_node, "audio-codec", 0);
> + if (!codec_dai_node) {
> + dev_err(dev, "audio-codec property invalid or missing\n");
> + ret = -EINVAL;
> + goto err_put_cpu_dai;
> + }
> +
> + for (i = 0; i < card->num_links; i++) {
> + card->dai_link[i].cpu_dai_name = NULL;
> + card->dai_link[i].cpu_name = NULL;
> + card->dai_link[i].platform_name = NULL;
> + card->dai_link[i].codec_of_node = codec_dai_node;
> + card->dai_link[i].cpu_of_node = cpu_dai_node;
> + card->dai_link[i].platform_of_node = cpu_dai_node;
> + }
> +
> + priv->codec_mclk1 = of_clk_get_by_name(codec_dai_node, "mclk1");
> + if (IS_ERR(priv->codec_mclk1)) {
> + dev_err(dev, "Failed to get mclk1 clock\n");
> + ret = PTR_ERR(priv->codec_mclk1);
> + goto err_put_codec_dai;
> + }

I think that you better to use the devm_clk_get() instead of 
of_clk_get_by_name()
because you don't need to handle the clk_put() when error happen and remove the 
this driver.

priv->codec_mclk1 = devm_clk_get(dev, "mclk1");

> +
> + /* mclk2 is optional */
> + priv->codec_mclk2 = of_clk_get_by_name(codec_dai_node, "mclk2");
> + if (IS_ERR(priv->codec_mclk2))
> + dev_info(dev, "Not using mclk2 clock\n");

priv->codec_mclk2 = devm_clk_get(dev, "mclk2");

> +
> + ret = devm_snd_soc_register_component(dev, _component,
> + tm2_ext_dai, ARRAY_SIZE(tm2_ext_dai));
> + if (ret < 0) {
> + dev_err(dev, "Failed to register component: %d\n", ret);
> + goto err_put_mclk;
> + }
> +
> + ret = devm_snd_soc_register_card(dev, card);
> + if (ret < 0) {
> + dev_err(dev, "Failed to register card: %d\n", ret);
> + goto err_put_mclk;
> + }
> +
> + return 0;
> +
> +err_put_mclk:
> + clk_put(priv->codec_mclk1);
> + if (!IS_ERR(priv->codec_mclk2))
> + clk_put(priv->codec_mclk2);

If using the devm_clk_get(), clk_put() is not needed

> +err_put_codec_dai:
> + of_node_put(codec_dai_node);
> +err_put_cpu_dai:
> + of_node_put(cpu_dai_node);
> +err_put_amp:
> + of_node_put(card->aux_dev[0].codec_of_node);
> + return ret;
> +}
> +
> +static int tm2_remove(struct platform_device *pdev)
> +{
> + struct snd_soc_card *card = _card;
> + struct tm2_machine_priv *priv = snd_soc_card_get_drvdata(card);
> +
> + clk_put(priv->codec_mclk1);
> + if (!IS_ERR(priv->codec_mclk2))
> + clk_put(priv->codec_mclk2);

ditto.

> +
> + of_node_put(card->dai_link[0].codec_of_node);
> + of_node_put(card->dai_link[0].cpu_of_node);
> + of_node_put(card->aux_dev[0].codec_of_node);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id tm2_of_match[] = {
> + { .compatible = "samsung,tm2-audio" },
> + { },
> +};
> +MODULE_DEVICE_TABLE(of, tm2_of_match);
> +
> +static struct platform_driver tm2_driver = {
> + .driver = {
> + 

Re: [patch net-next 2/2] devlink: fix trace format string

[David Miller]

From: Jiri Pirko 
Date: Thu, 14 Jul 2016 11:37:29 +0200

> From: Arnd Bergmann 
> 
> Including devlink.h on ARM and probably other 32-bit architectures results in
> a harmless warning:
> 
> In file included from ../include/trace/define_trace.h:95:0,
>  from ../include/trace/events/devlink.h:51,
>  from ../net/core/devlink.c:30:
> include/trace/events/devlink.h: In function 'trace_raw_output_devlink_hwmsg':
> include/trace/events/devlink.h:42:12: error: format '%lu' expects argument of 
> type 'long unsigned int', but argument 10 has type 'size_t {aka unsigned 
> int}' [-Werror=format=]
> 
> The correct format string for 'size_t' is %zu, not %lu, this works on all
> architectures.
> 
> Signed-off-by: Arnd Bergmann 
> Fixes: e5224f0fe2ac ("devlink: add hardware messages tracing facility")
> Signed-off-by: Jiri Pirko 

Applied.

Re: [patch net-next 1/2] tracing: change owner name to driver name for devlink hwmsg tracepoint

[David Miller]

From: Jiri Pirko 
Date: Thu, 14 Jul 2016 11:37:28 +0200

> From: Jiri Pirko 
> 
> Turned on that driver->owner which is struct module is not available when
> modules are disabled. Better to depend on a driver name which is
> always available.
> 
> Reported-by: Randy Dunlap 
> Fixes: e5224f0fe2 ("devlink: add hardware messages tracing facility")
> Signed-off-by: Jiri Pirko 

Applied.

Re: [PATCH v2 02/10] irqchip: add irqchip driver for nuc900

[Wan Zongshun]

On 2016年07月14日 21:54, Jason Cooper wrote:

Hi Wan Zongshun,

On Thu, Jul 14, 2016 at 11:36:53AM +0800, Wan Zongshun wrote:

On 2016年07月14日 04:09, Jason Cooper wrote:

On Sun, Jul 10, 2016 at 03:27:22PM +0800, Wan Zongshun wrote:

This patch is to add irqchip driver support for nuc900 plat,
current this driver only supports nuc970 SoC.

Signed-off-by: Wan Zongshun 
---
  arch/arm/mach-w90x900/include/mach/irqs.h |   5 +
  drivers/irqchip/Makefile  |   1 +
  drivers/irqchip/irq-nuc900.c  | 150 ++
  3 files changed, 156 insertions(+)
  create mode 100644 drivers/irqchip/irq-nuc900.c

diff --git a/arch/arm/mach-w90x900/include/mach/irqs.h 
b/arch/arm/mach-w90x900/include/mach/irqs.h
index 9d5cba3..3b035c6 100644
--- a/arch/arm/mach-w90x900/include/mach/irqs.h
+++ b/arch/arm/mach-w90x900/include/mach/irqs.h
@@ -59,7 +59,12 @@
  #define IRQ_KPI   W90X900_IRQ(29)
  #define IRQ_P2SGROUP  W90X900_IRQ(30)
  #define IRQ_ADC   W90X900_IRQ(31)
+
+#if !defined(CONFIG_SOC_NUC900)
  #define NR_IRQS   (IRQ_ADC+1)
+#else
+#define NR_IRQS62
+#endif


Arnd already covered this...



  /*for irq group*/

diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 38853a1..9ccd5af8a 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -69,3 +69,4 @@ obj-$(CONFIG_PIC32_EVIC)  += irq-pic32-evic.o
  obj-$(CONFIG_MVEBU_ODMI)  += irq-mvebu-odmi.o
  obj-$(CONFIG_LS_SCFG_MSI) += irq-ls-scfg-msi.o
  obj-$(CONFIG_EZNPS_GIC)   += irq-eznps.o
+obj-$(CONFIG_SOC_NUC970)   += irq-nuc900.o
diff --git a/drivers/irqchip/irq-nuc900.c b/drivers/irqchip/irq-nuc900.c
new file mode 100644
index 000..c4b2e39
--- /dev/null
+++ b/drivers/irqchip/irq-nuc900.c
@@ -0,0 +1,150 @@
+/*
+ * Copyright 2016 Wan Zongshun 
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#defineREG_AIC_SCR10x00
+#defineREG_AIC_SCR20x04
+#defineREG_AIC_SCR30x08
+#defineREG_AIC_SCR40x0C
+#defineREG_AIC_SCR50x10
+#defineREG_AIC_SCR60x14
+#defineREG_AIC_SCR70x18
+#defineREG_AIC_SCR80x1C
+#defineREG_AIC_SCR90x20
+#defineREG_AIC_SCR10   0x24
+#defineREG_AIC_SCR11   0x28
+#defineREG_AIC_SCR12   0x2C
+#defineREG_AIC_SCR13   0x30
+#defineREG_AIC_SCR14   0x34
+#defineREG_AIC_SCR15   0x38
+#defineREG_AIC_IRSR0x100
+#defineREG_AIC_IRSRH   0x104
+#defineREG_AIC_IASR0x108
+#defineREG_AIC_IASRH   0x10C
+#defineREG_AIC_ISR 0x110
+#defineREG_AIC_ISRH0x114
+#defineREG_AIC_IPER0x118
+#defineREG_AIC_ISNR0x120
+#defineREG_AIC_OISR0x124
+#defineREG_AIC_IMR 0x128
+#defineREG_AIC_IMRH0x12C
+#defineREG_AIC_MECR0x130
+#defineREG_AIC_MECRH   0x134
+#defineREG_AIC_MDCR0x138
+#defineREG_AIC_MDCRH   0x13C
+#defineREG_AIC_SSCR0x140
+#defineREG_AIC_SSCRH   0x144
+#defineREG_AIC_SCCR0x148
+#defineREG_AIC_SCCRH   0x14C
+#defineREG_AIC_EOSCR   0x150


Please remove unused defines.


Okay.




+
+static void __iomem *aic_base;
+static struct irq_domain *aic_domain;
+
+static void nuc900_irq_mask(struct irq_data *d)
+{
+   if (d->irq < 32)
+   writel(1 << (d->irq), aic_base + REG_AIC_MDCR);
+   else
+   writel(1 << (d->irq - 32), aic_base + REG_AIC_MDCRH);
+}
+
+static void nuc900_irq_ack(struct irq_data *d)
+{
+   writel(0x01, aic_base + REG_AIC_EOSCR);
+}
+
+static void nuc900_irq_unmask(struct irq_data *d)
+{
+   if (d->irq < 32)
+   writel(1 << (d->irq), aic_base + REG_AIC_MECR);
+   else
+   writel(1 << (d->irq - 32), aic_base + REG_AIC_MECRH);
+}
+
+static struct irq_chip nuc900_irq_chip = {
+   .irq_ack= nuc900_irq_ack,
+   .irq_mask   = nuc900_irq_mask,
+   .irq_unmask = nuc900_irq_unmask,
+};
+
+void __exception_irq_entry aic_handle_irq(struct pt_regs *regs)
+{
+   u32 hwirq;
+
+   hwirq = readl(aic_base + REG_AIC_IPER);
+   hwirq = readl(aic_base + REG_AIC_ISNR);
+   if (!hwirq)
+   writel(0x01, aic_base + REG_AIC_EOSCR);


Could you explain what's going on here?


AIC_IPER, When the AIC generates the interrupt, VECTOR represents
the interrupt channel number that is active, enabled, and has the

Re: [patch net-next 2/2] devlink: fix trace format string

[David Miller]

From: Jiri Pirko 
Date: Thu, 14 Jul 2016 11:37:29 +0200

> From: Arnd Bergmann 
> 
> Including devlink.h on ARM and probably other 32-bit architectures results in
> a harmless warning:
> 
> In file included from ../include/trace/define_trace.h:95:0,
>  from ../include/trace/events/devlink.h:51,
>  from ../net/core/devlink.c:30:
> include/trace/events/devlink.h: In function 'trace_raw_output_devlink_hwmsg':
> include/trace/events/devlink.h:42:12: error: format '%lu' expects argument of 
> type 'long unsigned int', but argument 10 has type 'size_t {aka unsigned 
> int}' [-Werror=format=]
> 
> The correct format string for 'size_t' is %zu, not %lu, this works on all
> architectures.
> 
> Signed-off-by: Arnd Bergmann 
> Fixes: e5224f0fe2ac ("devlink: add hardware messages tracing facility")
> Signed-off-by: Jiri Pirko 

Applied.

Re: [patch net-next 1/2] tracing: change owner name to driver name for devlink hwmsg tracepoint

[David Miller]

From: Jiri Pirko 
Date: Thu, 14 Jul 2016 11:37:28 +0200

> From: Jiri Pirko 
> 
> Turned on that driver->owner which is struct module is not available when
> modules are disabled. Better to depend on a driver name which is
> always available.
> 
> Reported-by: Randy Dunlap 
> Fixes: e5224f0fe2 ("devlink: add hardware messages tracing facility")
> Signed-off-by: Jiri Pirko 

Applied.

Re: [PATCH v2 02/10] irqchip: add irqchip driver for nuc900

[Wan Zongshun]

On 2016年07月14日 21:54, Jason Cooper wrote:

Hi Wan Zongshun,

On Thu, Jul 14, 2016 at 11:36:53AM +0800, Wan Zongshun wrote:

On 2016年07月14日 04:09, Jason Cooper wrote:

On Sun, Jul 10, 2016 at 03:27:22PM +0800, Wan Zongshun wrote:

This patch is to add irqchip driver support for nuc900 plat,
current this driver only supports nuc970 SoC.

Signed-off-by: Wan Zongshun 
---
  arch/arm/mach-w90x900/include/mach/irqs.h |   5 +
  drivers/irqchip/Makefile  |   1 +
  drivers/irqchip/irq-nuc900.c  | 150 ++
  3 files changed, 156 insertions(+)
  create mode 100644 drivers/irqchip/irq-nuc900.c

diff --git a/arch/arm/mach-w90x900/include/mach/irqs.h 
b/arch/arm/mach-w90x900/include/mach/irqs.h
index 9d5cba3..3b035c6 100644
--- a/arch/arm/mach-w90x900/include/mach/irqs.h
+++ b/arch/arm/mach-w90x900/include/mach/irqs.h
@@ -59,7 +59,12 @@
  #define IRQ_KPI   W90X900_IRQ(29)
  #define IRQ_P2SGROUP  W90X900_IRQ(30)
  #define IRQ_ADC   W90X900_IRQ(31)
+
+#if !defined(CONFIG_SOC_NUC900)
  #define NR_IRQS   (IRQ_ADC+1)
+#else
+#define NR_IRQS62
+#endif


Arnd already covered this...



  /*for irq group*/

diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 38853a1..9ccd5af8a 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -69,3 +69,4 @@ obj-$(CONFIG_PIC32_EVIC)  += irq-pic32-evic.o
  obj-$(CONFIG_MVEBU_ODMI)  += irq-mvebu-odmi.o
  obj-$(CONFIG_LS_SCFG_MSI) += irq-ls-scfg-msi.o
  obj-$(CONFIG_EZNPS_GIC)   += irq-eznps.o
+obj-$(CONFIG_SOC_NUC970)   += irq-nuc900.o
diff --git a/drivers/irqchip/irq-nuc900.c b/drivers/irqchip/irq-nuc900.c
new file mode 100644
index 000..c4b2e39
--- /dev/null
+++ b/drivers/irqchip/irq-nuc900.c
@@ -0,0 +1,150 @@
+/*
+ * Copyright 2016 Wan Zongshun 
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#defineREG_AIC_SCR10x00
+#defineREG_AIC_SCR20x04
+#defineREG_AIC_SCR30x08
+#defineREG_AIC_SCR40x0C
+#defineREG_AIC_SCR50x10
+#defineREG_AIC_SCR60x14
+#defineREG_AIC_SCR70x18
+#defineREG_AIC_SCR80x1C
+#defineREG_AIC_SCR90x20
+#defineREG_AIC_SCR10   0x24
+#defineREG_AIC_SCR11   0x28
+#defineREG_AIC_SCR12   0x2C
+#defineREG_AIC_SCR13   0x30
+#defineREG_AIC_SCR14   0x34
+#defineREG_AIC_SCR15   0x38
+#defineREG_AIC_IRSR0x100
+#defineREG_AIC_IRSRH   0x104
+#defineREG_AIC_IASR0x108
+#defineREG_AIC_IASRH   0x10C
+#defineREG_AIC_ISR 0x110
+#defineREG_AIC_ISRH0x114
+#defineREG_AIC_IPER0x118
+#defineREG_AIC_ISNR0x120
+#defineREG_AIC_OISR0x124
+#defineREG_AIC_IMR 0x128
+#defineREG_AIC_IMRH0x12C
+#defineREG_AIC_MECR0x130
+#defineREG_AIC_MECRH   0x134
+#defineREG_AIC_MDCR0x138
+#defineREG_AIC_MDCRH   0x13C
+#defineREG_AIC_SSCR0x140
+#defineREG_AIC_SSCRH   0x144
+#defineREG_AIC_SCCR0x148
+#defineREG_AIC_SCCRH   0x14C
+#defineREG_AIC_EOSCR   0x150


Please remove unused defines.


Okay.




+
+static void __iomem *aic_base;
+static struct irq_domain *aic_domain;
+
+static void nuc900_irq_mask(struct irq_data *d)
+{
+   if (d->irq < 32)
+   writel(1 << (d->irq), aic_base + REG_AIC_MDCR);
+   else
+   writel(1 << (d->irq - 32), aic_base + REG_AIC_MDCRH);
+}
+
+static void nuc900_irq_ack(struct irq_data *d)
+{
+   writel(0x01, aic_base + REG_AIC_EOSCR);
+}
+
+static void nuc900_irq_unmask(struct irq_data *d)
+{
+   if (d->irq < 32)
+   writel(1 << (d->irq), aic_base + REG_AIC_MECR);
+   else
+   writel(1 << (d->irq - 32), aic_base + REG_AIC_MECRH);
+}
+
+static struct irq_chip nuc900_irq_chip = {
+   .irq_ack= nuc900_irq_ack,
+   .irq_mask   = nuc900_irq_mask,
+   .irq_unmask = nuc900_irq_unmask,
+};
+
+void __exception_irq_entry aic_handle_irq(struct pt_regs *regs)
+{
+   u32 hwirq;
+
+   hwirq = readl(aic_base + REG_AIC_IPER);
+   hwirq = readl(aic_base + REG_AIC_ISNR);
+   if (!hwirq)
+   writel(0x01, aic_base + REG_AIC_EOSCR);


Could you explain what's going on here?


AIC_IPER, When the AIC generates the interrupt, VECTOR represents
the interrupt channel number that is active, enabled, and has the
highest priority.

The value of VECTOR is 

Re: [PATCH] mlxsw: spectrum_router: Return -ENOENT in case of error

[David Miller]

From: Jiri Pirko 
Date: Thu, 14 Jul 2016 08:28:19 +0200

> Thu, Jul 14, 2016 at 08:18:45AM CEST, christophe.jail...@wanadoo.fr wrote:
>>'vr' should be a valid pointer here, so returning 'PTR_ERR(vr)' is wrong.
>>Return an explicit error code (-ENOENT) instead.
>>
> 
> This is fo net-next.
> 
> Fixes: 61c503f976 ("mlxsw: spectrum_router: Implement fib4 add/del switchdev 
> obj ops")
> 
>>Signed-off-by: Christophe JAILLET 
> 
> Acked-by: Jiri Pirko 

Applied, thanks.

Re: [PATCH] mlxsw: spectrum_router: Return -ENOENT in case of error

[David Miller]

From: Jiri Pirko 
Date: Thu, 14 Jul 2016 08:28:19 +0200

> Thu, Jul 14, 2016 at 08:18:45AM CEST, christophe.jail...@wanadoo.fr wrote:
>>'vr' should be a valid pointer here, so returning 'PTR_ERR(vr)' is wrong.
>>Return an explicit error code (-ENOENT) instead.
>>
> 
> This is fo net-next.
> 
> Fixes: 61c503f976 ("mlxsw: spectrum_router: Implement fib4 add/del switchdev 
> obj ops")
> 
>>Signed-off-by: Christophe JAILLET 
> 
> Acked-by: Jiri Pirko 

Applied, thanks.

linux-next: manual merge of the devicetree tree with the arc tree

[Stephen Rothwell]

Hi Rob,

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

  arch/arc/kernel/setup.c

between commit:

  1ce0b5857f66 ("ARC: fix linux-next build breakage")

from the arc tree and commit:

  61c78644e7f1 ("arc: Remove unnecessary of_platform_populate with default 
match table")

from the devicetree tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc arch/arc/kernel/setup.c
index 5f8c0b47045a,584c5f064ff3..
--- a/arch/arc/kernel/setup.c
+++ b/arch/arc/kernel/setup.c
@@@ -14,8 -14,6 +14,7 @@@
  #include 
  #include 
  #include 
 +#include 
- #include 
  #include 
  #include 
  #include 

linux-next: manual merge of the devicetree tree with the arc tree

[Stephen Rothwell]

Hi Rob,

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

  arch/arc/kernel/setup.c

between commit:

  1ce0b5857f66 ("ARC: fix linux-next build breakage")

from the arc tree and commit:

  61c78644e7f1 ("arc: Remove unnecessary of_platform_populate with default 
match table")

from the devicetree tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc arch/arc/kernel/setup.c
index 5f8c0b47045a,584c5f064ff3..
--- a/arch/arc/kernel/setup.c
+++ b/arch/arc/kernel/setup.c
@@@ -14,8 -14,6 +14,7 @@@
  #include 
  #include 
  #include 
 +#include 
- #include 
  #include 
  #include 
  #include 

Re: [PATCH] staging: lustre: o2iblnd: iov fixes for kiblnd_send

[Al Viro]

On Fri, Jul 15, 2016 at 01:01:35AM -0400, Oleg Drokin wrote:

> > +   } else {
> > +   iov_iter_kvec(, ITER_KVEC | WRITE,
> > + payload_iov, payload_niov,
> > + payload_nob + payload_offset);
> > +   }
> > iov_iter_advance(, payload_offset);
> 
> Ah, I guess we added it there to then subtract here?

Yes (and that actually fixes a real bug there).

> Do you mind if I just merge this change into Al's patch with you as another
> Signed-off-by line instead?
> Since we caught this early, probably no point in having a breakage point in
> the history as it might break a future bisect.

No objections from me.  FWIW, I'd rather have all of that go through your
tree - it's independent from everything else in vfs.git and pulls quite
a bit from yours, so...

Re: [PATCH] staging: lustre: o2iblnd: iov fixes for kiblnd_send

[Al Viro]

On Fri, Jul 15, 2016 at 01:01:35AM -0400, Oleg Drokin wrote:

> > +   } else {
> > +   iov_iter_kvec(, ITER_KVEC | WRITE,
> > + payload_iov, payload_niov,
> > + payload_nob + payload_offset);
> > +   }
> > iov_iter_advance(, payload_offset);
> 
> Ah, I guess we added it there to then subtract here?

Yes (and that actually fixes a real bug there).

> Do you mind if I just merge this change into Al's patch with you as another
> Signed-off-by line instead?
> Since we caught this early, probably no point in having a breakage point in
> the history as it might break a future bisect.

No objections from me.  FWIW, I'd rather have all of that go through your
tree - it's independent from everything else in vfs.git and pulls quite
a bit from yours, so...

Re: [PATCH] KVM: release anon file in failure path of vm creation

[Al Viro]

On Fri, Jul 15, 2016 at 11:18:41AM +0800, Liu Shuo wrote:

> If there is no such thread (who operates the descriptor based on
> guessing), i can think the changing is safe at the point. As the fd has
> not been delivered to userspace. Am i right?


Expecting nice behaviour from userland code is something best avoided, really.


All jokes aside, this other thread doesn't have to be malicious - just being
buggy would suffice.  Besides, you never know if something like userns won't
be dumped into the kernel, making your ioctl accessible to genuinely
malicious code.

The only sane approach is to treat descriptor tables as shared data structures
and postpone the insertion of struct file reference into descriptor table
until you are past all failure exits.  Including the ones related to copying
to userland - e.g. pipe(2) creates a pipe, sets up two struct file associated
with it, reserves two descriptors, copies them into userland array and only if
everything has succeeded proceeds to fd_install().  In your case passing the
descriptor to userland is not an issue (return value of ioctl(2) goes via
register and that can't fail), so the last failure exit is that after failed
attempt to create debugfs stuff.  We have to reserve the descriptor before
that (it's used as a part of debugfs directory name), so anon_inode_getfd()
is not an option - it combines reserving descriptor with fd_install().
Such situations are exactly the reason why anon_inode_getfile() is there;
anon_inode_getfd() is usable only when it is the very last thing we do
before returning the descriptor to userland.

FWIW, original code was not unreasonable - it simply treated debugfs stuff as
optional and ignored those failures.  That way anon_inode_getfd() is fine -
there's no failure exits after it.  If we want to fail when debugfs had
been enabled and we'd failed to populate it, we need to use the real primitives
behind anon_inode_getfd(), though.

Re: [PATCH] KVM: release anon file in failure path of vm creation

[Al Viro]

On Fri, Jul 15, 2016 at 11:18:41AM +0800, Liu Shuo wrote:

> If there is no such thread (who operates the descriptor based on
> guessing), i can think the changing is safe at the point. As the fd has
> not been delivered to userspace. Am i right?


Expecting nice behaviour from userland code is something best avoided, really.


All jokes aside, this other thread doesn't have to be malicious - just being
buggy would suffice.  Besides, you never know if something like userns won't
be dumped into the kernel, making your ioctl accessible to genuinely
malicious code.

The only sane approach is to treat descriptor tables as shared data structures
and postpone the insertion of struct file reference into descriptor table
until you are past all failure exits.  Including the ones related to copying
to userland - e.g. pipe(2) creates a pipe, sets up two struct file associated
with it, reserves two descriptors, copies them into userland array and only if
everything has succeeded proceeds to fd_install().  In your case passing the
descriptor to userland is not an issue (return value of ioctl(2) goes via
register and that can't fail), so the last failure exit is that after failed
attempt to create debugfs stuff.  We have to reserve the descriptor before
that (it's used as a part of debugfs directory name), so anon_inode_getfd()
is not an option - it combines reserving descriptor with fd_install().
Such situations are exactly the reason why anon_inode_getfile() is there;
anon_inode_getfd() is usable only when it is the very last thing we do
before returning the descriptor to userland.

FWIW, original code was not unreasonable - it simply treated debugfs stuff as
optional and ignored those failures.  That way anon_inode_getfd() is fine -
there's no failure exits after it.  If we want to fail when debugfs had
been enabled and we'd failed to populate it, we need to use the real primitives
behind anon_inode_getfd(), though.

[PATCH V2] usb: ehci-platform: use helper variables in probe function

[Rafał Miłecki]

Probing function was using >dev and dev->dev.of_node over 20 times
so I believe it made sense to use helper variables for both of them.
To avoid some uncommon variable name for struct device I first replaced
existing dev variable with pdev.

Signed-off-by: Rafał Miłecki 
Acked-by: Alan Stern 
---
V2: Use 2 extra tabs after line break to match one of already used
coding styles.
---
 drivers/usb/host/ehci-platform.c | 65 +++-
 1 file changed, 31 insertions(+), 34 deletions(-)

diff --git a/drivers/usb/host/ehci-platform.c b/drivers/usb/host/ehci-platform.c
index 6816b8c..d67dd92 100644
--- a/drivers/usb/host/ehci-platform.c
+++ b/drivers/usb/host/ehci-platform.c
@@ -143,11 +143,13 @@ static struct usb_ehci_pdata ehci_platform_defaults = {
.power_off =ehci_platform_power_off,
 };
 
-static int ehci_platform_probe(struct platform_device *dev)
+static int ehci_platform_probe(struct platform_device *pdev)
 {
+   struct device *dev = >dev;
+   struct device_node *np = dev->of_node;
struct usb_hcd *hcd;
struct resource *res_mem;
-   struct usb_ehci_pdata *pdata = dev_get_platdata(>dev);
+   struct usb_ehci_pdata *pdata = dev_get_platdata(dev);
struct ehci_platform_priv *priv;
struct ehci_hcd *ehci;
int err, irq, phy_num, clk = 0, rst;
@@ -162,52 +164,49 @@ static int ehci_platform_probe(struct platform_device 
*dev)
if (!pdata)
pdata = _platform_defaults;
 
-   err = dma_coerce_mask_and_coherent(>dev,
+   err = dma_coerce_mask_and_coherent(dev,
pdata->dma_mask_64 ? DMA_BIT_MASK(64) : DMA_BIT_MASK(32));
if (err) {
-   dev_err(>dev, "Error: DMA mask configuration failed\n");
+   dev_err(dev, "Error: DMA mask configuration failed\n");
return err;
}
 
-   irq = platform_get_irq(dev, 0);
+   irq = platform_get_irq(pdev, 0);
if (irq < 0) {
-   dev_err(>dev, "no irq provided");
+   dev_err(dev, "no irq provided");
return irq;
}
 
-   hcd = usb_create_hcd(_platform_hc_driver, >dev,
-dev_name(>dev));
+   hcd = usb_create_hcd(_platform_hc_driver, dev, dev_name(dev));
if (!hcd)
return -ENOMEM;
 
-   platform_set_drvdata(dev, hcd);
-   dev->dev.platform_data = pdata;
+   platform_set_drvdata(pdev, hcd);
+   dev->platform_data = pdata;
priv = hcd_to_ehci_priv(hcd);
ehci = hcd_to_ehci(hcd);
 
-   if (pdata == _platform_defaults && dev->dev.of_node) {
-   if (of_property_read_bool(dev->dev.of_node, "big-endian-regs"))
+   if (pdata == _platform_defaults && np) {
+   if (of_property_read_bool(np, "big-endian-regs"))
ehci->big_endian_mmio = 1;
 
-   if (of_property_read_bool(dev->dev.of_node, "big-endian-desc"))
+   if (of_property_read_bool(np, "big-endian-desc"))
ehci->big_endian_desc = 1;
 
-   if (of_property_read_bool(dev->dev.of_node, "big-endian"))
+   if (of_property_read_bool(np, "big-endian"))
ehci->big_endian_mmio = ehci->big_endian_desc = 1;
 
-   if (of_property_read_bool(dev->dev.of_node,
- "needs-reset-on-resume"))
+   if (of_property_read_bool(np, "needs-reset-on-resume"))
priv->reset_on_resume = true;
 
-   if (of_property_read_bool(dev->dev.of_node,
- "has-transaction-translator"))
+   if (of_property_read_bool(np, "has-transaction-translator"))
hcd->has_tt = 1;
 
-   priv->num_phys = of_count_phandle_with_args(dev->dev.of_node,
-   "phys", "#phy-cells");
+   priv->num_phys = of_count_phandle_with_args(np, "phys",
+   "#phy-cells");
 
if (priv->num_phys > 0) {
-   priv->phys = devm_kcalloc(>dev, priv->num_phys,
+   priv->phys = devm_kcalloc(dev, priv->num_phys,
sizeof(struct phy *), GFP_KERNEL);
if (!priv->phys)
return -ENOMEM;
@@ -216,7 +215,7 @@ static int ehci_platform_probe(struct platform_device *dev)
 
for (phy_num = 0; phy_num < priv->num_phys; phy_num++) {
priv->phys[phy_num] = devm_of_phy_get_by_index(
-   >dev, dev->dev.of_node, phy_num);
+   dev, np, phy_num);
if (IS_ERR(priv->phys[phy_num])) {
err = PTR_ERR(priv->phys[phy_num]);

[PATCH V2] usb: ehci-platform: use helper variables in probe function

[Rafał Miłecki]

Probing function was using >dev and dev->dev.of_node over 20 times
so I believe it made sense to use helper variables for both of them.
To avoid some uncommon variable name for struct device I first replaced
existing dev variable with pdev.

Signed-off-by: Rafał Miłecki 
Acked-by: Alan Stern 
---
V2: Use 2 extra tabs after line break to match one of already used
coding styles.
---
 drivers/usb/host/ehci-platform.c | 65 +++-
 1 file changed, 31 insertions(+), 34 deletions(-)

diff --git a/drivers/usb/host/ehci-platform.c b/drivers/usb/host/ehci-platform.c
index 6816b8c..d67dd92 100644
--- a/drivers/usb/host/ehci-platform.c
+++ b/drivers/usb/host/ehci-platform.c
@@ -143,11 +143,13 @@ static struct usb_ehci_pdata ehci_platform_defaults = {
.power_off =ehci_platform_power_off,
 };
 
-static int ehci_platform_probe(struct platform_device *dev)
+static int ehci_platform_probe(struct platform_device *pdev)
 {
+   struct device *dev = >dev;
+   struct device_node *np = dev->of_node;
struct usb_hcd *hcd;
struct resource *res_mem;
-   struct usb_ehci_pdata *pdata = dev_get_platdata(>dev);
+   struct usb_ehci_pdata *pdata = dev_get_platdata(dev);
struct ehci_platform_priv *priv;
struct ehci_hcd *ehci;
int err, irq, phy_num, clk = 0, rst;
@@ -162,52 +164,49 @@ static int ehci_platform_probe(struct platform_device 
*dev)
if (!pdata)
pdata = _platform_defaults;
 
-   err = dma_coerce_mask_and_coherent(>dev,
+   err = dma_coerce_mask_and_coherent(dev,
pdata->dma_mask_64 ? DMA_BIT_MASK(64) : DMA_BIT_MASK(32));
if (err) {
-   dev_err(>dev, "Error: DMA mask configuration failed\n");
+   dev_err(dev, "Error: DMA mask configuration failed\n");
return err;
}
 
-   irq = platform_get_irq(dev, 0);
+   irq = platform_get_irq(pdev, 0);
if (irq < 0) {
-   dev_err(>dev, "no irq provided");
+   dev_err(dev, "no irq provided");
return irq;
}
 
-   hcd = usb_create_hcd(_platform_hc_driver, >dev,
-dev_name(>dev));
+   hcd = usb_create_hcd(_platform_hc_driver, dev, dev_name(dev));
if (!hcd)
return -ENOMEM;
 
-   platform_set_drvdata(dev, hcd);
-   dev->dev.platform_data = pdata;
+   platform_set_drvdata(pdev, hcd);
+   dev->platform_data = pdata;
priv = hcd_to_ehci_priv(hcd);
ehci = hcd_to_ehci(hcd);
 
-   if (pdata == _platform_defaults && dev->dev.of_node) {
-   if (of_property_read_bool(dev->dev.of_node, "big-endian-regs"))
+   if (pdata == _platform_defaults && np) {
+   if (of_property_read_bool(np, "big-endian-regs"))
ehci->big_endian_mmio = 1;
 
-   if (of_property_read_bool(dev->dev.of_node, "big-endian-desc"))
+   if (of_property_read_bool(np, "big-endian-desc"))
ehci->big_endian_desc = 1;
 
-   if (of_property_read_bool(dev->dev.of_node, "big-endian"))
+   if (of_property_read_bool(np, "big-endian"))
ehci->big_endian_mmio = ehci->big_endian_desc = 1;
 
-   if (of_property_read_bool(dev->dev.of_node,
- "needs-reset-on-resume"))
+   if (of_property_read_bool(np, "needs-reset-on-resume"))
priv->reset_on_resume = true;
 
-   if (of_property_read_bool(dev->dev.of_node,
- "has-transaction-translator"))
+   if (of_property_read_bool(np, "has-transaction-translator"))
hcd->has_tt = 1;
 
-   priv->num_phys = of_count_phandle_with_args(dev->dev.of_node,
-   "phys", "#phy-cells");
+   priv->num_phys = of_count_phandle_with_args(np, "phys",
+   "#phy-cells");
 
if (priv->num_phys > 0) {
-   priv->phys = devm_kcalloc(>dev, priv->num_phys,
+   priv->phys = devm_kcalloc(dev, priv->num_phys,
sizeof(struct phy *), GFP_KERNEL);
if (!priv->phys)
return -ENOMEM;
@@ -216,7 +215,7 @@ static int ehci_platform_probe(struct platform_device *dev)
 
for (phy_num = 0; phy_num < priv->num_phys; phy_num++) {
priv->phys[phy_num] = devm_of_phy_get_by_index(
-   >dev, dev->dev.of_node, phy_num);
+   dev, np, phy_num);
if (IS_ERR(priv->phys[phy_num])) {
err = PTR_ERR(priv->phys[phy_num]);
goto err_put_hcd;
@@ -224,7 +223,7 @@ static 

Re: [PATCH] staging: lustre: o2iblnd: iov fixes for kiblnd_send

[Oleg Drokin]

On Jul 11, 2016, at 1:18 PM, James Simmons wrote:

> With the move to iov_iter handling two issues merged
> for the ko2iblnd driver. The first fix address a simple
> typo of the wrong flag being used with iov_iter_kvec.
> The second fix adds the payload offset to the payload
> size.
> 
> Signed-off-by: James Simmons 
> ---
> drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c | 13 -
> 1 file changed, 8 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c 
> b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c
> index 3d597dc..437e149 100644
> --- a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c
> +++ b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c
> @@ -1519,12 +1519,15 @@ kiblnd_send(lnet_ni_t *ni, void *private, lnet_msg_t 
> *lntmsg)
>   /* payload is either all vaddrs or all pages */
>   LASSERT(!(payload_kiov && payload_iov));
> 
> - if (payload_kiov)
> + if (payload_kiov) {

The braces are in fact going to make checkpatch complain that we do not
need them here.

>   iov_iter_bvec(, ITER_BVEC | WRITE,
> - payload_kiov, payload_niov, payload_nob);
> - else
> - iov_iter_kvec(, ITER_BVEC | WRITE,
> - payload_iov, payload_niov, payload_nob);
> +   payload_kiov, payload_niov,
> +   payload_nob + payload_offset);

Why are we adding the offset to number of bytes here?

> + } else {
> + iov_iter_kvec(, ITER_KVEC | WRITE,
> +   payload_iov, payload_niov,
> +   payload_nob + payload_offset);
> + }
>   iov_iter_advance(, payload_offset);

Ah, I guess we added it there to then subtract here?

Do you mind if I just merge this change into Al's patch with you as another
Signed-off-by line instead?
Since we caught this early, probably no point in having a breakage point in
the history as it might break a future bisect.


>   switch (type) {
> -- 
> 2.7.4

Re: [PATCH] staging: lustre: o2iblnd: iov fixes for kiblnd_send

[Oleg Drokin]

On Jul 11, 2016, at 1:18 PM, James Simmons wrote:

> With the move to iov_iter handling two issues merged
> for the ko2iblnd driver. The first fix address a simple
> typo of the wrong flag being used with iov_iter_kvec.
> The second fix adds the payload offset to the payload
> size.
> 
> Signed-off-by: James Simmons 
> ---
> drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c | 13 -
> 1 file changed, 8 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c 
> b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c
> index 3d597dc..437e149 100644
> --- a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c
> +++ b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c
> @@ -1519,12 +1519,15 @@ kiblnd_send(lnet_ni_t *ni, void *private, lnet_msg_t 
> *lntmsg)
>   /* payload is either all vaddrs or all pages */
>   LASSERT(!(payload_kiov && payload_iov));
> 
> - if (payload_kiov)
> + if (payload_kiov) {

The braces are in fact going to make checkpatch complain that we do not
need them here.

>   iov_iter_bvec(, ITER_BVEC | WRITE,
> - payload_kiov, payload_niov, payload_nob);
> - else
> - iov_iter_kvec(, ITER_BVEC | WRITE,
> - payload_iov, payload_niov, payload_nob);
> +   payload_kiov, payload_niov,
> +   payload_nob + payload_offset);

Why are we adding the offset to number of bytes here?

> + } else {
> + iov_iter_kvec(, ITER_KVEC | WRITE,
> +   payload_iov, payload_niov,
> +   payload_nob + payload_offset);
> + }
>   iov_iter_advance(, payload_offset);

Ah, I guess we added it there to then subtract here?

Do you mind if I just merge this change into Al's patch with you as another
Signed-off-by line instead?
Since we caught this early, probably no point in having a breakage point in
the history as it might break a future bisect.


>   switch (type) {
> -- 
> 2.7.4

Re: [PATCH net-next V3] net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)

[Leon Romanovsky]

On Thu, Jul 14, 2016 at 09:46:14AM +0300, Netanel Belgazal wrote:
> This is a driver for the ENA family of networking devices.
> 
> Signed-off-by: Netanel Belgazal 
> ---
> 
> Notes:

...

> - Increase driver version to 1.0.2

...

> +static void ena_get_drvinfo(struct net_device *dev,
> + struct ethtool_drvinfo *info)
> +{
> + struct ena_adapter *adapter = netdev_priv(dev);
> +
> + strlcpy(info->driver, DRV_MODULE_NAME, sizeof(info->driver));
> + strlcpy(info->version, DRV_MODULE_VERSION, sizeof(info->version));

Does module version give anything valuable in real life usage?
Do you plan to bump version after every patch?

Hint, NO.

> + strlcpy(info->bus_info, pci_name(adapter->pdev),
> + sizeof(info->bus_info));
> +}
> +
> +

...

> +
> +static char version[] =
> + DEVICE_NAME " v"
> + DRV_MODULE_VERSION " (" DRV_MODULE_RELDATE ")\n";
> +
> +MODULE_AUTHOR("Amazon.com, Inc. or its affiliates");
> +MODULE_DESCRIPTION(DEVICE_NAME);
> +MODULE_LICENSE("GPL");
> +MODULE_VERSION(DRV_MODULE_VERSION);
> +
> +/* Time in jiffies before concluding the transmitter is hung. */
> +#define TX_TIMEOUT  (5 * HZ)
> +
> +#define ENA_NAPI_BUDGET 64
> +
> +#define DEFAULT_MSG_ENABLE (NETIF_MSG_DRV | NETIF_MSG_PROBE | NETIF_MSG_IFUP 
> | \
> + NETIF_MSG_TX_DONE | NETIF_MSG_TX_ERR | NETIF_MSG_RX_ERR)
> +static int debug = -1;
> +module_param(debug, int, 0);
> +MODULE_PARM_DESC(debug, "Debug level (0=none,...,16=all)");

What is it?

> +
> +static int push_mode;
> +module_param(push_mode, int, 0);
> +MODULE_PARM_DESC(push_mode, "Descriptor / header push mode 
> (0=automatic,1=disable,3=enable)\n"
> +  "\t\t\t  0 - Automatically choose according to device 
> capability (default)\n"
> +  "\t\t\t  1 - Don't push anything to device memory\n"
> +  "\t\t\t  3 - Push descriptors and header buffer to device 
> memory");
> +
> +static int enable_wd = 1;
> +module_param(enable_wd, int, 0);
> +MODULE_PARM_DESC(enable_wd, "Enable keepalive watchdog 
> (0=disable,1=enable,default=1)");
> +
> +static int enable_missing_tx_detection = 1;
> +module_param(enable_missing_tx_detection, int, 0);
> +MODULE_PARM_DESC(enable_missing_tx_detection, "Enable missing Tx 
> completions. (default=1)");
> +
> +static int numa_node_override_array[NR_CPUS] = {[0 ... (NR_CPUS - 1)] = 
> NUMA_NO_NODE };
> +module_param_array(numa_node_override_array, int, NULL, 0);
> +MODULE_PARM_DESC(numa_node_override_array, "Numa node override map\n");
> +
> +static int numa_node_override;
> +module_param(numa_node_override, int, 0);
> +MODULE_PARM_DESC(numa_node_override, "Enable/Disable numa node override 
> (0=disable)\n");

As fas as I remember, new drivers are not supposed to add module
parameters.

...

> +
> +#define DRV_MODULE_VER_MAJOR 1
> +#define DRV_MODULE_VER_MINOR 0
> +#define DRV_MODULE_VER_SUBMINOR 1
> +
> +#define DRV_MODULE_NAME  "ena"
> +#ifndef DRV_MODULE_VERSION
> +#define DRV_MODULE_VERSION \
> + __stringify(DRV_MODULE_VER_MAJOR) "."   \
> + __stringify(DRV_MODULE_VER_MINOR) "."   \
> + __stringify(DRV_MODULE_VER_SUBMINOR)
> +#endif
> +#define DRV_MODULE_RELDATE  "22-JUNE-2016"

Please remove it, driver version is useless in real life kernel usage.



signature.asc
Description: Digital signature

Re: [PATCH net-next V3] net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)

[Leon Romanovsky]

On Thu, Jul 14, 2016 at 09:46:14AM +0300, Netanel Belgazal wrote:
> This is a driver for the ENA family of networking devices.
> 
> Signed-off-by: Netanel Belgazal 
> ---
> 
> Notes:

...

> - Increase driver version to 1.0.2

...

> +static void ena_get_drvinfo(struct net_device *dev,
> + struct ethtool_drvinfo *info)
> +{
> + struct ena_adapter *adapter = netdev_priv(dev);
> +
> + strlcpy(info->driver, DRV_MODULE_NAME, sizeof(info->driver));
> + strlcpy(info->version, DRV_MODULE_VERSION, sizeof(info->version));

Does module version give anything valuable in real life usage?
Do you plan to bump version after every patch?

Hint, NO.

> + strlcpy(info->bus_info, pci_name(adapter->pdev),
> + sizeof(info->bus_info));
> +}
> +
> +

...

> +
> +static char version[] =
> + DEVICE_NAME " v"
> + DRV_MODULE_VERSION " (" DRV_MODULE_RELDATE ")\n";
> +
> +MODULE_AUTHOR("Amazon.com, Inc. or its affiliates");
> +MODULE_DESCRIPTION(DEVICE_NAME);
> +MODULE_LICENSE("GPL");
> +MODULE_VERSION(DRV_MODULE_VERSION);
> +
> +/* Time in jiffies before concluding the transmitter is hung. */
> +#define TX_TIMEOUT  (5 * HZ)
> +
> +#define ENA_NAPI_BUDGET 64
> +
> +#define DEFAULT_MSG_ENABLE (NETIF_MSG_DRV | NETIF_MSG_PROBE | NETIF_MSG_IFUP 
> | \
> + NETIF_MSG_TX_DONE | NETIF_MSG_TX_ERR | NETIF_MSG_RX_ERR)
> +static int debug = -1;
> +module_param(debug, int, 0);
> +MODULE_PARM_DESC(debug, "Debug level (0=none,...,16=all)");

What is it?

> +
> +static int push_mode;
> +module_param(push_mode, int, 0);
> +MODULE_PARM_DESC(push_mode, "Descriptor / header push mode 
> (0=automatic,1=disable,3=enable)\n"
> +  "\t\t\t  0 - Automatically choose according to device 
> capability (default)\n"
> +  "\t\t\t  1 - Don't push anything to device memory\n"
> +  "\t\t\t  3 - Push descriptors and header buffer to device 
> memory");
> +
> +static int enable_wd = 1;
> +module_param(enable_wd, int, 0);
> +MODULE_PARM_DESC(enable_wd, "Enable keepalive watchdog 
> (0=disable,1=enable,default=1)");
> +
> +static int enable_missing_tx_detection = 1;
> +module_param(enable_missing_tx_detection, int, 0);
> +MODULE_PARM_DESC(enable_missing_tx_detection, "Enable missing Tx 
> completions. (default=1)");
> +
> +static int numa_node_override_array[NR_CPUS] = {[0 ... (NR_CPUS - 1)] = 
> NUMA_NO_NODE };
> +module_param_array(numa_node_override_array, int, NULL, 0);
> +MODULE_PARM_DESC(numa_node_override_array, "Numa node override map\n");
> +
> +static int numa_node_override;
> +module_param(numa_node_override, int, 0);
> +MODULE_PARM_DESC(numa_node_override, "Enable/Disable numa node override 
> (0=disable)\n");

As fas as I remember, new drivers are not supposed to add module
parameters.

...

> +
> +#define DRV_MODULE_VER_MAJOR 1
> +#define DRV_MODULE_VER_MINOR 0
> +#define DRV_MODULE_VER_SUBMINOR 1
> +
> +#define DRV_MODULE_NAME  "ena"
> +#ifndef DRV_MODULE_VERSION
> +#define DRV_MODULE_VERSION \
> + __stringify(DRV_MODULE_VER_MAJOR) "."   \
> + __stringify(DRV_MODULE_VER_MINOR) "."   \
> + __stringify(DRV_MODULE_VER_SUBMINOR)
> +#endif
> +#define DRV_MODULE_RELDATE  "22-JUNE-2016"

Please remove it, driver version is useless in real life kernel usage.



signature.asc
Description: Digital signature

Re: [PATCH] powernv: Use __printf in pe_level_printk

[Joe Perches]

On Fri, 2016-07-15 at 14:36 +1000, Michael Ellerman wrote:
> Joe Perches  writes:
> 
> > 
> > Make the compiler detect format and argument mismatches.
> > 
> > Signed-off-by: Joe Perches 
> > ---
> >  arch/powerpc/platforms/powernv/pci.h | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/arch/powerpc/platforms/powernv/pci.h
> > b/arch/powerpc/platforms/powernv/pci.h
> > index 3a97990..1c1a586 100644
> > --- a/arch/powerpc/platforms/powernv/pci.h
> > +++ b/arch/powerpc/platforms/powernv/pci.h
> > @@ -213,6 +213,7 @@ extern void pnv_pci_dma_bus_setup(struct pci_bus
> > *bus);
> >  extern int pnv_setup_msi_irqs(struct pci_dev *pdev, int nvec, int
> > type);
> >  extern void pnv_teardown_msi_irqs(struct pci_dev *pdev);
> >  
> > +__printf(3, 4)
> >  extern void pe_level_printk(const struct pnv_ioda_pe *pe, const
> > char *level,
> >     const char *fmt, ...);
> Thanks, but it breaks the build due to lots of new warnings.
> 
> We'll have to fix those before merging it.

Good.  Are you going to fix those?

I thought I did a powerpc defconfig build of arch/powerpc/
and I believe it finished without error, but I'm pleased
it found some defects.

I think it's now marked "rejected" in patchwork.
Perhaps it'd better to mark it "deferred" instead.

Re: [PATCH] powernv: Use __printf in pe_level_printk

[Joe Perches]

On Fri, 2016-07-15 at 14:36 +1000, Michael Ellerman wrote:
> Joe Perches  writes:
> 
> > 
> > Make the compiler detect format and argument mismatches.
> > 
> > Signed-off-by: Joe Perches 
> > ---
> >  arch/powerpc/platforms/powernv/pci.h | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/arch/powerpc/platforms/powernv/pci.h
> > b/arch/powerpc/platforms/powernv/pci.h
> > index 3a97990..1c1a586 100644
> > --- a/arch/powerpc/platforms/powernv/pci.h
> > +++ b/arch/powerpc/platforms/powernv/pci.h
> > @@ -213,6 +213,7 @@ extern void pnv_pci_dma_bus_setup(struct pci_bus
> > *bus);
> >  extern int pnv_setup_msi_irqs(struct pci_dev *pdev, int nvec, int
> > type);
> >  extern void pnv_teardown_msi_irqs(struct pci_dev *pdev);
> >  
> > +__printf(3, 4)
> >  extern void pe_level_printk(const struct pnv_ioda_pe *pe, const
> > char *level,
> >     const char *fmt, ...);
> Thanks, but it breaks the build due to lots of new warnings.
> 
> We'll have to fix those before merging it.

Good.  Are you going to fix those?

I thought I did a powerpc defconfig build of arch/powerpc/
and I believe it finished without error, but I'm pleased
it found some defects.

I think it's now marked "rejected" in patchwork.
Perhaps it'd better to mark it "deferred" instead.

Re: [PATCH v2 02/11] mm: Hardened usercopy

[Kees Cook]

On Thu, Jul 14, 2016 at 9:05 PM, Kees Cook  wrote:
> On Thu, Jul 14, 2016 at 6:41 PM, Balbir Singh  wrote:
>> On Thu, Jul 14, 2016 at 09:04:18PM -0400, Rik van Riel wrote:
>>> On Fri, 2016-07-15 at 09:20 +1000, Balbir Singh wrote:
>>>
>>> > > ==
>>> > > +((unsigned long)end & (unsigned
>>> > > long)PAGE_MASK)))
>>> > > + return NULL;
>>> > > +
>>> > > + /* Allow if start and end are inside the same compound
>>> > > page. */
>>> > > + endpage = virt_to_head_page(end);
>>> > > + if (likely(endpage == page))
>>> > > + return NULL;
>>> > > +
>>> > > + /* Allow special areas, device memory, and sometimes
>>> > > kernel data. */
>>> > > + if (PageReserved(page) && PageReserved(endpage))
>>> > > + return NULL;
>>> >
>>> > If we came here, it's likely that endpage > page, do we need to check
>>> > that only the first and last pages are reserved? What about the ones
>>> > in
>>> > the middle?
>>>
>>> I think this will be so rare, we can get away with just
>>> checking the beginning and the end.
>>>
>>
>> But do we want to leave a hole where an aware user space
>> can try a longer copy_* to avoid this check? If it is unlikely
>> should we just bite the bullet and do the check for the entire
>> range?
>
> I'd be okay with expanding the test -- it should be an extremely rare
> situation already since the common Reserved areas (kernel data) will
> have already been explicitly tested.
>
> What's the best way to do "next page"? Should it just be:
>
> for ( ; page <= endpage ; ptr += PAGE_SIZE, page = virt_to_head_page(ptr) ) {
> if (!PageReserved(page))
> return "";
> }
>
> return NULL;
>
> ?

Er, I was testing the wrong thing. How about:

/*
 * Reject if range is not Reserved (i.e. special or device memory),
 * since then the object spans several independently allocated pages.
 */
for (; ptr <= end ; ptr += PAGE_SIZE, page = virt_to_head_page(ptr)) {
if (!PageReserved(page))
return "";
}

return NULL;



-- 
Kees Cook
Chrome OS & Brillo Security

Re: [PATCH v2 02/11] mm: Hardened usercopy

[Kees Cook]

On Thu, Jul 14, 2016 at 9:05 PM, Kees Cook  wrote:
> On Thu, Jul 14, 2016 at 6:41 PM, Balbir Singh  wrote:
>> On Thu, Jul 14, 2016 at 09:04:18PM -0400, Rik van Riel wrote:
>>> On Fri, 2016-07-15 at 09:20 +1000, Balbir Singh wrote:
>>>
>>> > > ==
>>> > > +((unsigned long)end & (unsigned
>>> > > long)PAGE_MASK)))
>>> > > + return NULL;
>>> > > +
>>> > > + /* Allow if start and end are inside the same compound
>>> > > page. */
>>> > > + endpage = virt_to_head_page(end);
>>> > > + if (likely(endpage == page))
>>> > > + return NULL;
>>> > > +
>>> > > + /* Allow special areas, device memory, and sometimes
>>> > > kernel data. */
>>> > > + if (PageReserved(page) && PageReserved(endpage))
>>> > > + return NULL;
>>> >
>>> > If we came here, it's likely that endpage > page, do we need to check
>>> > that only the first and last pages are reserved? What about the ones
>>> > in
>>> > the middle?
>>>
>>> I think this will be so rare, we can get away with just
>>> checking the beginning and the end.
>>>
>>
>> But do we want to leave a hole where an aware user space
>> can try a longer copy_* to avoid this check? If it is unlikely
>> should we just bite the bullet and do the check for the entire
>> range?
>
> I'd be okay with expanding the test -- it should be an extremely rare
> situation already since the common Reserved areas (kernel data) will
> have already been explicitly tested.
>
> What's the best way to do "next page"? Should it just be:
>
> for ( ; page <= endpage ; ptr += PAGE_SIZE, page = virt_to_head_page(ptr) ) {
> if (!PageReserved(page))
> return "";
> }
>
> return NULL;
>
> ?

Er, I was testing the wrong thing. How about:

/*
 * Reject if range is not Reserved (i.e. special or device memory),
 * since then the object spans several independently allocated pages.
 */
for (; ptr <= end ; ptr += PAGE_SIZE, page = virt_to_head_page(ptr)) {
if (!PageReserved(page))
return "";
}

return NULL;



-- 
Kees Cook
Chrome OS & Brillo Security

[PATCH] mm: show node_pages_scanned per node, not zone

[Minchan Kim]

The node_pages_scanned represents the number of scanned pages
of node for reclaim so it's pointless to show it as kilobytes.

As well, node_pages_scanned is per-node value, not per-zone.

This patch changes node_pages_scannerd per-zone-killobytes
with per-node-count.

Signed-off-by: Minchan Kim 
---
 mm/page_alloc.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index f80a0e5..7edd311 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -4345,6 +4345,7 @@ void show_free_areas(unsigned int filter)
 #endif
" writeback_tmp:%lukB"
" unstable:%lukB"
+   " pages_scanned:%lu"
" all_unreclaimable? %s"
"\n",
pgdat->node_id,
@@ -4367,6 +4368,7 @@ void show_free_areas(unsigned int filter)
K(node_page_state(pgdat, NR_SHMEM)),
K(node_page_state(pgdat, NR_WRITEBACK_TEMP)),
K(node_page_state(pgdat, NR_UNSTABLE_NFS)),
+   node_page_state(zone->zone_pgdat, NR_PAGES_SCANNED),
!pgdat_reclaimable(pgdat) ? "yes" : "no");
}
 
@@ -4397,7 +4399,6 @@ void show_free_areas(unsigned int filter)
" free_pcp:%lukB"
" local_pcp:%ukB"
" free_cma:%lukB"
-   " node_pages_scanned:%lu"
"\n",
zone->name,
K(zone_page_state(zone, NR_FREE_PAGES)),
@@ -4415,8 +4416,7 @@ void show_free_areas(unsigned int filter)
K(zone_page_state(zone, NR_BOUNCE)),
K(free_pcp),
K(this_cpu_read(zone->pageset->pcp.count)),
-   K(zone_page_state(zone, NR_FREE_CMA_PAGES)),
-   K(node_page_state(zone->zone_pgdat, NR_PAGES_SCANNED)));
+   K(zone_page_state(zone, NR_FREE_CMA_PAGES)));
printk("lowmem_reserve[]:");
for (i = 0; i < MAX_NR_ZONES; i++)
printk(" %ld", zone->lowmem_reserve[i]);
-- 
1.9.1

[PATCH] mm: show node_pages_scanned per node, not zone

[Minchan Kim]

The node_pages_scanned represents the number of scanned pages
of node for reclaim so it's pointless to show it as kilobytes.

As well, node_pages_scanned is per-node value, not per-zone.

This patch changes node_pages_scannerd per-zone-killobytes
with per-node-count.

Signed-off-by: Minchan Kim 
---
 mm/page_alloc.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index f80a0e5..7edd311 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -4345,6 +4345,7 @@ void show_free_areas(unsigned int filter)
 #endif
" writeback_tmp:%lukB"
" unstable:%lukB"
+   " pages_scanned:%lu"
" all_unreclaimable? %s"
"\n",
pgdat->node_id,
@@ -4367,6 +4368,7 @@ void show_free_areas(unsigned int filter)
K(node_page_state(pgdat, NR_SHMEM)),
K(node_page_state(pgdat, NR_WRITEBACK_TEMP)),
K(node_page_state(pgdat, NR_UNSTABLE_NFS)),
+   node_page_state(zone->zone_pgdat, NR_PAGES_SCANNED),
!pgdat_reclaimable(pgdat) ? "yes" : "no");
}
 
@@ -4397,7 +4399,6 @@ void show_free_areas(unsigned int filter)
" free_pcp:%lukB"
" local_pcp:%ukB"
" free_cma:%lukB"
-   " node_pages_scanned:%lu"
"\n",
zone->name,
K(zone_page_state(zone, NR_FREE_PAGES)),
@@ -4415,8 +4416,7 @@ void show_free_areas(unsigned int filter)
K(zone_page_state(zone, NR_BOUNCE)),
K(free_pcp),
K(this_cpu_read(zone->pageset->pcp.count)),
-   K(zone_page_state(zone, NR_FREE_CMA_PAGES)),
-   K(node_page_state(zone->zone_pgdat, NR_PAGES_SCANNED)));
+   K(zone_page_state(zone, NR_FREE_CMA_PAGES)));
printk("lowmem_reserve[]:");
for (i = 0; i < MAX_NR_ZONES; i++)
printk(" %ld", zone->lowmem_reserve[i]);
-- 
1.9.1

[git pull] drm vmware fixes.

[Dave Airlie]

Hi Linus,

These are some fixes for the vmware graphics driver, that fix
some black screen issues on at least Ubuntu 16.04, I think VMware
would like to get these in so stable can pick them up ASAP.

It's up to you if you aren't comfortable with them at this stage.

Dave.

The following changes since commit 71404e8a88fa4a94b3833ccc853c322fd6d7:

  Merge tag 'drm-intel-fixes-2016-07-14' of 
git://anongit.freedesktop.org/drm-intel into drm-fixes (2016-07-15 09:19:14 
+1000)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.7-rc8-vmware

for you to fetch changes up to d2e1204f896b17bda1922f6320d3b442367302fc:

  Merge branch 'drm-vmwgfx-fixes' of 
git://people.freedesktop.org/~syeh/repos_linux into drm-fixes (2016-07-15 
13:51:55 +1000)


Dave Airlie (1):
  Merge branch 'drm-vmwgfx-fixes' of 
git://people.freedesktop.org/~syeh/repos_linux into drm-fixes

Sinclair Yeh (7):
  drm/vmwgfx: Add a check to handle host message failure
  drm/vmwgfx: Work around mode set failure in 2D VMs
  drm/vmwgfx: Add an option to change assumed FB bpp
  drm/ttm: Make ttm_bo_mem_compat available
  drm/vmwgfx: Check pin count before attempting to move a buffer
  drm/vmwgfx: Delay pinning fbdev framebuffer until after mode set
  drm/vmwgfx: Fix error paths when mapping framebuffer

Thomas Hellstrom (1):
  drm/vmwgfx: Fix corner case screen target management

 drivers/gpu/drm/ttm/ttm_bo.c   |  7 ++---
 drivers/gpu/drm/vmwgfx/vmwgfx_dmabuf.c | 25 +++---
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c| 12 +
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h|  1 +
 drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 47 ++
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c| 10 +++-
 drivers/gpu/drm/vmwgfx/vmwgfx_msg.c|  3 +++
 drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c   |  8 +++---
 include/drm/ttm/ttm_bo_api.h   | 14 ++
 9 files changed, 88 insertions(+), 39 deletions(-)

[git pull] drm vmware fixes.

[Dave Airlie]

Hi Linus,

These are some fixes for the vmware graphics driver, that fix
some black screen issues on at least Ubuntu 16.04, I think VMware
would like to get these in so stable can pick them up ASAP.

It's up to you if you aren't comfortable with them at this stage.

Dave.

The following changes since commit 71404e8a88fa4a94b3833ccc853c322fd6d7:

  Merge tag 'drm-intel-fixes-2016-07-14' of 
git://anongit.freedesktop.org/drm-intel into drm-fixes (2016-07-15 09:19:14 
+1000)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.7-rc8-vmware

for you to fetch changes up to d2e1204f896b17bda1922f6320d3b442367302fc:

  Merge branch 'drm-vmwgfx-fixes' of 
git://people.freedesktop.org/~syeh/repos_linux into drm-fixes (2016-07-15 
13:51:55 +1000)


Dave Airlie (1):
  Merge branch 'drm-vmwgfx-fixes' of 
git://people.freedesktop.org/~syeh/repos_linux into drm-fixes

Sinclair Yeh (7):
  drm/vmwgfx: Add a check to handle host message failure
  drm/vmwgfx: Work around mode set failure in 2D VMs
  drm/vmwgfx: Add an option to change assumed FB bpp
  drm/ttm: Make ttm_bo_mem_compat available
  drm/vmwgfx: Check pin count before attempting to move a buffer
  drm/vmwgfx: Delay pinning fbdev framebuffer until after mode set
  drm/vmwgfx: Fix error paths when mapping framebuffer

Thomas Hellstrom (1):
  drm/vmwgfx: Fix corner case screen target management

 drivers/gpu/drm/ttm/ttm_bo.c   |  7 ++---
 drivers/gpu/drm/vmwgfx/vmwgfx_dmabuf.c | 25 +++---
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c| 12 +
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h|  1 +
 drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 47 ++
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c| 10 +++-
 drivers/gpu/drm/vmwgfx/vmwgfx_msg.c|  3 +++
 drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c   |  8 +++---
 include/drm/ttm/ttm_bo_api.h   | 14 ++
 9 files changed, 88 insertions(+), 39 deletions(-)

[git pull] drm fixes

[Dave Airlie]

Hi Linus,

These are just some i915 and amdgpu fixes that shows up, the amdgpu
ones are polaris fixes, and i915 is one major regression fix.

I've got some vmwgfx fixes that might be a bit large for this time,
but I'll send them on in a separate pull so it can be decided.

DAve.


The following changes since commit f97d10454e4da2aceb44dfa7c59bb43ba9f50199:

  Merge branches 'perf-urgent-for-linus' and 'timers-urgent-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip (2016-07-14 05:44:47 
+0900)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.7-rc8

for you to fetch changes up to 71404e8a88fa4a94b3833ccc853c322fd6d7:

  Merge tag 'drm-intel-fixes-2016-07-14' of 
git://anongit.freedesktop.org/drm-intel into drm-fixes (2016-07-15 09:19:14 
+1000)


Chris Wilson (1):
  drm/i915: Update ifdeffery for mutex->owner

Dave Airlie (2):
  Merge branch 'drm-fixes-4.7' of git://people.freedesktop.org/~agd5f/linux 
into drm-fixes
  Merge tag 'drm-intel-fixes-2016-07-14' of 
git://anongit.freedesktop.org/drm-intel into drm-fixes

Ken Wang (2):
  drm/amdgpu: Add a missing register to Polaris golden setting
  drm/amdgpu: fix power distribution issue for Polaris10 XT

Ville Syrjälä (1):
  drm/i915: Ignore panel type from OpRegion on SKL

 drivers/gpu/drm/amd/amdgpu/atombios_i2c.c | 15 +++
 drivers/gpu/drm/amd/amdgpu/atombios_i2c.h |  2 ++
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c |  7 +++
 drivers/gpu/drm/i915/i915_gem_shrinker.c  |  2 +-
 drivers/gpu/drm/i915/intel_opregion.c | 11 +++
 5 files changed, 36 insertions(+), 1 deletion(-)

[git pull] drm fixes

[Dave Airlie]

Hi Linus,

These are just some i915 and amdgpu fixes that shows up, the amdgpu
ones are polaris fixes, and i915 is one major regression fix.

I've got some vmwgfx fixes that might be a bit large for this time,
but I'll send them on in a separate pull so it can be decided.

DAve.


The following changes since commit f97d10454e4da2aceb44dfa7c59bb43ba9f50199:

  Merge branches 'perf-urgent-for-linus' and 'timers-urgent-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip (2016-07-14 05:44:47 
+0900)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.7-rc8

for you to fetch changes up to 71404e8a88fa4a94b3833ccc853c322fd6d7:

  Merge tag 'drm-intel-fixes-2016-07-14' of 
git://anongit.freedesktop.org/drm-intel into drm-fixes (2016-07-15 09:19:14 
+1000)


Chris Wilson (1):
  drm/i915: Update ifdeffery for mutex->owner

Dave Airlie (2):
  Merge branch 'drm-fixes-4.7' of git://people.freedesktop.org/~agd5f/linux 
into drm-fixes
  Merge tag 'drm-intel-fixes-2016-07-14' of 
git://anongit.freedesktop.org/drm-intel into drm-fixes

Ken Wang (2):
  drm/amdgpu: Add a missing register to Polaris golden setting
  drm/amdgpu: fix power distribution issue for Polaris10 XT

Ville Syrjälä (1):
  drm/i915: Ignore panel type from OpRegion on SKL

 drivers/gpu/drm/amd/amdgpu/atombios_i2c.c | 15 +++
 drivers/gpu/drm/amd/amdgpu/atombios_i2c.h |  2 ++
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c |  7 +++
 drivers/gpu/drm/i915/i915_gem_shrinker.c  |  2 +-
 drivers/gpu/drm/i915/intel_opregion.c | 11 +++
 5 files changed, 36 insertions(+), 1 deletion(-)

linux-next: manual merge of the block tree with the ext4 tree

[Stephen Rothwell]

Hi all,

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

  fs/ext4/crypto.c

between commit:

  a7550b30ab70 ("ext4 crypto: migrate into vfs's crypto engine")

from the ext4 tree and commits:

  4e49ea4a3d27 ("block/fs/drivers: remove rw argument from submit_bio")
  60a40096a3b2 ("ext4: use bio op helprs in ext4 crypto code")

from the block tree.

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



-- 
Cheers,
Stephen Rothwell

linux-next: manual merge of the block tree with the ext4 tree

[Stephen Rothwell]

Hi all,

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

  fs/ext4/crypto.c

between commit:

  a7550b30ab70 ("ext4 crypto: migrate into vfs's crypto engine")

from the ext4 tree and commits:

  4e49ea4a3d27 ("block/fs/drivers: remove rw argument from submit_bio")
  60a40096a3b2 ("ext4: use bio op helprs in ext4 crypto code")

from the block tree.

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



-- 
Cheers,
Stephen Rothwell

Re: linux-next: build failure after merge of the drm tree

[Sedat Dilek]

On 7/15/16, Stephen Rothwell  wrote:
> Hi Dave,
>
> After merging the drm tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> In file included from drivers/gpu/drm/i915/intel_opregion.c:34:0:
> drivers/gpu/drm/i915/intel_opregion.c: In function
> 'intel_opregion_get_panel_type':
> drivers/gpu/drm/i915/intel_opregion.c:1042:17: error: 'dev' undeclared
> (first use in this function)
>   if (IS_SKYLAKE(dev)) {
>  ^
> drivers/gpu/drm/i915/i915_drv.h:2603:43: note: in definition of macro
> '__I915__'
>   if (__builtin_types_compatible_p(typeof(*p), struct drm_i915_private)) \
>^
> drivers/gpu/drm/i915/i915_drv.h:2670:26: note: in expansion of macro
> 'INTEL_INFO'
>  #define IS_SKYLAKE(dev) (INTEL_INFO(dev)->is_skylake)
>   ^
> drivers/gpu/drm/i915/intel_opregion.c:1042:6: note: in expansion of macro
> 'IS_SKYLAKE'
>   if (IS_SKYLAKE(dev)) {
>   ^
> drivers/gpu/drm/i915/intel_opregion.c:1042:17: note: each undeclared
> identifier is reported only once for each function it appears in
>   if (IS_SKYLAKE(dev)) {
>  ^
> drivers/gpu/drm/i915/i915_drv.h:2603:43: note: in definition of macro
> '__I915__'
>   if (__builtin_types_compatible_p(typeof(*p), struct drm_i915_private)) \
>^
> drivers/gpu/drm/i915/i915_drv.h:2670:26: note: in expansion of macro
> 'INTEL_INFO'
>  #define IS_SKYLAKE(dev) (INTEL_INFO(dev)->is_skylake)
>   ^
> drivers/gpu/drm/i915/intel_opregion.c:1042:6: note: in expansion of macro
> 'IS_SKYLAKE'
>   if (IS_SKYLAKE(dev)) {
>   ^
>
> Caused by commit
>
>   6f9f4b7a2cf7 ("drm/i915/opregion: Convert to using native
> drm_i915_private")
>
> interacting with commit
>
>   aeddda06c1a7 ("drm/i915: Ignore panel type from OpRegion on SKL")
>
> from the drm-intel-fixes tree.
>
> I applied this merge fix patch:
>
> From: Stephen Rothwell 
> Date: Fri, 15 Jul 2016 13:34:05 +1000
> Subject: [PATCH] drm/i915/opregion: fix up for argument change
>
> Signed-off-by: Stephen Rothwell 
> ---
>  drivers/gpu/drm/i915/intel_opregion.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_opregion.c
> b/drivers/gpu/drm/i915/intel_opregion.c
> index 21f19641e33e..dcdb346b596c 100644
> --- a/drivers/gpu/drm/i915/intel_opregion.c
> +++ b/drivers/gpu/drm/i915/intel_opregion.c
> @@ -1039,7 +1039,7 @@ intel_opregion_get_panel_type(struct drm_i915_private
> *dev_priv)
>* vswing instead. Low vswing results in some display flickers, so
>* let's simply ignore the OpRegion panel type on SKL for now.
>*/
> - if (IS_SKYLAKE(dev)) {
> + if (IS_SKYLAKE(dev_priv)) {
>   DRM_DEBUG_KMS("Ignoring OpRegion panel type (%d)\n", ret - 1);
>   return -ENODEV;
>   }
> --
> 2.8.1
>

I fell over the same issue when testing drm-intel-nightly and sent a patch.

- Sedat -

https://lists.freedesktop.org/archives/intel-gfx/2016-July/100691.html

Re: linux-next: build failure after merge of the drm tree

[Sedat Dilek]

On 7/15/16, Stephen Rothwell  wrote:
> Hi Dave,
>
> After merging the drm tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> In file included from drivers/gpu/drm/i915/intel_opregion.c:34:0:
> drivers/gpu/drm/i915/intel_opregion.c: In function
> 'intel_opregion_get_panel_type':
> drivers/gpu/drm/i915/intel_opregion.c:1042:17: error: 'dev' undeclared
> (first use in this function)
>   if (IS_SKYLAKE(dev)) {
>  ^
> drivers/gpu/drm/i915/i915_drv.h:2603:43: note: in definition of macro
> '__I915__'
>   if (__builtin_types_compatible_p(typeof(*p), struct drm_i915_private)) \
>^
> drivers/gpu/drm/i915/i915_drv.h:2670:26: note: in expansion of macro
> 'INTEL_INFO'
>  #define IS_SKYLAKE(dev) (INTEL_INFO(dev)->is_skylake)
>   ^
> drivers/gpu/drm/i915/intel_opregion.c:1042:6: note: in expansion of macro
> 'IS_SKYLAKE'
>   if (IS_SKYLAKE(dev)) {
>   ^
> drivers/gpu/drm/i915/intel_opregion.c:1042:17: note: each undeclared
> identifier is reported only once for each function it appears in
>   if (IS_SKYLAKE(dev)) {
>  ^
> drivers/gpu/drm/i915/i915_drv.h:2603:43: note: in definition of macro
> '__I915__'
>   if (__builtin_types_compatible_p(typeof(*p), struct drm_i915_private)) \
>^
> drivers/gpu/drm/i915/i915_drv.h:2670:26: note: in expansion of macro
> 'INTEL_INFO'
>  #define IS_SKYLAKE(dev) (INTEL_INFO(dev)->is_skylake)
>   ^
> drivers/gpu/drm/i915/intel_opregion.c:1042:6: note: in expansion of macro
> 'IS_SKYLAKE'
>   if (IS_SKYLAKE(dev)) {
>   ^
>
> Caused by commit
>
>   6f9f4b7a2cf7 ("drm/i915/opregion: Convert to using native
> drm_i915_private")
>
> interacting with commit
>
>   aeddda06c1a7 ("drm/i915: Ignore panel type from OpRegion on SKL")
>
> from the drm-intel-fixes tree.
>
> I applied this merge fix patch:
>
> From: Stephen Rothwell 
> Date: Fri, 15 Jul 2016 13:34:05 +1000
> Subject: [PATCH] drm/i915/opregion: fix up for argument change
>
> Signed-off-by: Stephen Rothwell 
> ---
>  drivers/gpu/drm/i915/intel_opregion.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_opregion.c
> b/drivers/gpu/drm/i915/intel_opregion.c
> index 21f19641e33e..dcdb346b596c 100644
> --- a/drivers/gpu/drm/i915/intel_opregion.c
> +++ b/drivers/gpu/drm/i915/intel_opregion.c
> @@ -1039,7 +1039,7 @@ intel_opregion_get_panel_type(struct drm_i915_private
> *dev_priv)
>* vswing instead. Low vswing results in some display flickers, so
>* let's simply ignore the OpRegion panel type on SKL for now.
>*/
> - if (IS_SKYLAKE(dev)) {
> + if (IS_SKYLAKE(dev_priv)) {
>   DRM_DEBUG_KMS("Ignoring OpRegion panel type (%d)\n", ret - 1);
>   return -ENODEV;
>   }
> --
> 2.8.1
>

I fell over the same issue when testing drm-intel-nightly and sent a patch.

- Sedat -

https://lists.freedesktop.org/archives/intel-gfx/2016-July/100691.html

Re: [PATCH v2 11/11] mm: SLUB hardened usercopy support

[Kees Cook]

On Thu, Jul 14, 2016 at 7:05 PM, Balbir Singh  wrote:
> On Wed, Jul 13, 2016 at 02:56:04PM -0700, Kees Cook wrote:
>> Under CONFIG_HARDENED_USERCOPY, this adds object size checking to the
>> SLUB allocator to catch any copies that may span objects. Includes a
>> redzone handling fix from Michael Ellerman.
>>
>> Based on code from PaX and grsecurity.
>>
>> Signed-off-by: Kees Cook 
>> ---
>>  init/Kconfig |  1 +
>>  mm/slub.c| 36 
>>  2 files changed, 37 insertions(+)
>>
>> diff --git a/init/Kconfig b/init/Kconfig
>> index 798c2020ee7c..1c4711819dfd 100644
>> --- a/init/Kconfig
>> +++ b/init/Kconfig
>> @@ -1765,6 +1765,7 @@ config SLAB
>>
>>  config SLUB
>>   bool "SLUB (Unqueued Allocator)"
>> + select HAVE_HARDENED_USERCOPY_ALLOCATOR
>
> Should this patch come in earlier from a build perspective? I think
> patch 1 introduces and uses __check_heap_object.

__check_heap_object in patch 1 is protected by a check for
CONFIG_HAVE_HARDENED_USERCOPY_ALLOCATOR.

It seemed better to be to do arch enablement first, and then add the
per-allocator heap object size check since it was a distinct piece.
I'm happy to rearrange things, though, if there's a good reason.

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

Re: [PATCH v2 11/11] mm: SLUB hardened usercopy support

[Kees Cook]

On Thu, Jul 14, 2016 at 7:05 PM, Balbir Singh  wrote:
> On Wed, Jul 13, 2016 at 02:56:04PM -0700, Kees Cook wrote:
>> Under CONFIG_HARDENED_USERCOPY, this adds object size checking to the
>> SLUB allocator to catch any copies that may span objects. Includes a
>> redzone handling fix from Michael Ellerman.
>>
>> Based on code from PaX and grsecurity.
>>
>> Signed-off-by: Kees Cook 
>> ---
>>  init/Kconfig |  1 +
>>  mm/slub.c| 36 
>>  2 files changed, 37 insertions(+)
>>
>> diff --git a/init/Kconfig b/init/Kconfig
>> index 798c2020ee7c..1c4711819dfd 100644
>> --- a/init/Kconfig
>> +++ b/init/Kconfig
>> @@ -1765,6 +1765,7 @@ config SLAB
>>
>>  config SLUB
>>   bool "SLUB (Unqueued Allocator)"
>> + select HAVE_HARDENED_USERCOPY_ALLOCATOR
>
> Should this patch come in earlier from a build perspective? I think
> patch 1 introduces and uses __check_heap_object.

__check_heap_object in patch 1 is protected by a check for
CONFIG_HAVE_HARDENED_USERCOPY_ALLOCATOR.

It seemed better to be to do arch enablement first, and then add the
per-allocator heap object size check since it was a distinct piece.
I'm happy to rearrange things, though, if there's a good reason.

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

Re: [PATCH -v4 2/2] printk: Add kernel parameter to control writes to /dev/kmsg

[Borislav Petkov]

On Thu, Jul 14, 2016 at 01:23:23PM -0700, Andrew Morton wrote:
> Which changes current kernel behaviour.  Can we please get some
> discussion into this changelog which justifies that decision?  What's
> the reasoning and how do we know it won't break existing stuff?

What Rostedt said and in addition, since we do offer this /dev/kmsg
facility to userspace and since userspace likes to (ab-)use it from time
to time, we're adding a controlling cmdline param which should make
everyone happy as it is a tristate.

> Please also include a description of the reasoning behind this design
> decision.

See above. It is really that simple - we want to control how it is being
logged to that interface, thus a tristate. For example, the "on" usecase
I know of is people wanting to debug systemd and they want to see *all*
output go to dmesg.

The "off" use case is for kernel people not wanting to have any
userspace lines in the logs when debugging the kernel.

The "ratelimit" being the default...

> > Signed-off-by: Borislav Petkov 
> > Cc: Andrew Morton 
> > Cc: Franck Bui 
> > Cc: Greg Kroah-Hartman 
> > Cc: Ingo Molnar 
> > Cc: Linus Torvalds 
> > Cc: Peter Zijlstra 
> > Cc: Steven Rostedt 
> > Cc: Uwe Kleine-K__nig 
> 
> Did nobody ack any of this?

I'm sure they all want this but are tired of the bikeshedding :-)

> > +   printk.devkmsg={on,off}
> > +   Control writing to /dev/kmsg.
> > +   on - unlimited logging to /dev/kmsg from userspace
> > +   off - logging to /dev/kmsg disabled
> > +   Default: ratelimited logging.
> 
> printk.devkmsg=ratelimit is undocumented?

Fixed.

> > +printk_devkmsg:
> > +
> > +Control the logging to /dev/kmsg from userspace:
> > +
> > +0: default, ratelimited
> > +1: unlimited logging to /dev/kmsg from userspace
> > +2: logging to /dev/kmsg disabled
> 
> hm.  If we're going to make this a pain old 0/1/2 then perhaps the boot
> parameter should also simply accept 0/1/2.

So my reasoning to have the string option names for the cmdline
parameter is so that you don't have to always go lookup what was what,
was 1 off or on, etc.

So actually, I should make the sysctl accept "on", "off" and "ratelimit"
instead too.

Agreed?

> > +The kernel command line parameter printk.devkmsg= overrides this and is
> > +a one-time setting until next reboot: once set, it cannot be changed by
> > +this sysctl interface anymore.
> 
> Why?

What Rostedt said.

> Please put these forward declarations near top-of-file.  Otherwise we
> can later get duplicates.

Done.

> Please enhance the comment to describe why this is being done.  The
> reasoning behind it.

I changed Rostedt's text a bit:

/*
 * Sysctl cannot change it anymore. The kernel command line setting of
 * this parameter is to force the setting to be permanent throughout the
 * runtime of the system. This is a precation measure against userspace
 * trying to be a smarta** and attempting to change it up on us.
 */

-- 
Regards/Gruss,
Boris.

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

Re: [PATCH -v4 2/2] printk: Add kernel parameter to control writes to /dev/kmsg

[Borislav Petkov]

On Thu, Jul 14, 2016 at 01:23:23PM -0700, Andrew Morton wrote:
> Which changes current kernel behaviour.  Can we please get some
> discussion into this changelog which justifies that decision?  What's
> the reasoning and how do we know it won't break existing stuff?

What Rostedt said and in addition, since we do offer this /dev/kmsg
facility to userspace and since userspace likes to (ab-)use it from time
to time, we're adding a controlling cmdline param which should make
everyone happy as it is a tristate.

> Please also include a description of the reasoning behind this design
> decision.

See above. It is really that simple - we want to control how it is being
logged to that interface, thus a tristate. For example, the "on" usecase
I know of is people wanting to debug systemd and they want to see *all*
output go to dmesg.

The "off" use case is for kernel people not wanting to have any
userspace lines in the logs when debugging the kernel.

The "ratelimit" being the default...

> > Signed-off-by: Borislav Petkov 
> > Cc: Andrew Morton 
> > Cc: Franck Bui 
> > Cc: Greg Kroah-Hartman 
> > Cc: Ingo Molnar 
> > Cc: Linus Torvalds 
> > Cc: Peter Zijlstra 
> > Cc: Steven Rostedt 
> > Cc: Uwe Kleine-K__nig 
> 
> Did nobody ack any of this?

I'm sure they all want this but are tired of the bikeshedding :-)

> > +   printk.devkmsg={on,off}
> > +   Control writing to /dev/kmsg.
> > +   on - unlimited logging to /dev/kmsg from userspace
> > +   off - logging to /dev/kmsg disabled
> > +   Default: ratelimited logging.
> 
> printk.devkmsg=ratelimit is undocumented?

Fixed.

> > +printk_devkmsg:
> > +
> > +Control the logging to /dev/kmsg from userspace:
> > +
> > +0: default, ratelimited
> > +1: unlimited logging to /dev/kmsg from userspace
> > +2: logging to /dev/kmsg disabled
> 
> hm.  If we're going to make this a pain old 0/1/2 then perhaps the boot
> parameter should also simply accept 0/1/2.

So my reasoning to have the string option names for the cmdline
parameter is so that you don't have to always go lookup what was what,
was 1 off or on, etc.

So actually, I should make the sysctl accept "on", "off" and "ratelimit"
instead too.

Agreed?

> > +The kernel command line parameter printk.devkmsg= overrides this and is
> > +a one-time setting until next reboot: once set, it cannot be changed by
> > +this sysctl interface anymore.
> 
> Why?

What Rostedt said.

> Please put these forward declarations near top-of-file.  Otherwise we
> can later get duplicates.

Done.

> Please enhance the comment to describe why this is being done.  The
> reasoning behind it.

I changed Rostedt's text a bit:

/*
 * Sysctl cannot change it anymore. The kernel command line setting of
 * this parameter is to force the setting to be permanent throughout the
 * runtime of the system. This is a precation measure against userspace
 * trying to be a smarta** and attempting to change it up on us.
 */

-- 
Regards/Gruss,
Boris.

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

Re: [PATCH v2 02/11] mm: Hardened usercopy

[Kees Cook]

On Thu, Jul 14, 2016 at 4:20 PM, Balbir Singh  wrote:
> On Wed, Jul 13, 2016 at 02:55:55PM -0700, Kees Cook wrote:
>> [...]
>> +++ b/mm/usercopy.c
>> @@ -0,0 +1,219 @@
>> [...]
>> +/*
>> + * Checks if a given pointer and length is contained by the current
>> + * stack frame (if possible).
>> + *
>> + *   0: not at all on the stack
>> + *   1: fully within a valid stack frame
>> + *   2: fully on the stack (when can't do frame-checking)
>> + *   -1: error condition (invalid stack position or bad stack frame)
>
> Can we use enums? Makes it easier to read/debug

Sure, I will update this.

>> [...]
>> +static void report_usercopy(const void *ptr, unsigned long len,
>> + bool to_user, const char *type)
>> +{
>> + pr_emerg("kernel memory %s attempt detected %s %p (%s) (%lu bytes)\n",
>> + to_user ? "exposure" : "overwrite",
>> + to_user ? "from" : "to", ptr, type ? : "unknown", len);
>> + dump_stack();
>> + do_group_exit(SIGKILL);
>
> SIGKILL -- SIGBUS?

I'd like to keep SIGKILL since it indicates a process fiddling with a
kernel bug. The real problem here is that there doesn't seem to be an
arch-independent way to Oops the kernel and kill a process ("die()" is
closest, but it's defined on a per-arch basis with varying arguments).
This could be a BUG, but I'd rather not panic the entire kernel.

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

Re: [PATCH v2 02/11] mm: Hardened usercopy

[Kees Cook]

On Thu, Jul 14, 2016 at 4:20 PM, Balbir Singh  wrote:
> On Wed, Jul 13, 2016 at 02:55:55PM -0700, Kees Cook wrote:
>> [...]
>> +++ b/mm/usercopy.c
>> @@ -0,0 +1,219 @@
>> [...]
>> +/*
>> + * Checks if a given pointer and length is contained by the current
>> + * stack frame (if possible).
>> + *
>> + *   0: not at all on the stack
>> + *   1: fully within a valid stack frame
>> + *   2: fully on the stack (when can't do frame-checking)
>> + *   -1: error condition (invalid stack position or bad stack frame)
>
> Can we use enums? Makes it easier to read/debug

Sure, I will update this.

>> [...]
>> +static void report_usercopy(const void *ptr, unsigned long len,
>> + bool to_user, const char *type)
>> +{
>> + pr_emerg("kernel memory %s attempt detected %s %p (%s) (%lu bytes)\n",
>> + to_user ? "exposure" : "overwrite",
>> + to_user ? "from" : "to", ptr, type ? : "unknown", len);
>> + dump_stack();
>> + do_group_exit(SIGKILL);
>
> SIGKILL -- SIGBUS?

I'd like to keep SIGKILL since it indicates a process fiddling with a
kernel bug. The real problem here is that there doesn't seem to be an
arch-independent way to Oops the kernel and kill a process ("die()" is
closest, but it's defined on a per-arch basis with varying arguments).
This could be a BUG, but I'd rather not panic the entire kernel.

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

Re: mmc: dwmmc: exynos: Warn if HS400 is being used on non-Exynos5420 chipset

[Alim Akhtar]

Hi Krzysztof,

On 07/14/2016 06:52 PM, Krzysztof Kozlowski wrote:

Chipsets before Exynos5420 did not support HS400 so if MMC core tries to
configure HS400 timing, this might or might not work.  Warn in such
cases because this is DTB misconfiguration.

Signed-off-by: Krzysztof Kozlowski 
---


Reviewed-by: Alim Akhtar 


  drivers/mmc/host/dw_mmc-exynos.c | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/dw_mmc-exynos.c b/drivers/mmc/host/dw_mmc-exynos.c
index da0ef1765735..7ab3d749b5ae 100644
--- a/drivers/mmc/host/dw_mmc-exynos.c
+++ b/drivers/mmc/host/dw_mmc-exynos.c
@@ -225,8 +225,12 @@ static void dw_mci_exynos_config_hs400(struct dw_mci 
*host, u32 timing)
 * Not supported to configure register
 * related to HS400
 */
-   if (priv->ctrl_type < DW_MCI_TYPE_EXYNOS5420)
+   if (priv->ctrl_type < DW_MCI_TYPE_EXYNOS5420) {
+   if (timing == MMC_TIMING_MMC_HS400)
+   dev_warn(host->dev,
+"cannot configure HS400, unsupported 
chipset\n");
return;
+   }


It is good to have extra bit of debug information handy.


dqs = priv->saved_dqs_en;
strobe = priv->saved_strobe_ctrl;

Re: mmc: dwmmc: exynos: Warn if HS400 is being used on non-Exynos5420 chipset

[Alim Akhtar]

Hi Krzysztof,

On 07/14/2016 06:52 PM, Krzysztof Kozlowski wrote:

Chipsets before Exynos5420 did not support HS400 so if MMC core tries to
configure HS400 timing, this might or might not work.  Warn in such
cases because this is DTB misconfiguration.

Signed-off-by: Krzysztof Kozlowski 
---


Reviewed-by: Alim Akhtar 


  drivers/mmc/host/dw_mmc-exynos.c | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/dw_mmc-exynos.c b/drivers/mmc/host/dw_mmc-exynos.c
index da0ef1765735..7ab3d749b5ae 100644
--- a/drivers/mmc/host/dw_mmc-exynos.c
+++ b/drivers/mmc/host/dw_mmc-exynos.c
@@ -225,8 +225,12 @@ static void dw_mci_exynos_config_hs400(struct dw_mci 
*host, u32 timing)
 * Not supported to configure register
 * related to HS400
 */
-   if (priv->ctrl_type < DW_MCI_TYPE_EXYNOS5420)
+   if (priv->ctrl_type < DW_MCI_TYPE_EXYNOS5420) {
+   if (timing == MMC_TIMING_MMC_HS400)
+   dev_warn(host->dev,
+"cannot configure HS400, unsupported 
chipset\n");
return;
+   }


It is good to have extra bit of debug information handy.


dqs = priv->saved_dqs_en;
strobe = priv->saved_strobe_ctrl;

Re: [PATCH v2 02/30] HID: wacom: store the type in wacom->shared for INTUOSHT and INTUOSHT2

[Ping Cheng]

On Wed, Jul 13, 2016 at 9:05 AM, Benjamin Tissoires
 wrote:
> The type is never set but we check for it in wacom_wireless_irq().

Type was assigned in wacom_wireless_work [1] before we moved code
around. It somehow failed to get into wacom_parse_and_register. The
value was only assigned once on stylus interface. It was unnecessary
to assign it again on touch interface since it is a shared value.
Maybe that was the reason it missed its "flight"?

[1] 
https://git.kernel.org/cgit/linux/kernel/git/dtor/input.git/commit/drivers/hid/wacom_sys.c?id=2546dacd3e0e48c40bbb99caf01455f1ade9bb24

> It looks like this is a big hack from the beginning, so fill in the gap
> only.

Yeah, wireless is a dynamic connection. We can not tell which tablet
model is going to be connected before it is paired. But, the dongle is
always the same. That's the tricky part.

> Untested.

Aaron tested it. So, your code is safe ;).

> Signed-off-by: Benjamin Tissoires 

The whole set is

Acked-by: Ping Cheng 

Thanks for your effort!

Ping

> ---
>
> No changes in v2
> ---
>  drivers/hid/wacom_sys.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c
> index 499cc82..9e283aa 100644
> --- a/drivers/hid/wacom_sys.c
> +++ b/drivers/hid/wacom_sys.c
> @@ -1720,9 +1720,10 @@ static int wacom_parse_and_register(struct wacom 
> *wacom, bool wireless)
> error = hid_hw_open(hdev);
>
> if ((wacom_wac->features.type == INTUOSHT ||
> -   wacom_wac->features.type == INTUOSHT2) &&
> +wacom_wac->features.type == INTUOSHT2) &&
> (wacom_wac->features.device_type & WACOM_DEVICETYPE_TOUCH)) {
> -   wacom_wac->shared->touch_input = 
> wacom_wac->touch_input;
> +   wacom_wac->shared->type = wacom_wac->features.type;
> +   wacom_wac->shared->touch_input = wacom_wac->touch_input;
> }
>
> return 0;
> --
> 2.5.5
>

Re: [PATCH v2 02/30] HID: wacom: store the type in wacom->shared for INTUOSHT and INTUOSHT2

[Ping Cheng]

On Wed, Jul 13, 2016 at 9:05 AM, Benjamin Tissoires
 wrote:
> The type is never set but we check for it in wacom_wireless_irq().

Type was assigned in wacom_wireless_work [1] before we moved code
around. It somehow failed to get into wacom_parse_and_register. The
value was only assigned once on stylus interface. It was unnecessary
to assign it again on touch interface since it is a shared value.
Maybe that was the reason it missed its "flight"?

[1] 
https://git.kernel.org/cgit/linux/kernel/git/dtor/input.git/commit/drivers/hid/wacom_sys.c?id=2546dacd3e0e48c40bbb99caf01455f1ade9bb24

> It looks like this is a big hack from the beginning, so fill in the gap
> only.

Yeah, wireless is a dynamic connection. We can not tell which tablet
model is going to be connected before it is paired. But, the dongle is
always the same. That's the tricky part.

> Untested.

Aaron tested it. So, your code is safe ;).

> Signed-off-by: Benjamin Tissoires 

The whole set is

Acked-by: Ping Cheng 

Thanks for your effort!

Ping

> ---
>
> No changes in v2
> ---
>  drivers/hid/wacom_sys.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c
> index 499cc82..9e283aa 100644
> --- a/drivers/hid/wacom_sys.c
> +++ b/drivers/hid/wacom_sys.c
> @@ -1720,9 +1720,10 @@ static int wacom_parse_and_register(struct wacom 
> *wacom, bool wireless)
> error = hid_hw_open(hdev);
>
> if ((wacom_wac->features.type == INTUOSHT ||
> -   wacom_wac->features.type == INTUOSHT2) &&
> +wacom_wac->features.type == INTUOSHT2) &&
> (wacom_wac->features.device_type & WACOM_DEVICETYPE_TOUCH)) {
> -   wacom_wac->shared->touch_input = 
> wacom_wac->touch_input;
> +   wacom_wac->shared->type = wacom_wac->features.type;
> +   wacom_wac->shared->touch_input = wacom_wac->touch_input;
> }
>
> return 0;
> --
> 2.5.5
>

[PATCH v4] acpi, nfit: treat virtual ramdisk SPA as pmem region

[Lee, Chun-Yi]

This patch adds logic to treat virtual ramdisk SPA as pmem region, then
ramdisk's /dev/pmem* device can be mounted with iso9660.

It's useful to work with the httpboot in EFI firmware to pull a remote
ISO file to the local memory region for booting and installation.

Wiki page of UEFI HTTPBoot with OVMF:
https://en.opensuse.org/UEFI_HTTPBoot_with_OVMF

The ramdisk function in EDK2/OVMF generates a ACPI0012 root device that
it contains empty _STA but without _DSM:

DefinitionBlock ("ssdt2.aml", "SSDT", 2, "INTEL ", "RamDisk ", 0x1000)
{
Scope (\_SB)
{
Device (NVDR)
{
Name (_HID, "ACPI0012")  // _HID: Hardware ID
Name (_STR, Unicode ("NVDIMM Root Device"))  // _STR: Description 
String
Method (_STA, 0, NotSerialized)  // _STA: Status
{
Return (0x0F)
}
}
}
}

In section 5.2.25.2 of ACPI 6.1 spec, it mentions that the "SPA Range
Structure Index" of virtual SPA shall be set to zero. That means virtual SPA
will not be associated by any NVDIMM region mapping.

The VCD's SPA Range Structure in NFIT is similar to virtual disk region
as following:

[028h 0040   2]Subtable Type :  [System Physical Address 
Range]
[02Ah 0042   2]   Length : 0038

[02Ch 0044   2]  Range Index : 
[02Eh 0046   2]Flags (decoded below) : 
   Add/Online Operation Only : 0
  Proximity Domain Valid : 0
[030h 0048   4] Reserved : 
[034h 0052   4] Proximity Domain : 
[038h 0056  16]   Address Range GUID : 
77AB535A-45FC-624B-5560-F7B281D1F96E
[048h 0072   8]   Address Range Base : B6ABD018
[050h 0080   8] Address Range Length : 0550
[058h 0088   8] Memory Map Attribute : 

The way to not associate a SPA range is to never reference it from a "flush 
hint",
"interleave", or "control region" table.

After testing on OVMF, pmem driver can support the region that it doesn't
assoicate to any NVDIMM mapping. So, treat VCD like pmem is a idea to get
a pmem block device that it contains iso. 

v4:
Instoduce nfit_spa_is_virtual() to check virtual ramdisk SPA and create
pmem region.

v3:
To simplify patch, removed useless VCD region in libnvdimm.
 
v2:
Removed the code for setting VCD to a read-only region.

Cc: Gary Lin 
Cc: Dan Williams 
Cc: Ross Zwisler 
Cc: "Rafael J. Wysocki" 
Cc: Linda Knippers 
Signed-off-by: Lee, Chun-Yi 
---
 drivers/acpi/nfit.c  |  8 +++-
 drivers/nvdimm/region_devs.c | 26 +-
 include/linux/libnvdimm.h|  2 ++
 3 files changed, 34 insertions(+), 2 deletions(-)

Index: linux/drivers/acpi/nfit.c
===
--- linux.orig/drivers/acpi/nfit.c
+++ linux/drivers/acpi/nfit.c
@@ -1980,6 +1980,14 @@ static int acpi_nfit_init_mapping(struct
return 0;
 }
 
+static bool nfit_spa_is_virtual(struct acpi_nfit_system_address *spa)
+{
+   return (nfit_spa_type(spa) == NFIT_SPA_VDISK ||
+   nfit_spa_type(spa) == NFIT_SPA_VCD   ||
+   nfit_spa_type(spa) == NFIT_SPA_PDISK ||
+   nfit_spa_type(spa) == NFIT_SPA_PCD);
+}
+
 static int acpi_nfit_register_region(struct acpi_nfit_desc *acpi_desc,
struct nfit_spa *nfit_spa)
 {
@@ -1995,7 +2003,7 @@ static int acpi_nfit_register_region(str
if (nfit_spa->nd_region)
return 0;
 
-   if (spa->range_index == 0) {
+   if (spa->range_index == 0 && !nfit_spa_is_virtual(spa)) {
dev_dbg(acpi_desc->dev, "%s: detected invalid spa index\n",
__func__);
return 0;
@@ -2059,6 +2067,11 @@ static int acpi_nfit_register_region(str
ndr_desc);
if (!nfit_spa->nd_region)
rc = -ENOMEM;
+   } else if (nfit_spa_is_virtual(spa)) {
+   nfit_spa->nd_region = nvdimm_pmem_region_create(nvdimm_bus,
+   ndr_desc);
+   if (!nfit_spa->nd_region)
+   rc = -ENOMEM;
}
 
  out:

[PATCH v4] acpi, nfit: treat virtual ramdisk SPA as pmem region

[Lee, Chun-Yi]

This patch adds logic to treat virtual ramdisk SPA as pmem region, then
ramdisk's /dev/pmem* device can be mounted with iso9660.

It's useful to work with the httpboot in EFI firmware to pull a remote
ISO file to the local memory region for booting and installation.

Wiki page of UEFI HTTPBoot with OVMF:
https://en.opensuse.org/UEFI_HTTPBoot_with_OVMF

The ramdisk function in EDK2/OVMF generates a ACPI0012 root device that
it contains empty _STA but without _DSM:

DefinitionBlock ("ssdt2.aml", "SSDT", 2, "INTEL ", "RamDisk ", 0x1000)
{
Scope (\_SB)
{
Device (NVDR)
{
Name (_HID, "ACPI0012")  // _HID: Hardware ID
Name (_STR, Unicode ("NVDIMM Root Device"))  // _STR: Description 
String
Method (_STA, 0, NotSerialized)  // _STA: Status
{
Return (0x0F)
}
}
}
}

In section 5.2.25.2 of ACPI 6.1 spec, it mentions that the "SPA Range
Structure Index" of virtual SPA shall be set to zero. That means virtual SPA
will not be associated by any NVDIMM region mapping.

The VCD's SPA Range Structure in NFIT is similar to virtual disk region
as following:

[028h 0040   2]Subtable Type :  [System Physical Address 
Range]
[02Ah 0042   2]   Length : 0038

[02Ch 0044   2]  Range Index : 
[02Eh 0046   2]Flags (decoded below) : 
   Add/Online Operation Only : 0
  Proximity Domain Valid : 0
[030h 0048   4] Reserved : 
[034h 0052   4] Proximity Domain : 
[038h 0056  16]   Address Range GUID : 
77AB535A-45FC-624B-5560-F7B281D1F96E
[048h 0072   8]   Address Range Base : B6ABD018
[050h 0080   8] Address Range Length : 0550
[058h 0088   8] Memory Map Attribute : 

The way to not associate a SPA range is to never reference it from a "flush 
hint",
"interleave", or "control region" table.

After testing on OVMF, pmem driver can support the region that it doesn't
assoicate to any NVDIMM mapping. So, treat VCD like pmem is a idea to get
a pmem block device that it contains iso. 

v4:
Instoduce nfit_spa_is_virtual() to check virtual ramdisk SPA and create
pmem region.

v3:
To simplify patch, removed useless VCD region in libnvdimm.
 
v2:
Removed the code for setting VCD to a read-only region.

Cc: Gary Lin 
Cc: Dan Williams 
Cc: Ross Zwisler 
Cc: "Rafael J. Wysocki" 
Cc: Linda Knippers 
Signed-off-by: Lee, Chun-Yi 
---
 drivers/acpi/nfit.c  |  8 +++-
 drivers/nvdimm/region_devs.c | 26 +-
 include/linux/libnvdimm.h|  2 ++
 3 files changed, 34 insertions(+), 2 deletions(-)

Index: linux/drivers/acpi/nfit.c
===
--- linux.orig/drivers/acpi/nfit.c
+++ linux/drivers/acpi/nfit.c
@@ -1980,6 +1980,14 @@ static int acpi_nfit_init_mapping(struct
return 0;
 }
 
+static bool nfit_spa_is_virtual(struct acpi_nfit_system_address *spa)
+{
+   return (nfit_spa_type(spa) == NFIT_SPA_VDISK ||
+   nfit_spa_type(spa) == NFIT_SPA_VCD   ||
+   nfit_spa_type(spa) == NFIT_SPA_PDISK ||
+   nfit_spa_type(spa) == NFIT_SPA_PCD);
+}
+
 static int acpi_nfit_register_region(struct acpi_nfit_desc *acpi_desc,
struct nfit_spa *nfit_spa)
 {
@@ -1995,7 +2003,7 @@ static int acpi_nfit_register_region(str
if (nfit_spa->nd_region)
return 0;
 
-   if (spa->range_index == 0) {
+   if (spa->range_index == 0 && !nfit_spa_is_virtual(spa)) {
dev_dbg(acpi_desc->dev, "%s: detected invalid spa index\n",
__func__);
return 0;
@@ -2059,6 +2067,11 @@ static int acpi_nfit_register_region(str
ndr_desc);
if (!nfit_spa->nd_region)
rc = -ENOMEM;
+   } else if (nfit_spa_is_virtual(spa)) {
+   nfit_spa->nd_region = nvdimm_pmem_region_create(nvdimm_bus,
+   ndr_desc);
+   if (!nfit_spa->nd_region)
+   rc = -ENOMEM;
}
 
  out:

Re: [PATCH 1/2] tpm: devicetree: document properties for cr50

[Guenter Roeck]

On Thu, Jul 14, 2016 at 7:20 PM, Andrey Pronin  wrote:
> Add TPM2.0-compatible interface to Cr50. Document its properties
> in devicetree.
>
> Signed-off-by: Andrey Pronin 
> ---
>  .../devicetree/bindings/security/tpm/cr50_spi.txt  | 30 
> ++
>  1 file changed, 30 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/security/tpm/cr50_spi.txt
>
> diff --git a/Documentation/devicetree/bindings/security/tpm/cr50_spi.txt 
> b/Documentation/devicetree/bindings/security/tpm/cr50_spi.txt
> new file mode 100644
> index 000..1b05e51
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/security/tpm/cr50_spi.txt
> @@ -0,0 +1,30 @@
> +* Cr50 Chip on SPI.
> +
> +TCG PTP FIFO Compliant Interface to Cr50 on SPI bus.
> +
> +Required properties:
> +- compatible: Should be "google,cr50_spi".

google,cr50, maybe ? The "_spi" seems redundant.

Also, I agree with comments from others - the term cr50 really needs
an explanation (Google thinks that it is a motor bike, a scanner, or a
coffee roaster).

Thanks,
Guenter

> +- spi-max-frequency: Maximum SPI frequency.
> +
> +Optional properties:
> +- access-delay-msec: Required delay between subsequent transactions on SPI.
> +- sleep-delay-msec: Time after the last SPI activity, after which the chip
> +  may go to sleep.
> +- wake-start-delay-msec: Time after initiating wake up before the chip is
> +  ready to accept commands over SPI.
> +
> +Example:
> +
> + {
> +status = "okay";
> +
> +cr50@0 {
> +compatible = "google,cr50_spi";
> +reg = <0>;
> +spi-max-frequency = <80>;
> +
> +access-delay-msec = <2>;
> +sleep-delay-msec = <1000>;
> +wake-start-delay-msec = <60>;
> +};
> +};
> --
> 2.6.6
>

Re: [PATCH 1/2] tpm: devicetree: document properties for cr50

[Guenter Roeck]

On Thu, Jul 14, 2016 at 7:20 PM, Andrey Pronin  wrote:
> Add TPM2.0-compatible interface to Cr50. Document its properties
> in devicetree.
>
> Signed-off-by: Andrey Pronin 
> ---
>  .../devicetree/bindings/security/tpm/cr50_spi.txt  | 30 
> ++
>  1 file changed, 30 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/security/tpm/cr50_spi.txt
>
> diff --git a/Documentation/devicetree/bindings/security/tpm/cr50_spi.txt 
> b/Documentation/devicetree/bindings/security/tpm/cr50_spi.txt
> new file mode 100644
> index 000..1b05e51
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/security/tpm/cr50_spi.txt
> @@ -0,0 +1,30 @@
> +* Cr50 Chip on SPI.
> +
> +TCG PTP FIFO Compliant Interface to Cr50 on SPI bus.
> +
> +Required properties:
> +- compatible: Should be "google,cr50_spi".

google,cr50, maybe ? The "_spi" seems redundant.

Also, I agree with comments from others - the term cr50 really needs
an explanation (Google thinks that it is a motor bike, a scanner, or a
coffee roaster).

Thanks,
Guenter

> +- spi-max-frequency: Maximum SPI frequency.
> +
> +Optional properties:
> +- access-delay-msec: Required delay between subsequent transactions on SPI.
> +- sleep-delay-msec: Time after the last SPI activity, after which the chip
> +  may go to sleep.
> +- wake-start-delay-msec: Time after initiating wake up before the chip is
> +  ready to accept commands over SPI.
> +
> +Example:
> +
> + {
> +status = "okay";
> +
> +cr50@0 {
> +compatible = "google,cr50_spi";
> +reg = <0>;
> +spi-max-frequency = <80>;
> +
> +access-delay-msec = <2>;
> +sleep-delay-msec = <1000>;
> +wake-start-delay-msec = <60>;
> +};
> +};
> --
> 2.6.6
>

Re: [PATCH v2 02/11] mm: Hardened usercopy

[Kees Cook]

On Thu, Jul 14, 2016 at 6:41 PM, Balbir Singh  wrote:
> On Thu, Jul 14, 2016 at 09:04:18PM -0400, Rik van Riel wrote:
>> On Fri, 2016-07-15 at 09:20 +1000, Balbir Singh wrote:
>>
>> > > ==
>> > > +((unsigned long)end & (unsigned
>> > > long)PAGE_MASK)))
>> > > + return NULL;
>> > > +
>> > > + /* Allow if start and end are inside the same compound
>> > > page. */
>> > > + endpage = virt_to_head_page(end);
>> > > + if (likely(endpage == page))
>> > > + return NULL;
>> > > +
>> > > + /* Allow special areas, device memory, and sometimes
>> > > kernel data. */
>> > > + if (PageReserved(page) && PageReserved(endpage))
>> > > + return NULL;
>> >
>> > If we came here, it's likely that endpage > page, do we need to check
>> > that only the first and last pages are reserved? What about the ones
>> > in
>> > the middle?
>>
>> I think this will be so rare, we can get away with just
>> checking the beginning and the end.
>>
>
> But do we want to leave a hole where an aware user space
> can try a longer copy_* to avoid this check? If it is unlikely
> should we just bite the bullet and do the check for the entire
> range?

I'd be okay with expanding the test -- it should be an extremely rare
situation already since the common Reserved areas (kernel data) will
have already been explicitly tested.

What's the best way to do "next page"? Should it just be:

for ( ; page <= endpage ; ptr += PAGE_SIZE, page = virt_to_head_page(ptr) ) {
if (!PageReserved(page))
return "";
}

return NULL;

?


-- 
Kees Cook
Chrome OS & Brillo Security

Re: [PATCH v2 02/11] mm: Hardened usercopy

[Kees Cook]

On Thu, Jul 14, 2016 at 6:41 PM, Balbir Singh  wrote:
> On Thu, Jul 14, 2016 at 09:04:18PM -0400, Rik van Riel wrote:
>> On Fri, 2016-07-15 at 09:20 +1000, Balbir Singh wrote:
>>
>> > > ==
>> > > +((unsigned long)end & (unsigned
>> > > long)PAGE_MASK)))
>> > > + return NULL;
>> > > +
>> > > + /* Allow if start and end are inside the same compound
>> > > page. */
>> > > + endpage = virt_to_head_page(end);
>> > > + if (likely(endpage == page))
>> > > + return NULL;
>> > > +
>> > > + /* Allow special areas, device memory, and sometimes
>> > > kernel data. */
>> > > + if (PageReserved(page) && PageReserved(endpage))
>> > > + return NULL;
>> >
>> > If we came here, it's likely that endpage > page, do we need to check
>> > that only the first and last pages are reserved? What about the ones
>> > in
>> > the middle?
>>
>> I think this will be so rare, we can get away with just
>> checking the beginning and the end.
>>
>
> But do we want to leave a hole where an aware user space
> can try a longer copy_* to avoid this check? If it is unlikely
> should we just bite the bullet and do the check for the entire
> range?

I'd be okay with expanding the test -- it should be an extremely rare
situation already since the common Reserved areas (kernel data) will
have already been explicitly tested.

What's the best way to do "next page"? Should it just be:

for ( ; page <= endpage ; ptr += PAGE_SIZE, page = virt_to_head_page(ptr) ) {
if (!PageReserved(page))
return "";
}

return NULL;

?


-- 
Kees Cook
Chrome OS & Brillo Security

Re: [PATCH -v4 1/2] ratelimit: Extend to print suppressed messages on release

[Borislav Petkov]

Hi Andrew,

thanks for taking a look.

On Thu, Jul 14, 2016 at 01:29:36PM -0700, Andrew Morton wrote:
> Why?  What's driving this?  What are the benefits to our users?  Are
> there any downsides or back-compatibility issues?
> 
> I see from the code that this is not actually enabled by default.  The
> client code must use ratelimit_set_flags() to select this behaviour,
> and the second patch uses this.  Please include all such info in the
> changelog.

How about:

"This use case is aimed at short-termed, burst-like users of the
ratelimiting facility for which we want to output the suppressed lines
stats only once, after it has been disposed of. For an example, see
usage in /dev/kmsg."

?

> > Separated from a previous patch by Linus.
> > 
> > Also, make the ON_RELEASE image not use "callbacks" as it is misleading.
> 
> "image"?

Bah, it should say

"Also, change the printk line we issue on release to not use "callbacks"
as it is misleading. We're not suppressing callbacks but printk calls."

> > @@ -46,12 +46,14 @@ int ___ratelimit(struct ratelimit_state *rs, const char 
> > *func)
> > rs->begin = jiffies;
> >  
> > if (time_is_before_jiffies(rs->begin + rs->interval)) {
> > -   if (rs->missed)
> > -   printk(KERN_WARNING "%s: %d callbacks suppressed\n",
> > -   func, rs->missed);
> > +   if (rs->missed) {
> > +   if (!(rs->flags & RATELIMIT_MSG_ON_RELEASE)) {
> > +   pr_warn("%s: %d callbacks suppressed\n", func, 
> > rs->missed);
> > +   rs->missed = 0;
> > +   }
> > +   }
> 
> hm, what's the difference between an output line being suppressed and a
> callback being suppressed?  I think I've forgotten how this code works ;)

Right, ___ratelimit() gets as @func arg the name of the current calling
function:

#define __ratelimit(state) ___ratelimit(state, __func__)

I'm strongly assuming this is the "callback" ___ratelimit() is talking
about :-)

In our case, we don't have callbacks but /dev/kmsg users and I thought
the most generic way of referring to them would be by not doing so at
all but simply talking about output lines being suppressed.

-- 
Regards/Gruss,
Boris.

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

Re: [PATCH -v4 1/2] ratelimit: Extend to print suppressed messages on release

[Borislav Petkov]

Hi Andrew,

thanks for taking a look.

On Thu, Jul 14, 2016 at 01:29:36PM -0700, Andrew Morton wrote:
> Why?  What's driving this?  What are the benefits to our users?  Are
> there any downsides or back-compatibility issues?
> 
> I see from the code that this is not actually enabled by default.  The
> client code must use ratelimit_set_flags() to select this behaviour,
> and the second patch uses this.  Please include all such info in the
> changelog.

How about:

"This use case is aimed at short-termed, burst-like users of the
ratelimiting facility for which we want to output the suppressed lines
stats only once, after it has been disposed of. For an example, see
usage in /dev/kmsg."

?

> > Separated from a previous patch by Linus.
> > 
> > Also, make the ON_RELEASE image not use "callbacks" as it is misleading.
> 
> "image"?

Bah, it should say

"Also, change the printk line we issue on release to not use "callbacks"
as it is misleading. We're not suppressing callbacks but printk calls."

> > @@ -46,12 +46,14 @@ int ___ratelimit(struct ratelimit_state *rs, const char 
> > *func)
> > rs->begin = jiffies;
> >  
> > if (time_is_before_jiffies(rs->begin + rs->interval)) {
> > -   if (rs->missed)
> > -   printk(KERN_WARNING "%s: %d callbacks suppressed\n",
> > -   func, rs->missed);
> > +   if (rs->missed) {
> > +   if (!(rs->flags & RATELIMIT_MSG_ON_RELEASE)) {
> > +   pr_warn("%s: %d callbacks suppressed\n", func, 
> > rs->missed);
> > +   rs->missed = 0;
> > +   }
> > +   }
> 
> hm, what's the difference between an output line being suppressed and a
> callback being suppressed?  I think I've forgotten how this code works ;)

Right, ___ratelimit() gets as @func arg the name of the current calling
function:

#define __ratelimit(state) ___ratelimit(state, __func__)

I'm strongly assuming this is the "callback" ___ratelimit() is talking
about :-)

In our case, we don't have callbacks but /dev/kmsg users and I thought
the most generic way of referring to them would be by not doing so at
all but simply talking about output lines being suppressed.

-- 
Regards/Gruss,
Boris.

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

Re: [PATCH 1/2] tpm_tis_core: add optional max xfer size check

[Guenter Roeck]

On Thu, Jul 14, 2016 at 8:25 PM, Andrey Pronin  wrote:
> On Thu, Jul 14, 2016 at 09:13:51PM -0600, Jason Gunthorpe wrote:
>> On Thu, Jul 14, 2016 at 06:39:04PM -0700, Andrey Pronin wrote:
>>
>> > +static inline u16 tpm_tis_max_xfer_size(struct tpm_tis_data *data)
>> > +{
>> > +   return data->phy_ops->max_xfer_size;
>> > +}
>> > +
>> > +static inline bool tpm_tis_burstcnt_is_valid(struct tpm_tis_data *data,
>> > +u16 burstcnt)
>> > +{
>> > +   return (tpm_tis_max_xfer_size(data) == 0)
>> > +   || (burstcnt <= tpm_tis_max_xfer_size(data));
>> > +}
>>
>> We don't need these accessors, just open code it in the one call
>> site. That is more clear as the ==0 case is important to understand
>> that the flow is correct.
>>
>> BTW, I dodn't think || as the start of a line was cannonical kernel
>> style.. Did checkpatch accept that?
>>
>> Jason
>
> You mean completely open code it inside get_burstcount()? Will do.
> checkpatch.pl had no problems with it, but I can move it to the end
> of the line, if it feels better.
>

I would suggest to use checkpatch --strict; it will tell you. It will
also ask you to align continuation lines with '(' on the previous
line. On that, I would suggest to follow the style used in the file(s)
you are working on (or follow guidance from the maintainer).

Thanks,
Guenter

Re: [PATCH 1/2] tpm_tis_core: add optional max xfer size check

[Guenter Roeck]

On Thu, Jul 14, 2016 at 8:25 PM, Andrey Pronin  wrote:
> On Thu, Jul 14, 2016 at 09:13:51PM -0600, Jason Gunthorpe wrote:
>> On Thu, Jul 14, 2016 at 06:39:04PM -0700, Andrey Pronin wrote:
>>
>> > +static inline u16 tpm_tis_max_xfer_size(struct tpm_tis_data *data)
>> > +{
>> > +   return data->phy_ops->max_xfer_size;
>> > +}
>> > +
>> > +static inline bool tpm_tis_burstcnt_is_valid(struct tpm_tis_data *data,
>> > +u16 burstcnt)
>> > +{
>> > +   return (tpm_tis_max_xfer_size(data) == 0)
>> > +   || (burstcnt <= tpm_tis_max_xfer_size(data));
>> > +}
>>
>> We don't need these accessors, just open code it in the one call
>> site. That is more clear as the ==0 case is important to understand
>> that the flow is correct.
>>
>> BTW, I dodn't think || as the start of a line was cannonical kernel
>> style.. Did checkpatch accept that?
>>
>> Jason
>
> You mean completely open code it inside get_burstcount()? Will do.
> checkpatch.pl had no problems with it, but I can move it to the end
> of the line, if it feels better.
>

I would suggest to use checkpatch --strict; it will tell you. It will
also ask you to align continuation lines with '(' on the previous
line. On that, I would suggest to follow the style used in the file(s)
you are working on (or follow guidance from the maintainer).

Thanks,
Guenter

Re: [PATCH 2/2] tpm: add driver for cr50 on SPI

[Andrey Pronin]

On Thu, Jul 14, 2016 at 09:32:36PM -0600, Jason Gunthorpe wrote:
> On Thu, Jul 14, 2016 at 07:20:18PM -0700, Andrey Pronin wrote:
> 
> > +static int cr50_spi_read16(struct tpm_tis_data *data, u32 addr, u16 
> > *result)
> > +{
> > +   int rc;
> > +
> > +   rc = data->phy_ops->read_bytes(data, addr, sizeof(u16), (u8 *)result);
> > +   if (!rc)
> > +   *result = le16_to_cpu(*result);
> > +   return rc;
> > +}
> 
> I thought we had core support for this pattern?
> 
> Christophe ?
> 
> Please change this so this code isn't duplicated.
> 
> Jason
>
Hmm, didn't see the support. Would be great if there is.
The pattern itself is copied from tpm_tis_spi as is.
read_bytes/write_bytes were de-dup'ed as they used a lot of common code
(even more for this driver than for tpm_tis_spi).
But as for _readNN/_writeNN, there're only three of these functions,
so it din't seem too bad.

Re: [PATCH 2/2] tpm: add driver for cr50 on SPI

[Andrey Pronin]

On Thu, Jul 14, 2016 at 09:32:36PM -0600, Jason Gunthorpe wrote:
> On Thu, Jul 14, 2016 at 07:20:18PM -0700, Andrey Pronin wrote:
> 
> > +static int cr50_spi_read16(struct tpm_tis_data *data, u32 addr, u16 
> > *result)
> > +{
> > +   int rc;
> > +
> > +   rc = data->phy_ops->read_bytes(data, addr, sizeof(u16), (u8 *)result);
> > +   if (!rc)
> > +   *result = le16_to_cpu(*result);
> > +   return rc;
> > +}
> 
> I thought we had core support for this pattern?
> 
> Christophe ?
> 
> Please change this so this code isn't duplicated.
> 
> Jason
>
Hmm, didn't see the support. Would be great if there is.
The pattern itself is copied from tpm_tis_spi as is.
read_bytes/write_bytes were de-dup'ed as they used a lot of common code
(even more for this driver than for tpm_tis_spi).
But as for _readNN/_writeNN, there're only three of these functions,
so it din't seem too bad.

Re: [PATCH 2/2] tpm: support driver-specific sysfs attrs in tpm_tis_core

[Andrey Pronin]

On Thu, Jul 14, 2016 at 09:23:27PM -0600, Jason Gunthorpe wrote:
> On Thu, Jul 14, 2016 at 06:51:36PM -0700, Andrey Pronin wrote:
> > -   WARN_ON(chip->groups_cnt != 0);
> 
> Nope.
> 
> > -   const struct attribute_group *groups[3];
> > +   /* up to 4 attribute groups:
> > +* - driver-specific
> > +* - common TPM1.2 and TPM2.0
> > +* - TPM1.2/2.0-specific
> > +* - ppi
> > +*/
> > +   const struct attribute_group *groups[5];
> 
> The prior patch needed to have groups[4], every patch much work.
> 
> > +   if (priv->phy_ops->attr_group)
> > +   chip->groups[chip->groups_cnt++] = priv->phy_ops->attr_group;
> 
> I am really not excited about having driver specific sysfs
> files.
> 
> What is the justification for this?
> 
> Jason

Justification: give access to vendor-specific properties that are
specific to a particular chip and its registers.

Andrey

Re: [PATCH 2/2] tpm: support driver-specific sysfs attrs in tpm_tis_core

[Andrey Pronin]

On Thu, Jul 14, 2016 at 09:23:27PM -0600, Jason Gunthorpe wrote:
> On Thu, Jul 14, 2016 at 06:51:36PM -0700, Andrey Pronin wrote:
> > -   WARN_ON(chip->groups_cnt != 0);
> 
> Nope.
> 
> > -   const struct attribute_group *groups[3];
> > +   /* up to 4 attribute groups:
> > +* - driver-specific
> > +* - common TPM1.2 and TPM2.0
> > +* - TPM1.2/2.0-specific
> > +* - ppi
> > +*/
> > +   const struct attribute_group *groups[5];
> 
> The prior patch needed to have groups[4], every patch much work.
> 
> > +   if (priv->phy_ops->attr_group)
> > +   chip->groups[chip->groups_cnt++] = priv->phy_ops->attr_group;
> 
> I am really not excited about having driver specific sysfs
> files.
> 
> What is the justification for this?
> 
> Jason

Justification: give access to vendor-specific properties that are
specific to a particular chip and its registers.

Andrey

Re: [PATCH 1/2] tpm: add sysfs attributes for tpm2

[Jason Gunthorpe]

On Thu, Jul 14, 2016 at 08:32:01PM -0700, Andrey Pronin wrote:

> tpm2 shares some of the attributes with tpm1 (e.g. timeouts). Do I still
> just add those separately for tpm2 to groups[1] and keep groups[0] empty?

I think so. Since the file never exists for tpm2, nothing coded for
tpm2 will ever look in the old location.

Jason

Re: [PATCH 1/2] tpm: add sysfs attributes for tpm2

[Jason Gunthorpe]

On Thu, Jul 14, 2016 at 08:32:01PM -0700, Andrey Pronin wrote:

> tpm2 shares some of the attributes with tpm1 (e.g. timeouts). Do I still
> just add those separately for tpm2 to groups[1] and keep groups[0] empty?

I think so. Since the file never exists for tpm2, nothing coded for
tpm2 will ever look in the old location.

Jason

[PATCH] staging/lustre/llite: Close atomic_open race with several openers

[Oleg Drokin]

Right now, if it's an open of a negative dentry, a race is possible
with several openers who all try to instantiate/rehash the same
dentry and would hit a BUG_ON in d_add.
But in fact if we got a negative dentry in atomic_open, that means
we just revalidated it so no point in talking to MDS at all,
just return ENOENT and make the race go away completely.

Signed-off-by: Oleg Drokin 
---
This problem was introduced during current development cycle, with
parallel openers now possible for non-creates due to vfs changes,
so it would be great if this could go into Linus' tree separatel
in time for 4.7

 drivers/staging/lustre/lustre/llite/namei.c | 43 -
 1 file changed, 24 insertions(+), 19 deletions(-)

diff --git a/drivers/staging/lustre/lustre/llite/namei.c 
b/drivers/staging/lustre/lustre/llite/namei.c
index 3664bfd..2c4dc69 100644
--- a/drivers/staging/lustre/lustre/llite/namei.c
+++ b/drivers/staging/lustre/lustre/llite/namei.c
@@ -388,6 +388,7 @@ static int ll_lookup_it_finish(struct ptlrpc_request 
*request,
struct inode *inode = NULL;
__u64 bits = 0;
int rc = 0;
+   struct dentry *alias;
 
/* NB 1 request reference will be taken away by ll_intent_lock()
 * when I return
@@ -412,26 +413,12 @@ static int ll_lookup_it_finish(struct ptlrpc_request 
*request,
 */
}
 
-   /* Only hash *de if it is unhashed (new dentry).
-* Atoimc_open may passing hashed dentries for open.
-*/
-   if (d_unhashed(*de)) {
-   struct dentry *alias;
-
-   alias = ll_splice_alias(inode, *de);
-   if (IS_ERR(alias)) {
-   rc = PTR_ERR(alias);
-   goto out;
-   }
-   *de = alias;
-   } else if (!it_disposition(it, DISP_LOOKUP_NEG)  &&
-  !it_disposition(it, DISP_OPEN_CREATE)) {
-   /* With DISP_OPEN_CREATE dentry will be
-* instantiated in ll_create_it.
-*/
-   LASSERT(!d_inode(*de));
-   d_instantiate(*de, inode);
+   alias = ll_splice_alias(inode, *de);
+   if (IS_ERR(alias)) {
+   rc = PTR_ERR(alias);
+   goto out;
}
+   *de = alias;
 
if (!it_disposition(it, DISP_LOOKUP_NEG)) {
/* we have lookup look - unhide dentry */
@@ -587,6 +574,24 @@ static int ll_atomic_open(struct inode *dir, struct dentry 
*dentry,
   dentry, PFID(ll_inode2fid(dir)), dir, file, open_flags, mode,
   *opened);
 
+   /* Only negative dentries enter here */
+   LASSERT(!d_inode(dentry));
+
+   if (!d_in_lookup(dentry)) {
+   /* A valid negative dentry that just passed revalidation,
+* there's little point to try and open it server-side,
+* even though there's a minuscle chance it might succeed.
+* Either way it's a valid race to just return -ENOENT here.
+*/
+   if (!(open_flags & O_CREAT))
+   return -ENOENT;
+
+   /* Otherwise we just unhash it to be rehashed afresh via
+* lookup if necessary
+*/
+   d_drop(dentry);
+   }
+
it = kzalloc(sizeof(*it), GFP_NOFS);
if (!it)
return -ENOMEM;
-- 
2.7.4

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

[Stephen Rothwell]

Hi Dave,

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

In file included from drivers/gpu/drm/i915/intel_opregion.c:34:0:
drivers/gpu/drm/i915/intel_opregion.c: In function 
'intel_opregion_get_panel_type':
drivers/gpu/drm/i915/intel_opregion.c:1042:17: error: 'dev' undeclared (first 
use in this function)
  if (IS_SKYLAKE(dev)) {
 ^
drivers/gpu/drm/i915/i915_drv.h:2603:43: note: in definition of macro '__I915__'
  if (__builtin_types_compatible_p(typeof(*p), struct drm_i915_private)) \
   ^
drivers/gpu/drm/i915/i915_drv.h:2670:26: note: in expansion of macro 
'INTEL_INFO'
 #define IS_SKYLAKE(dev) (INTEL_INFO(dev)->is_skylake)
  ^
drivers/gpu/drm/i915/intel_opregion.c:1042:6: note: in expansion of macro 
'IS_SKYLAKE'
  if (IS_SKYLAKE(dev)) {
  ^
drivers/gpu/drm/i915/intel_opregion.c:1042:17: note: each undeclared identifier 
is reported only once for each function it appears in
  if (IS_SKYLAKE(dev)) {
 ^
drivers/gpu/drm/i915/i915_drv.h:2603:43: note: in definition of macro '__I915__'
  if (__builtin_types_compatible_p(typeof(*p), struct drm_i915_private)) \
   ^
drivers/gpu/drm/i915/i915_drv.h:2670:26: note: in expansion of macro 
'INTEL_INFO'
 #define IS_SKYLAKE(dev) (INTEL_INFO(dev)->is_skylake)
  ^
drivers/gpu/drm/i915/intel_opregion.c:1042:6: note: in expansion of macro 
'IS_SKYLAKE'
  if (IS_SKYLAKE(dev)) {
  ^

Caused by commit

  6f9f4b7a2cf7 ("drm/i915/opregion: Convert to using native drm_i915_private")

interacting with commit

  aeddda06c1a7 ("drm/i915: Ignore panel type from OpRegion on SKL")

from the drm-intel-fixes tree.

I applied this merge fix patch:

From: Stephen Rothwell 
Date: Fri, 15 Jul 2016 13:34:05 +1000
Subject: [PATCH] drm/i915/opregion: fix up for argument change

Signed-off-by: Stephen Rothwell 
---
 drivers/gpu/drm/i915/intel_opregion.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_opregion.c 
b/drivers/gpu/drm/i915/intel_opregion.c
index 21f19641e33e..dcdb346b596c 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -1039,7 +1039,7 @@ intel_opregion_get_panel_type(struct drm_i915_private 
*dev_priv)
 * vswing instead. Low vswing results in some display flickers, so
 * let's simply ignore the OpRegion panel type on SKL for now.
 */
-   if (IS_SKYLAKE(dev)) {
+   if (IS_SKYLAKE(dev_priv)) {
DRM_DEBUG_KMS("Ignoring OpRegion panel type (%d)\n", ret - 1);
return -ENODEV;
}
-- 
2.8.1

-- 
Cheers,
Stephen Rothwell

[PATCH] staging/lustre/llite: Close atomic_open race with several openers

[Oleg Drokin]

Right now, if it's an open of a negative dentry, a race is possible
with several openers who all try to instantiate/rehash the same
dentry and would hit a BUG_ON in d_add.
But in fact if we got a negative dentry in atomic_open, that means
we just revalidated it so no point in talking to MDS at all,
just return ENOENT and make the race go away completely.

Signed-off-by: Oleg Drokin 
---
This problem was introduced during current development cycle, with
parallel openers now possible for non-creates due to vfs changes,
so it would be great if this could go into Linus' tree separatel
in time for 4.7

 drivers/staging/lustre/lustre/llite/namei.c | 43 -
 1 file changed, 24 insertions(+), 19 deletions(-)

diff --git a/drivers/staging/lustre/lustre/llite/namei.c 
b/drivers/staging/lustre/lustre/llite/namei.c
index 3664bfd..2c4dc69 100644
--- a/drivers/staging/lustre/lustre/llite/namei.c
+++ b/drivers/staging/lustre/lustre/llite/namei.c
@@ -388,6 +388,7 @@ static int ll_lookup_it_finish(struct ptlrpc_request 
*request,
struct inode *inode = NULL;
__u64 bits = 0;
int rc = 0;
+   struct dentry *alias;
 
/* NB 1 request reference will be taken away by ll_intent_lock()
 * when I return
@@ -412,26 +413,12 @@ static int ll_lookup_it_finish(struct ptlrpc_request 
*request,
 */
}
 
-   /* Only hash *de if it is unhashed (new dentry).
-* Atoimc_open may passing hashed dentries for open.
-*/
-   if (d_unhashed(*de)) {
-   struct dentry *alias;
-
-   alias = ll_splice_alias(inode, *de);
-   if (IS_ERR(alias)) {
-   rc = PTR_ERR(alias);
-   goto out;
-   }
-   *de = alias;
-   } else if (!it_disposition(it, DISP_LOOKUP_NEG)  &&
-  !it_disposition(it, DISP_OPEN_CREATE)) {
-   /* With DISP_OPEN_CREATE dentry will be
-* instantiated in ll_create_it.
-*/
-   LASSERT(!d_inode(*de));
-   d_instantiate(*de, inode);
+   alias = ll_splice_alias(inode, *de);
+   if (IS_ERR(alias)) {
+   rc = PTR_ERR(alias);
+   goto out;
}
+   *de = alias;
 
if (!it_disposition(it, DISP_LOOKUP_NEG)) {
/* we have lookup look - unhide dentry */
@@ -587,6 +574,24 @@ static int ll_atomic_open(struct inode *dir, struct dentry 
*dentry,
   dentry, PFID(ll_inode2fid(dir)), dir, file, open_flags, mode,
   *opened);
 
+   /* Only negative dentries enter here */
+   LASSERT(!d_inode(dentry));
+
+   if (!d_in_lookup(dentry)) {
+   /* A valid negative dentry that just passed revalidation,
+* there's little point to try and open it server-side,
+* even though there's a minuscle chance it might succeed.
+* Either way it's a valid race to just return -ENOENT here.
+*/
+   if (!(open_flags & O_CREAT))
+   return -ENOENT;
+
+   /* Otherwise we just unhash it to be rehashed afresh via
+* lookup if necessary
+*/
+   d_drop(dentry);
+   }
+
it = kzalloc(sizeof(*it), GFP_NOFS);
if (!it)
return -ENOMEM;
-- 
2.7.4

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

[Stephen Rothwell]

Hi Dave,

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

In file included from drivers/gpu/drm/i915/intel_opregion.c:34:0:
drivers/gpu/drm/i915/intel_opregion.c: In function 
'intel_opregion_get_panel_type':
drivers/gpu/drm/i915/intel_opregion.c:1042:17: error: 'dev' undeclared (first 
use in this function)
  if (IS_SKYLAKE(dev)) {
 ^
drivers/gpu/drm/i915/i915_drv.h:2603:43: note: in definition of macro '__I915__'
  if (__builtin_types_compatible_p(typeof(*p), struct drm_i915_private)) \
   ^
drivers/gpu/drm/i915/i915_drv.h:2670:26: note: in expansion of macro 
'INTEL_INFO'
 #define IS_SKYLAKE(dev) (INTEL_INFO(dev)->is_skylake)
  ^
drivers/gpu/drm/i915/intel_opregion.c:1042:6: note: in expansion of macro 
'IS_SKYLAKE'
  if (IS_SKYLAKE(dev)) {
  ^
drivers/gpu/drm/i915/intel_opregion.c:1042:17: note: each undeclared identifier 
is reported only once for each function it appears in
  if (IS_SKYLAKE(dev)) {
 ^
drivers/gpu/drm/i915/i915_drv.h:2603:43: note: in definition of macro '__I915__'
  if (__builtin_types_compatible_p(typeof(*p), struct drm_i915_private)) \
   ^
drivers/gpu/drm/i915/i915_drv.h:2670:26: note: in expansion of macro 
'INTEL_INFO'
 #define IS_SKYLAKE(dev) (INTEL_INFO(dev)->is_skylake)
  ^
drivers/gpu/drm/i915/intel_opregion.c:1042:6: note: in expansion of macro 
'IS_SKYLAKE'
  if (IS_SKYLAKE(dev)) {
  ^

Caused by commit

  6f9f4b7a2cf7 ("drm/i915/opregion: Convert to using native drm_i915_private")

interacting with commit

  aeddda06c1a7 ("drm/i915: Ignore panel type from OpRegion on SKL")

from the drm-intel-fixes tree.

I applied this merge fix patch:

From: Stephen Rothwell 
Date: Fri, 15 Jul 2016 13:34:05 +1000
Subject: [PATCH] drm/i915/opregion: fix up for argument change

Signed-off-by: Stephen Rothwell 
---
 drivers/gpu/drm/i915/intel_opregion.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_opregion.c 
b/drivers/gpu/drm/i915/intel_opregion.c
index 21f19641e33e..dcdb346b596c 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -1039,7 +1039,7 @@ intel_opregion_get_panel_type(struct drm_i915_private 
*dev_priv)
 * vswing instead. Low vswing results in some display flickers, so
 * let's simply ignore the OpRegion panel type on SKL for now.
 */
-   if (IS_SKYLAKE(dev)) {
+   if (IS_SKYLAKE(dev_priv)) {
DRM_DEBUG_KMS("Ignoring OpRegion panel type (%d)\n", ret - 1);
return -ENODEV;
}
-- 
2.8.1

-- 
Cheers,
Stephen Rothwell

Re: [PATCH 2/2] tpm: fix byte-order for the value read by tpm2_get_tpm_pt

[Jason Gunthorpe]

On Thu, Jul 14, 2016 at 08:17:01PM -0700, Andrey Pronin wrote:
> conversion. The only place tpm2_get_tpm_pt() was used before was in
> tpm2_gen_interrupt, which discarded the result. So, nobody noticed,
> I guess.

If you have a moment can you run sparse on this file before/after this
change and make sure it did complain and that there are not other
endian errors?

Jason

Re: [PATCH 2/2] tpm: fix byte-order for the value read by tpm2_get_tpm_pt

[Jason Gunthorpe]

On Thu, Jul 14, 2016 at 08:17:01PM -0700, Andrey Pronin wrote:
> conversion. The only place tpm2_get_tpm_pt() was used before was in
> tpm2_gen_interrupt, which discarded the result. So, nobody noticed,
> I guess.

If you have a moment can you run sparse on this file before/after this
change and make sure it did complain and that there are not other
endian errors?

Jason

Re: [PATCH 2/2] tpm: add driver for cr50 on SPI

[Jason Gunthorpe]

On Thu, Jul 14, 2016 at 07:20:18PM -0700, Andrey Pronin wrote:

> +static int cr50_spi_read16(struct tpm_tis_data *data, u32 addr, u16 *result)
> +{
> + int rc;
> +
> + rc = data->phy_ops->read_bytes(data, addr, sizeof(u16), (u8 *)result);
> + if (!rc)
> + *result = le16_to_cpu(*result);
> + return rc;
> +}

I thought we had core support for this pattern?

Christophe ?

Please change this so this code isn't duplicated.

Jason

Re: [PATCH 2/2] tpm: add driver for cr50 on SPI

[Jason Gunthorpe]

On Thu, Jul 14, 2016 at 07:20:18PM -0700, Andrey Pronin wrote:

> +static int cr50_spi_read16(struct tpm_tis_data *data, u32 addr, u16 *result)
> +{
> + int rc;
> +
> + rc = data->phy_ops->read_bytes(data, addr, sizeof(u16), (u8 *)result);
> + if (!rc)
> + *result = le16_to_cpu(*result);
> + return rc;
> +}

I thought we had core support for this pattern?

Christophe ?

Please change this so this code isn't duplicated.

Jason

Re: [PATCH 1/2] tpm: add sysfs attributes for tpm2

[Andrey Pronin]

On Thu, Jul 14, 2016 at 09:21:45PM -0600, Jason Gunthorpe wrote:
> On Thu, Jul 14, 2016 at 06:51:35PM -0700, Andrey Pronin wrote:
> > -   sysfs_remove_link(>dev.parent->kobj, "ppi");
> > -
> > -   for (i = chip->groups[0]->attrs; *i != NULL; ++i)
> > -   sysfs_remove_link(>dev.parent->kobj, (*i)->name);
> > +   for (ngrp = 0; ngrp < chip->groups_cnt; ++ngrp) {
> > +   if (chip->groups[ngrp]->name) {
> > +   sysfs_remove_link(>dev.parent->kobj,
> > + chip->groups[ngrp]->name);
> > +   } else {
> > +   for (i = chip->groups[ngrp]->attrs; *i != NULL; ++i)
> > +   sysfs_remove_link(>dev.parent->kobj,
> > + (*i)->name);
> > +   }
> > +   }
> 
> NAK
> 
> No new compat symlinks. Only the existing set of links are permitted.
> 
> Any new sysfs entries must use only the new location.
> 
> > +static struct attribute *tpm2_dev_attrs[] = {
> > NULL,
> >  };
> 
> > +static const struct attribute_group tpm2_dev_group = {
> > +   .attrs = tpm2_dev_attrs,
> > +};
> 
> Don't add dead code, add this and related in the patch that requires it.
> 
> >  void tpm_sysfs_add_device(struct tpm_chip *chip)
> >  {
> > /* The sysfs routines rely on an implicit tpm_try_get_ops, device_del
> > @@ -290,4 +306,8 @@ void tpm_sysfs_add_device(struct tpm_chip *chip)
> >  */
> > WARN_ON(chip->groups_cnt != 0);
> > chip->groups[chip->groups_cnt++] = _dev_group;
> > +   if (chip->flags & TPM_CHIP_FLAG_TPM2)
> > +   chip->groups[chip->groups_cnt++] = _dev_group;
> > +   else
> > +   chip->groups[chip->groups_cnt++] = _dev_group;
> 
> .. and this can't really happen either..
> 
> To make things simple you can just have tpm2 not ever create any links
> for any files by never using groups[0]. There is no need to try and
> create a shared 'tpm_dev_group'.
> 
> Jason

Hi Jason,

Mostly understood. One question.

tpm2 shares some of the attributes with tpm1 (e.g. timeouts). Do I still
just add those separately for tpm2 to groups[1] and keep groups[0] empty?

Andrey

Re: [PATCH 1/2] tpm: add sysfs attributes for tpm2

[Andrey Pronin]

On Thu, Jul 14, 2016 at 09:21:45PM -0600, Jason Gunthorpe wrote:
> On Thu, Jul 14, 2016 at 06:51:35PM -0700, Andrey Pronin wrote:
> > -   sysfs_remove_link(>dev.parent->kobj, "ppi");
> > -
> > -   for (i = chip->groups[0]->attrs; *i != NULL; ++i)
> > -   sysfs_remove_link(>dev.parent->kobj, (*i)->name);
> > +   for (ngrp = 0; ngrp < chip->groups_cnt; ++ngrp) {
> > +   if (chip->groups[ngrp]->name) {
> > +   sysfs_remove_link(>dev.parent->kobj,
> > + chip->groups[ngrp]->name);
> > +   } else {
> > +   for (i = chip->groups[ngrp]->attrs; *i != NULL; ++i)
> > +   sysfs_remove_link(>dev.parent->kobj,
> > + (*i)->name);
> > +   }
> > +   }
> 
> NAK
> 
> No new compat symlinks. Only the existing set of links are permitted.
> 
> Any new sysfs entries must use only the new location.
> 
> > +static struct attribute *tpm2_dev_attrs[] = {
> > NULL,
> >  };
> 
> > +static const struct attribute_group tpm2_dev_group = {
> > +   .attrs = tpm2_dev_attrs,
> > +};
> 
> Don't add dead code, add this and related in the patch that requires it.
> 
> >  void tpm_sysfs_add_device(struct tpm_chip *chip)
> >  {
> > /* The sysfs routines rely on an implicit tpm_try_get_ops, device_del
> > @@ -290,4 +306,8 @@ void tpm_sysfs_add_device(struct tpm_chip *chip)
> >  */
> > WARN_ON(chip->groups_cnt != 0);
> > chip->groups[chip->groups_cnt++] = _dev_group;
> > +   if (chip->flags & TPM_CHIP_FLAG_TPM2)
> > +   chip->groups[chip->groups_cnt++] = _dev_group;
> > +   else
> > +   chip->groups[chip->groups_cnt++] = _dev_group;
> 
> .. and this can't really happen either..
> 
> To make things simple you can just have tpm2 not ever create any links
> for any files by never using groups[0]. There is no need to try and
> create a shared 'tpm_dev_group'.
> 
> Jason

Hi Jason,

Mostly understood. One question.

tpm2 shares some of the attributes with tpm1 (e.g. timeouts). Do I still
just add those separately for tpm2 to groups[1] and keep groups[0] empty?

Andrey

Re: [PATCH 0/2] tpm: add driver for cr50 on SPI

[Jason Gunthorpe]

On Thu, Jul 14, 2016 at 07:50:26PM -0700, Andrey Pronin wrote:
> Yes, it has a TCG-compliant interface, however, there are several things
> specific to this device:
>  - need to ensure a certain delay between spi transactions, or else
>the chip can miss several first bytes.
>  - if there is no spi activity for this chip, it may go to sleep, and
>needs to be waken up before sending further commands.
>  - it has some vendor-specific registers accessible from spi bus.

This all needs to be commented clearly in the driver..

The chip sounds pretty broken...

Jason

Re: [PATCH 0/2] tpm: add driver for cr50 on SPI

[Jason Gunthorpe]

On Thu, Jul 14, 2016 at 07:50:26PM -0700, Andrey Pronin wrote:
> Yes, it has a TCG-compliant interface, however, there are several things
> specific to this device:
>  - need to ensure a certain delay between spi transactions, or else
>the chip can miss several first bytes.
>  - if there is no spi activity for this chip, it may go to sleep, and
>needs to be waken up before sending further commands.
>  - it has some vendor-specific registers accessible from spi bus.

This all needs to be commented clearly in the driver..

The chip sounds pretty broken...

Jason

Re: ARM: dts: exynos: Properly select eMMC HighSpeed mode

[Alim Akhtar]

Hi Krzysztof,

On 07/14/2016 06:17 PM, Krzysztof Kozlowski wrote:

Exynos5410 supports eMMC version 4.41 so HS200 is the top mode which
should be configured.  This is reflected in usage of
"samsung,exynos5250-dw-mshc" compatible.  However DTS contained also
property "mmc-hs400-1_8v" which is parsed by MMC core therefore
resulting in mixed configuration.  MMC core set HS400 but dwmmc_exynos
driver did not configure the data strobe for HS400 DDR mode.

Removal of HS400 properties fixes semi-random mmc errors during boot:
   mmc_host mmc0: Bus speed (slot 0) = 4Hz (slot req 2Hz, 
actual 2HZ div = 1)
   mmc0: mmc_select_hs400 failed, error -84
   mmc0: error -84 whilst initialising MMC card

Signed-off-by: Krzysztof Kozlowski 
---
  arch/arm/boot/dts/exynos5410-odroidxu.dts | 2 --
  1 file changed, 2 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5410-odroidxu.dts 
b/arch/arm/boot/dts/exynos5410-odroidxu.dts
index d9499310a301..7536164438ca 100644
--- a/arch/arm/boot/dts/exynos5410-odroidxu.dts
+++ b/arch/arm/boot/dts/exynos5410-odroidxu.dts
@@ -447,14 +447,12 @@
samsung,dw-mshc-ciu-div = <3>;
samsung,dw-mshc-sdr-timing = <0 4>;
samsung,dw-mshc-ddr-timing = <0 2>;
-   samsung,dw-mshc-hs400-timing = <0 2>;

not sure but can we use /delete-property/ option for this removable?

samsung,read-strobe-delay = <90>;

this also need to be removed.

pinctrl-names = "default";
pinctrl-0 = <_clk _cmd _bus1 _bus4 _bus8 _cd>;
bus-width = <8>;
cap-mmc-highspeed;
mmc-hs200-1_8v;
-   mmc-hs400-1_8v;

same as above if possible use /delete-property/

vmmc-supply = <_reg>;
vqmmc-supply = <_reg>;
  };

Re: ARM: dts: exynos: Properly select eMMC HighSpeed mode

[Alim Akhtar]

Hi Krzysztof,

On 07/14/2016 06:17 PM, Krzysztof Kozlowski wrote:

Exynos5410 supports eMMC version 4.41 so HS200 is the top mode which
should be configured.  This is reflected in usage of
"samsung,exynos5250-dw-mshc" compatible.  However DTS contained also
property "mmc-hs400-1_8v" which is parsed by MMC core therefore
resulting in mixed configuration.  MMC core set HS400 but dwmmc_exynos
driver did not configure the data strobe for HS400 DDR mode.

Removal of HS400 properties fixes semi-random mmc errors during boot:
   mmc_host mmc0: Bus speed (slot 0) = 4Hz (slot req 2Hz, 
actual 2HZ div = 1)
   mmc0: mmc_select_hs400 failed, error -84
   mmc0: error -84 whilst initialising MMC card

Signed-off-by: Krzysztof Kozlowski 
---
  arch/arm/boot/dts/exynos5410-odroidxu.dts | 2 --
  1 file changed, 2 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5410-odroidxu.dts 
b/arch/arm/boot/dts/exynos5410-odroidxu.dts
index d9499310a301..7536164438ca 100644
--- a/arch/arm/boot/dts/exynos5410-odroidxu.dts
+++ b/arch/arm/boot/dts/exynos5410-odroidxu.dts
@@ -447,14 +447,12 @@
samsung,dw-mshc-ciu-div = <3>;
samsung,dw-mshc-sdr-timing = <0 4>;
samsung,dw-mshc-ddr-timing = <0 2>;
-   samsung,dw-mshc-hs400-timing = <0 2>;

not sure but can we use /delete-property/ option for this removable?

samsung,read-strobe-delay = <90>;

this also need to be removed.

pinctrl-names = "default";
pinctrl-0 = <_clk _cmd _bus1 _bus4 _bus8 _cd>;
bus-width = <8>;
cap-mmc-highspeed;
mmc-hs200-1_8v;
-   mmc-hs400-1_8v;

same as above if possible use /delete-property/

vmmc-supply = <_reg>;
vqmmc-supply = <_reg>;
  };