[PATCH] tty: serial: Fix spelling of Medfield

[Joseph Kogut]

Changed 'Medfile' to 'Medfield' in Kconfig

Signed-off-by: Joseph Kogut 
---
 drivers/tty/serial/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index d2501f0..7baf98c 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -489,7 +489,7 @@ config SERIAL_MFD_HSU
select SERIAL_CORE
 
 config SERIAL_MFD_HSU_CONSOLE
-   bool "Medfile HSU serial console support"
+   bool "Medfield HSU serial console support"
depends on SERIAL_MFD_HSU=y
select SERIAL_CORE_CONSOLE
 
-- 
2.3.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] clkdev: clk_add_alias don't put origin clock

[Yoshinori Sato]

Refer to 'r' later.
So don't put in clk_add_alias.

Signed-off-by: Yoshinori Sato 
---
 drivers/clk/clkdev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/clkdev.c b/drivers/clk/clkdev.c
index 043fd36..fddb999 100644
--- a/drivers/clk/clkdev.c
+++ b/drivers/clk/clkdev.c
@@ -318,7 +318,6 @@ int clk_add_alias(const char *alias, const char 
*alias_dev_name, char *id,
return PTR_ERR(r);
 
l = clkdev_alloc(r, alias, alias_dev_name);
-   clk_put(r);
if (!l)
return -ENODEV;
clkdev_add(l);
@@ -334,6 +333,7 @@ void clkdev_drop(struct clk_lookup *cl)
mutex_lock(_mutex);
list_del(>node);
mutex_unlock(_mutex);
+   clk_put(cl->clk);
kfree(cl);
 }
 EXPORT_SYMBOL(clkdev_drop);
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] tty: serial: Fixed misspelling of 'Medfield' in Kconfig

[Joseph Kogut]

My apologies, please disregard this patch. It seems my tree wasn't
clean, and another change snuck its way in.

On Sun, Mar 1, 2015 at 12:39 AM, Joseph Kogut  wrote:
> Change 'Medfile' to 'Medfield'
>
> Signed-off-by: Joseph Kogut 
> ---
>  drivers/tty/serial/Kconfig | 2 +-
>  drivers/tty/serial/mfd.c   | 1 +
>  2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
> index d2501f0..7baf98c 100644
> --- a/drivers/tty/serial/Kconfig
> +++ b/drivers/tty/serial/Kconfig
> @@ -489,7 +489,7 @@ config SERIAL_MFD_HSU
> select SERIAL_CORE
>
>  config SERIAL_MFD_HSU_CONSOLE
> -   bool "Medfile HSU serial console support"
> +   bool "Medfield HSU serial console support"
> depends on SERIAL_MFD_HSU=y
> select SERIAL_CORE_CONSOLE
>
> diff --git a/drivers/tty/serial/mfd.c b/drivers/tty/serial/mfd.c
> index 8fe4501..97b0cf5 100644
> --- a/drivers/tty/serial/mfd.c
> +++ b/drivers/tty/serial/mfd.c
> @@ -1460,6 +1460,7 @@ static const struct pci_device_id pci_ids[] = {
> { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x081C) },
> { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x081D) },
> { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x081E) },
> +   { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x1191) },
> {},
>  };
>
> --
> 2.3.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] tty: serial: Fixed misspelling of 'Medfield' in Kconfig

[Joseph Kogut]

Change 'Medfile' to 'Medfield'

Signed-off-by: Joseph Kogut 
---
 drivers/tty/serial/Kconfig | 2 +-
 drivers/tty/serial/mfd.c   | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index d2501f0..7baf98c 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -489,7 +489,7 @@ config SERIAL_MFD_HSU
select SERIAL_CORE
 
 config SERIAL_MFD_HSU_CONSOLE
-   bool "Medfile HSU serial console support"
+   bool "Medfield HSU serial console support"
depends on SERIAL_MFD_HSU=y
select SERIAL_CORE_CONSOLE
 
diff --git a/drivers/tty/serial/mfd.c b/drivers/tty/serial/mfd.c
index 8fe4501..97b0cf5 100644
--- a/drivers/tty/serial/mfd.c
+++ b/drivers/tty/serial/mfd.c
@@ -1460,6 +1460,7 @@ static const struct pci_device_id pci_ids[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x081C) },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x081D) },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x081E) },
+   { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x1191) },
{},
 };
 
-- 
2.3.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/2] virtio_blk header fixes

[Michael S. Tsirkin]

Now that QEmu reuses linux virtio headers, we noticed
a typo in the exported virtio block header. Fix it up.

I'd like these merged for 4.0 so that Qemu 2.3 can
alredy get it right.

Michael S. Tsirkin (2):
  virtio_blk: typo fix
  virtio_blk: fix comment for virtio 1.0

 include/uapi/linux/virtio_blk.h | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

-- 
MST

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/2] virtio_blk: fix comment for virtio 1.0

[Michael S. Tsirkin]

Fix up comment to match virtio 1.0 logic:
virtio_blk_outhdr isn't the first elements anymore,
the only requirement is that it comes first in
the s/g list.

Signed-off-by: Michael S. Tsirkin 
---
 include/uapi/linux/virtio_blk.h | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/include/uapi/linux/virtio_blk.h b/include/uapi/linux/virtio_blk.h
index b695ba9..19c66fc 100644
--- a/include/uapi/linux/virtio_blk.h
+++ b/include/uapi/linux/virtio_blk.h
@@ -119,7 +119,11 @@ struct virtio_blk_config {
 #define VIRTIO_BLK_T_BARRIER   0x8000
 #endif /* !VIRTIO_BLK_NO_LEGACY */
 
-/* This is the first element of the read scatter-gather list. */
+/*
+ * This comes first in the read scatter-gather list.
+ * For legacy virtio, if VIRTIO_F_ANY_LAYOUT is not negotiated,
+ * this is the first element of the read scatter-gather list.
+ */
 struct virtio_blk_outhdr {
/* VIRTIO_BLK_T* */
__virtio32 type;
-- 
MST

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2] virtio_blk: typo fix

[Michael S. Tsirkin]

Now that QEmu reuses linux virtio headers, we noticed
a typo in the exported virtio block header. Fix it up.

Signed-off-by: Michael S. Tsirkin 
---
 include/uapi/linux/virtio_blk.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/uapi/linux/virtio_blk.h b/include/uapi/linux/virtio_blk.h
index 3c53eec..b695ba9 100644
--- a/include/uapi/linux/virtio_blk.h
+++ b/include/uapi/linux/virtio_blk.h
@@ -60,7 +60,7 @@ struct virtio_blk_config {
__u32 size_max;
/* The maximum number of segments (if VIRTIO_BLK_F_SEG_MAX) */
__u32 seg_max;
-   /* geometry the device (if VIRTIO_BLK_F_GEOMETRY) */
+   /* geometry of the device (if VIRTIO_BLK_F_GEOMETRY) */
struct virtio_blk_geometry {
__u16 cylinders;
__u8 heads;
-- 
MST

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] ARM: dts: add rk3288 PopMetal board

[Andy Yan]

Hi Heiko:

On 2015年03月01日 01:57, Heiko Stübner wrote:

Hi Andy,

Am Freitag, 27. Februar 2015, 19:03:03 schrieb Andy Yan:

PopMetal is a rockchip rk3288 based board made by ChipSpark,
which has many interface such as VGA,HDMI,usb,ir,sdcad and
lots of sensors such as gyroscope(L3G4200D),accelerometer(mma8452),
compass(AK8963C).

This patch add a basic support for this board, which make the board
boot into a initramfs shell with sdcard and all sensors enabled

Signed-off-by: Andy Yan 
---

  arch/arm/boot/dts/rk3288-popmetal.dts | 396
++ 1 file changed, 396 insertions(+)
  create mode 100644 arch/arm/boot/dts/rk3288-popmetal.dts

diff --git a/arch/arm/boot/dts/rk3288-popmetal.dts
b/arch/arm/boot/dts/rk3288-popmetal.dts new file mode 100644
index 000..f0c0cd9
--- /dev/null
+++ b/arch/arm/boot/dts/rk3288-popmetal.dts
@@ -0,0 +1,396 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This 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.

could you please put the new file under a gpl2+x11 dual license?
See the firefly dts files for an example.

Relicensing the of the already existing files is somewhere on my todo list, but
but at least we shouldn't introduce new restricted files at this point :-) .


Licensing with a more permissible license is necessary so that other projects
can use our dts files too (like the BSDs) and the gpl2 + x11 dual license is
the current agreed upon combination.

ok, I will use gpl2+x11 dual license



+ */
+
+/dts-v1/;
+
+#include "rk3288.dtsi"
+
+/ {
+   model = "PopMetal-RK3288";
+   compatible = "chipspark,popmetal-rk3288", "rockchip,rk3288";

a blank line here please

   ok



+   memory{
+   reg = <0 0x8000>;
+   };
+
+   ext_gmac: external-gmac-clock {
+   compatible = "fixed-clock";
+   clock-frequency = <12500>;
+   clock-output-names = "ext_gmac";
+   #clock-cells = <0>;
+   };
+
+   gpio-keys {
+   compatible = "gpio-keys";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   autorepeat;
+
+   pinctrl-names = "default";
+   pinctrl-0 = <>;
+
+   button@0 {
+   gpios = < 5 GPIO_ACTIVE_LOW>;
+   linux,code = <116>;
+   label = "GPIO Key Power";
+   linux,input-type = <1>;
+   gpio-key,wakeup = <1>;
+   debounce-interval = <100>;
+   };
+   };
+
+   ir: ir-receiver {
+   compatible = "gpio-ir-receiver";
+   gpios = < 6 GPIO_ACTIVE_LOW>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_int>;
+   };
+
+};
+
+ {
+   broken-cd;
+   bus-width = <8>;
+   cap-mmc-highspeed;
+   disable-wp;
+   non-removable;
+   num-slots = <1>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_clk _cmd _pwr _bus8>;
+   status = "okay";
+};
+
+ {
+   bus-width = <4>;
+   cap-mmc-highspeed;
+   cap-sd-highspeed;
+   card-detect-delay = <200>;
+   disable-wp; /* wp not hooked up */
+   num-slots = <1>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_clk _cmd _cd _bus4>;
+   status = "okay";
+};
+
+ {
+   phy-supply = <_lan>;
+   phy-mode = "rgmii";
+   clock_in_out = "input";
+   snps,reset-gpio = < 7 0>;
+   snps,reset-active-low;
+   snps,reset-delays-us = <0 1 100>;
+   assigned-clocks = < SCLK_MAC>;
+   assigned-clock-parents = <_gmac>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   tx_delay = <0x30>;
+   rx_delay = <0x10>;
+   status = "ok";
+};
+
+ {
+   ddc-i2c-bus = <>;
+   status = "okay";
+};
+
+ {
+   status = "okay";
+   clock-frequency = <40>;
+
+   rk808: pmic@1b {
+   compatible = "rockchip,rk808";
+   reg = <0x1b>;
+   interrupt-parent = <>;
+   interrupts = <4 IRQ_TYPE_LEVEL_LOW>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_int _pwroff>;
+   rockchip,system-power-controller;
+   wakeup-source;
+   #clock-cells = <1>;
+   clock-output-names = "xin32k", "rk808-clkout2";
+
+   vcc8-supply = <_18>;
+   vcc9-supply = <_io>;
+   vcc10-supply = <_io>;
+   vcc12-supply = <_io>;
+
+   regulators {
+  

Re: [git pull] drm fixes

[Linus Torvalds]

On Sat, Feb 28, 2015 at 10:08 PM, Linus Torvalds
 wrote:
>
> I'll see how painful it is to bisect it,

Not surprisingly, it went right for the drm merge.

Commit 8c334ce8f0fe ("Merge branch 'timers-core-for-linus'..") is
good, while the next merge commit 796e1c55717e ("Merge branch
'drm-next' ..") is bad and doesn't boot.

I'll try to narrow it down at least a *bit* more, even if it's a
painfully slow machine.

   Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] dt-bindings: add root compatible property for PopMetal board

[Andy Yan]

Hi Heiko:

On 2015年03月01日 01:43, Heiko Stübner wrote:

Hi Andy,

Am Freitag, 27. Februar 2015, 18:59:01 schrieb Andy Yan:

PopMetal board is a rk3288 based board made by ChipSpark,
this patch add root compatible property for it

Signed-off-by: Andy Yan 

---

  Documentation/devicetree/bindings/arm/rockchip.txt | 4 
  1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt
b/Documentation/devicetree/bindings/arm/rockchip.txt index 6809e4e..818d249
100644
--- a/Documentation/devicetree/bindings/arm/rockchip.txt
+++ b/Documentation/devicetree/bindings/arm/rockchip.txt
@@ -22,3 +22,7 @@ Rockchip platforms device tree bindings
- compatible = "firefly,firefly-rk3288", "rockchip,rk3288";
  or
- compatible = "firefly,firefly-rk3288-beta", "rockchip,rk3288";
+
+- PopMetal PopMetal-RK3288 board:

this should probably be
ChipSPARK PopMetal-RK3288 board:

  ok, this will be fixed in V2




+Required root node properties:
+  - compatible = "chipspark,popmetal-rk3288", "rockchip,rk3288";







--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Lepas KIDEX - East Klang Valley Expressway. Azmin Perlu Isu Untuk Lonjak Nama Sebagai Ketua Pembangkang.

[Kuasa Rakyat]

Assalamualaikum w.r.t

Azmin punyalah ingat, selepas dia terjun longkang, tangkap lori hantu, buat 
gotong royong, cuci
pakaian orang - dia sudah boleh lonjak diri sebagai Ketua Pembangkang. 
Rupa-rupanya, DAP
masih tak percaya dengan Azmin.

Apa punca DAP benci dan tak percaya kepada Azmin? Sebab DAP tahu, selepas 
PRU13, Azmin
antara individu yang kuat bertanya-tanya dengan orang keliling Najib tentang 
HARGA YANG
SANGGUP DIBAYAR jika dia berpaling tadah.

Selanjutnya sila layari http://gelagatanwar.wordpress.com
 
Gelagat
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2] net: macb: Add on the fly CPU endianness detection

[Arun Chandran]

Program management descriptor's access mode according to the
dynamically detected CPU endianness.

Signed-off-by: Arun Chandran 
Acked-by: Nicolas Ferre 
Tested-by: Michal Simek 
---
* Adding CPU endianness detection according to Michal Simek
* Added Acked-by: Nicolas Ferre
* Added Tested-by: Michal Simek
---
---
 drivers/net/ethernet/cadence/macb.c | 22 ++
 1 file changed, 18 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/cadence/macb.c 
b/drivers/net/ethernet/cadence/macb.c
index 05fb36d..1fe8b94 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -1578,6 +1578,7 @@ static u32 macb_dbw(struct macb *bp)
 static void macb_configure_dma(struct macb *bp)
 {
u32 dmacfg;
+   u32 tmp, ncr;
 
if (macb_is_gem(bp)) {
dmacfg = gem_readl(bp, DMACFG) & ~GEM_BF(RXBS, -1L);
@@ -1586,10 +1587,23 @@ static void macb_configure_dma(struct macb *bp)
dmacfg = GEM_BFINS(FBLDO, bp->dma_burst_length, dmacfg);
dmacfg |= GEM_BIT(TXPBMS) | GEM_BF(RXBMS, -1L);
dmacfg &= ~GEM_BIT(ENDIA_PKT);
-   /* Tell the chip to byteswap descriptors on big-endian hosts */
-#ifdef __BIG_ENDIAN
-   dmacfg |= GEM_BIT(ENDIA_DESC);
-#endif
+
+   /* Find the CPU endianness by using the loopback bit of net_ctrl
+* register. save it first. When the CPU is in big endian we
+* need to program swaped mode for management descriptor access.
+*/
+   ncr = macb_readl(bp, NCR);
+   __raw_writel(MACB_BIT(LLB), bp->regs + MACB_NCR);
+   tmp =  __raw_readl(bp->regs + MACB_NCR);
+
+   if (tmp == MACB_BIT(LLB))
+   dmacfg &= ~GEM_BIT(ENDIA_DESC);
+   else
+   dmacfg |= GEM_BIT(ENDIA_DESC); /* CPU in big endian */
+
+   /* Restore net_ctrl */
+   macb_writel(bp, NCR, ncr);
+
if (bp->dev->features & NETIF_F_HW_CSUM)
dmacfg |= GEM_BIT(TXCOEN);
else
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/2] net: macb: Properly add DMACFG bit definitions

[Arun Chandran]

Add *_SIZE macros for the bits ENDIA_DESC and
ENDIA_PKT

Signed-off-by: Arun Chandran 
Acked-by: Nicolas Ferre 
---
* Correct these macros according to comments from Nicolas Ferre. Also add his 
Acked-by
---
---
 drivers/net/ethernet/cadence/macb.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/cadence/macb.h 
b/drivers/net/ethernet/cadence/macb.h
index 57f0a1a..83241c8 100644
--- a/drivers/net/ethernet/cadence/macb.h
+++ b/drivers/net/ethernet/cadence/macb.h
@@ -230,8 +230,9 @@
 #define GEM_FBLDO_OFFSET   0 /* fixed burst length for DMA */
 #define GEM_FBLDO_SIZE 5
 #define GEM_ENDIA_DESC_OFFSET  6 /* endian swap mode for management descriptor 
access */
+#define GEM_ENDIA_DESC_SIZE1
 #define GEM_ENDIA_PKT_OFFSET   7 /* endian swap mode for packet data access */
-#define GEM_ENDIA_SIZE 1
+#define GEM_ENDIA_PKT_SIZE 1
 #define GEM_RXBMS_OFFSET   8 /* RX packet buffer memory size select */
 #define GEM_RXBMS_SIZE 2
 #define GEM_TXPBMS_OFFSET  10 /* TX packet buffer memory size select */
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [git pull] drm fixes

[Linus Torvalds]

On Sat, Feb 28, 2015 at 9:40 PM, Linus Torvalds
 wrote:
>
> I'm not sure how new these problems are, I think the previous kernel I
> booted on this machine was 3.16.

Hmm. 3.19 works fine, even if it ends up spewing

WARNING: CPU: 0 PID: 6 at drivers/gpu/drm/drm_irq.c:1121
drm_wait_one_vblank+0x125/0x130()
vblank not available on crtc 1, ret=-22

a lot. But it doesn't have the problems I saw with current -git.

So it's new to this merge window.

I'll see how painful it is to bisect it,

   Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] drm: Fix warning with make xmldocs caused by drm_crtc.h

[Masanari Iida]

This patch fix following warning while make xmldocs.

Warning(.//include/drm/drm_crtc.h:1016): Excess struct/union/enum/typedef
member 'num_bridges' description in 'drm_mode_group'

Signed-off-by: Masanari Iida 
---
 include/drm/drm_crtc.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 920e21a..8a4a2d0b 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -997,7 +997,6 @@ struct drm_mode_config_funcs {
  * @num_crtcs: CRTC count
  * @num_encoders: encoder count
  * @num_connectors: connector count
- * @num_bridges: bridge count
  * @id_list: list of KMS object IDs in this group
  *
  * Currently this simply tracks the global mode setting state.  But in the
-- 
2.3.1.167.g7f4ba4b

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [git pull] drm fixes

[Linus Torvalds]

Hmm. I haven't updated the old Mac Mini I have in a *long* time, but
today I decided to try.

And it causes problems in drm.

I'm not sure how new these problems are, I think the previous kernel I
booted on this machine was 3.16. But I thought I'd better report them
as-is, because bisection on this thing takes *forever*, and it's quite
possible that you or one of the i915 guys goes "ahh, of course", so no
point in wasting time on bisection unless absolutely required.

Anyway, I have two warnings, and then had to do a work-around to avoid an oops.

Warning #1:

...
fbcon: inteldrmfb (fb0) is primary device
random: nonblocking pool is initialized
[drm] Setting output timings on SDVOB failed
[ cut here ]
WARNING: CPU: 1 PID: 15 at drivers/gpu/drm/i915/i915_gem.c:4524
i915_gem_free_object+0x22d/0x250()
WARN_ON(obj->frontbuffer_bits)
CPU: 1 PID: 15 Comm: kworker/u4:1 Tainted: GW
4.0.0-rc1-00129-g6380ad5-dirty #3
Hardware name: Apple Computer, Inc. Macmini1,1/Mac-F4208EC8, BIOS
   MM11.88Z.0055.B03.0604071521 04/07/06
Workqueue: events_unbound async_run_entry_fn
Call Trace:
  dump_stack+0x41/0x52
  warn_slowpath_common+0x7f/0xb0
  warn_slowpath_fmt+0x2e/0x30
  i915_gem_free_object+0x22d/0x250
  drm_gem_object_free+0x1a/0x20
  intel_user_framebuffer_destroy+0x5d/0x80
  drm_framebuffer_free+0x43/0x60
  drm_framebuffer_unreference+0x28/0x60
  drm_mode_set_config_internal+0x8e/0xc0
  restore_fbdev_mode+0xc2/0xf0
  drm_fb_helper_restore_fbdev_mode_unlocked+0x24/0x70
  drm_fb_helper_set_par+0x1d/0x40
  intel_fbdev_set_par+0x18/0x60
  fbcon_init+0x4e2/0x530
  do_bind_con_driver+0x15e/0x330
  do_take_over_console+0xd5/0x160
  do_fbcon_takeover+0x5d/0xc0
  fbcon_event_notify+0x5dd/0x760
  notifier_call_chain+0x41/0x60
  __blocking_notifier_call_chain+0x46/0x60
  blocking_notifier_call_chain+0x1a/0x20
  fb_notifier_call_chain+0x11/0x20
  register_framebuffer+0x1f2/0x2f0
  drm_fb_helper_initial_config+0x2aa/0x370
  intel_fbdev_initial_config+0x14/0x20
  async_run_entry_fn+0x31/0xd0
  process_one_work+0xee/0x2b0
  worker_thread+0x39/0x400
  kthread+0xac/0xd0
  ret_from_kernel_thread+0x21/0x30
---[ end trace e533d8d502f4f45e ]---
Console: switching to colour frame buffer device 210x65
...

but things seemed to work despite it. The more scary warning is #2:

...
dracut: Starting plymouth daemon
usb 5-1: new full-speed USB device number 2 using uhci_hcd
setfont (1129) used greatest stack depth: 6448 bytes left
[ cut here ]
WARNING: CPU: 1 PID: 1127 at include/linux/kref.h:47
drm_framebuffer_reference+0x39/0x70()
CPU: 1 PID: 1127 Comm: plymouthd Tainted: GW
4.0.0-rc1-00129-g6380ad5-dirty #3
Hardware name: Apple Computer, Inc. Macmini1,1/Mac-F4208EC8, BIOS
   MM11.88Z.0055.B03.0604071521 04/07/06
Call Trace:
  dump_stack+0x41/0x52
  warn_slowpath_common+0x7f/0xb0
  warn_slowpath_null+0x1d/0x20
  drm_framebuffer_reference+0x39/0x70
  intel_plane_duplicate_state+0x36/0x70
  drm_plane_helper_update+0x24/0xc0
  __intel_set_mode+0x71c/0x9c0
  intel_set_mode+0x6b/0x90
  intel_get_load_detect_pipe+0x332/0x470
  intel_tv_detect+0x84/0x4e0
  drm_helper_probe_single_connector_modes_merge_bits+0x1a3/0x440
  drm_helper_probe_single_connector_modes+0x12/0x20
  drm_mode_getconnector+0x2e7/0x320
  drm_ioctl+0x1e5/0x560
  do_vfs_ioctl+0x71/0x590
  SyS_ioctl+0x92/0xa0
  syscall_call+0x7/0x7
---[ end trace e533d8d502f4f460 ]---
usb 5-1: New USB device found, idVendor=05ac, idProduct=1000
usb 5-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
...

which is scary because it implies some bad reference counting problem.
And in fact, that warning was followed by a NULL pointer oops, which I
worked around with this crazy patch:

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 6b6b07f..28527ac 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -452,7 +452,8 @@ static void drm_framebuffer_free(struct kref *kref)
}
mutex_unlock(>mode_config.fb_lock);

-   fb->funcs->destroy(fb);
+   if (fb->funcs)
+   fb->funcs->destroy(fb);
 }

 static struct drm_framebuffer *__drm_framebuffer_lookup(struct
drm_device *dev,

because "fb->funcs" was NULL. I assume it was NULL because some fb
freeing had cleared them already due to the kref going down to zero.

Any ideas? This is an ancient box with ancient user land, and not
getting a lot of testing. But it *used* to work.

 Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  

Re: [PATCH 3/3] locking: rtmutex: set state back to running on error

[Mike Galbraith]

On Fri, 2015-02-27 at 17:57 +0100, Sebastian Andrzej Siewior wrote:
> The "usual" path is:
> - rt_mutex_slowlock()
>  - set_current_state()
>  - task_blocks_on_rt_mutex() (ret 0)
>  - __rt_mutex_slowlock()
>- sleep or not but do return with __set_current_state(TASK_RUNNING)
>  - back to caller.
> 
> In the early error case where task_blocks_on_rt_mutex() return -EDEADLK
> we never change the task's state back to RUNNING. I assume this is
> intended. Without this change after ww_mutex using rt_mutex the selftest
> passes but later I get plenty of
> | bad: scheduling from the idle thread!
> backtraces.
> 
> Signed-off-by: Sebastian Andrzej Siewior 
> ---
>  kernel/locking/rtmutex.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c
> index 6d7d72ffa619..c4d07f254bb4 100644
> --- a/kernel/locking/rtmutex.c
> +++ b/kernel/locking/rtmutex.c
> @@ -1305,6 +1305,7 @@ rt_mutex_slowlock(struct rt_mutex *lock, int state,
>   }
>  
>   if (unlikely(ret)) {
> + set_current_state(TASK_RUNNING);
>   if (rt_mutex_has_waiters(lock))
>   remove_waiter(lock, );
>   /* ww_mutex need the error reported */

This may want a Fixes: afffc6c1 tag, and should use the double
underscore variant methinks.

-Mike

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3] net: bcmgenet: fix throughtput regression

[David Miller]

From: Jaedon Shin 
Date: Sat, 28 Feb 2015 11:48:26 +0900

> This patch adds bcmgenet_tx_poll for the tx_rings. This can reduce the
> interrupt load and send xmit in network stack on time. This also
> separated for the completion of tx_ring16 from bcmgenet_poll.
> 
> The bcmgenet_tx_reclaim of tx_ring[{0,1,2,3}] operative by an interrupt
> is to be not more than a certain number TxBDs. It is caused by too
> slowly reclaiming the transmitted skb. Therefore, performance
> degradation of xmit after 605ad7f ("tcp: refine TSO autosizing").
> 
> Signed-off-by: Jaedon Shin 
> Signed-off-by: Florian Fainelli 

Applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] sh_eth: Fix lost MAC address on kexec

[David Miller]

From: Geert Uytterhoeven 
Date: Fri, 27 Feb 2015 17:16:26 +0100

> Commit 740c7f31c094703c ("sh_eth: Ensure DMA engines are stopped before
> freeing buffers") added a call to sh_eth_reset() to the
> sh_eth_set_ringparam() and sh_eth_close() paths.
> 
> However, setting the software reset bit(s) in the EDMR register resets
> the MAC Address Registers to zero. Hence after kexec, the new kernel
> doesn't detect a valid MAC address and assigns a random MAC address,
> breaking DHCP.
> 
> Set the MAC address again after the reset in sh_eth_dev_exit() to fix
> this.
> 
> Tested on r8a7740/armadillo (GETHER) and r8a7791/koelsch (FAST_RCAR).
> 
> Fixes: 740c7f31c094703c ("sh_eth: Ensure DMA engines are stopped before 
> freeing buffers")
> Signed-off-by: Geert Uytterhoeven 

Applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RFC 0/2] add nproc cgroup subsystem

[Tim Hockin]

On Feb 28, 2015 2:50 PM, "Tejun Heo"  wrote:
>
> On Sat, Feb 28, 2015 at 02:26:58PM -0800, Tim Hockin wrote:
> > Wow, so much anger.  I'm not even sure how to respond, so I'll just
> > say this and sign off.  All I want is a better, friendlier, more
> > useful system overall.  We clearly have different ways of looking at
> > the problem.
>
> Can you communicate anything w/o passive aggression?  If you have a
> technical point, just state that.  Can you at least agree that we
> shouldn't be making design decisions based on 16bit pid_t?

Hmm, I have screwed this thread up, I think.  I've made some remarks
that did not come through with the proper tongue-in-cheek slant.  I'm
not being passive aggressive - we DO look at this problem differently.
OF COURSE we should not make decisions based on ancient artifacts of
history.  My point was that there are secondary considerations here -
PIDs are more than just the memory that backs them.  They _ARE_ a
constrained resource, and you shouldn't assume the constraint is just
physical memory.  It is a piece of policy that is outside the control
of the kernel proper - we handed those keys to userspace along time
ago.

Given that, I believe and have believed that the solution should model
the problem as the user perceives it - limiting PIDs - rather than
attaching to a solution-by-proxy.

Yes a solution here partially overlaps with kmemcg, but I don't think
that is a significant problem.  They are different policies governing
behavior that may result in the same condition, but for very different
reasons.  I do not think that is particularly bad for overall
comprehension, and I think the fact that this popped up yet again
indicates the existence of some nugget of user experience that is
worth paying consideration to.

I appreciate your promised consideration through a slightly refocused
lens.  I will go back to my cave and do something I hope is more
productive and less antagonistic.  I did not mean to bring out so much
vitriol.

Tim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] capabilities: Ambient capability set V2

[Serge E. Hallyn]

On Thu, Feb 26, 2015 at 04:14:33PM -0600, Christoph Lameter wrote:
> 
> V1->V2:
>  - Fix up the processing of the caps bits after discussions
>with Any and Serge. Make patch less intrusive.
> 
> Ambient caps are something like restricted root privileges.
> A process has a set of additional capabilities and those
> are inherited without have to set capabilites in other
> binaries involved. This allow the partial use of root
> like features in a controlled way. It is often useful
> to do this for user space device drivers or software that
> needs increased priviledges for networking or to control
> its own scheduling. Ambient caps allow one to avoid
> having to run these with full root priviledges.
> 
> Control over this feature is avaialable via a new
> prctl option called PR_CAP_AMBIENT. The second argument to prctl
> is a the capability number and the third the desired state.
> 0 for off. Otherwise on.
> 
> Ambient bits are enabled regardless of the inheritance
> mask of the target binary. They are only restricted
> by the bounding set.
> 
> History:
> 
> Linux capabilities have suffered from the problem that they are not
> inheritable like unregular process characteristics under Unix. This is
> behavior that is counter intuitive to the expected behavior of processes
> in Unix.
> 
> In particular there has been recently software that controls NICs from user
> space and provides IP stack like behavior also in user space (DPDK and RDMA
> kernel API based implementations). Those typically need either capabilities
> to allow raw network access or have to be run setsuid. There is scripting and
> LD_PREFLOAD etc involved, arbitrary binaries may be run from those scripts
> including those setting additional capabilites or requiring root access.
> 
> That does not go well with having file capabilities set that would enable
> the capabilities. Maybe it would work if one would setup capabilities on
> all executables but that would also defeat a secure design since these
> binaries may only need those caps for certain situations. Ok setting the
> inheritable flags on everything may also get one there (if there would not
> be the issues with LD_PRELOAD, debugging etc etc).
> 
> The easy solution is to allow some capabilities be inherited like setsuid
> is. We really prefer to use capabilities instead of setsuid (we want to
> limit what damage someone can do after all!). Therefore we have been
> running a patch like this in production for the last 6 years. At some
> point it becomes tedious to run your own custom kernel so we would like
> to have this functionality upstream.
> 
> See some of the earlier related discussions on the problems with capability
> inheritance:
> 
> 0. Recent surprise:
> https://lkml.org/lkml/2014/1/21/175
> 
> 1. Attempt to revise caps
> http://www.madore.org/~david/linux/newcaps/
> 
> 2. Problems of passing caps through exec
> 
> http://unix.stackexchange.com/questions/128394/passing-capabilities-through-exec
> 
> 3. Problems of binding to privileged ports
> 
> http://stackoverflow.com/questions/413807/is-there-a-way-for-non-root-processes-to-bind-to-privileged-ports-1024-on-l
> 
> 4. Reviving capabilities
> http://lwn.net/Articles/199004/
> 
> There does not seem to be an alternative on the horizon. Some involved
> in security development under Linux have even stated that they want to
> rip out the whole thing and replace it. Its been a couple of years now
> and we are still suffering from the capabilities mess. Let us just
> fix it. Others have already done implementations like this like Nokia
> for the N900.
> 
> 
> This patch does not change the default behavior but it allows to set up
> a list of capabilities via prctl that will enable regular
> unix inheritance only for the selected group of capabilities.
> 
> With that it is then possible to do something trivial like setting
> CAP_NET_RAW on an executable that can then allow that capability to
> be inherited by others.
> 
> Lets have a look at a coding example of a wrapper that enables
> a couple of capabilities:
> 
> -- ambient_test.c
> /*
>  * Test program for the ambient capabilities
>  *
>  *
>  * Compile using:
>  *gcc -o ambient_test ambient_test.o
>  *
>  * This program must have the following capabilities to run properly:
>  * CAP_SETPCAP, CAP_NET_RAW, CAP_NET_ADMIN, CAP_SYS_NICE
>  *
>  * A command to equip this with the right caps is:
>  *
>  *setcap cap_setpcap,cap_net_raw,cap_net_admin,cap_sys_nice+eip 
> ambient_test
>  *
>  * To get a shell with additional caps that can be inherited do:
>  *
>  * ./ambient_test /bin/bash
>  *
>  */
> 
> #include 
> #include 
> #include 
> #include 
> #include 
> 
> /* Defintion to be updated in the user space include files */
> #define PR_CAP_AMBIENT 45
> 
> int main(int argc, char **argv)
> {
>   int rc;
> 
>   if (prctl(PR_CAP_AMBIENT, CAP_NET_RAW))
> 

[PATCH net-next] Driver: Vmxnet3: Copy TCP header to mapped frame for IPv6 packets

[Shrikrishna Khare]

Allows for packet parsing to be done by the fast path. This performance
optimization already exists for IPv4. Add similar logic for IPv6.

Signed-off-by: Amitabha Banerjee 
Signed-off-by: Shrikrishna Khare 
---
 drivers/net/vmxnet3/vmxnet3_drv.c | 29 -
 drivers/net/vmxnet3/vmxnet3_int.h |  5 +++--
 2 files changed, 23 insertions(+), 11 deletions(-)

diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c 
b/drivers/net/vmxnet3/vmxnet3_drv.c
index 294214c..61c0840 100644
--- a/drivers/net/vmxnet3/vmxnet3_drv.c
+++ b/drivers/net/vmxnet3/vmxnet3_drv.c
@@ -819,6 +819,7 @@ vmxnet3_parse_and_copy_hdr(struct sk_buff *skb, struct 
vmxnet3_tx_queue *tq,
   struct vmxnet3_adapter *adapter)
 {
struct Vmxnet3_TxDataDesc *tdd;
+   u8 protocol = 0;
 
if (ctx->mss) { /* TSO */
ctx->eth_ip_hdr_size = skb_transport_offset(skb);
@@ -831,16 +832,25 @@ vmxnet3_parse_and_copy_hdr(struct sk_buff *skb, struct 
vmxnet3_tx_queue *tq,
if (ctx->ipv4) {
const struct iphdr *iph = ip_hdr(skb);
 
-   if (iph->protocol == IPPROTO_TCP)
-   ctx->l4_hdr_size = tcp_hdrlen(skb);
-   else if (iph->protocol == IPPROTO_UDP)
-   ctx->l4_hdr_size = sizeof(struct 
udphdr);
-   else
-   ctx->l4_hdr_size = 0;
-   } else {
-   /* for simplicity, don't copy L4 headers */
+   protocol = iph->protocol;
+   } else if (ctx->ipv6) {
+   const struct ipv6hdr *ipv6h = ipv6_hdr(skb);
+
+   protocol = ipv6h->nexthdr;
+   }
+
+   switch (protocol) {
+   case IPPROTO_TCP:
+   ctx->l4_hdr_size = tcp_hdrlen(skb);
+   break;
+   case IPPROTO_UDP:
+   ctx->l4_hdr_size = sizeof(struct udphdr);
+   break;
+   default:
ctx->l4_hdr_size = 0;
+   break;
}
+
ctx->copy_size = min(ctx->eth_ip_hdr_size +
 ctx->l4_hdr_size, skb->len);
} else {
@@ -887,7 +897,7 @@ vmxnet3_prepare_tso(struct sk_buff *skb,
iph->check = 0;
tcph->check = ~csum_tcpudp_magic(iph->saddr, iph->daddr, 0,
 IPPROTO_TCP, 0);
-   } else {
+   } else if (ctx->ipv6) {
struct ipv6hdr *iph = ipv6_hdr(skb);
 
tcph->check = ~csum_ipv6_magic(>saddr, >daddr, 0,
@@ -938,6 +948,7 @@ vmxnet3_tq_xmit(struct sk_buff *skb, struct 
vmxnet3_tx_queue *tq,
count = txd_estimate(skb);
 
ctx.ipv4 = (vlan_get_protocol(skb) == cpu_to_be16(ETH_P_IP));
+   ctx.ipv6 = (vlan_get_protocol(skb) == cpu_to_be16(ETH_P_IPV6));
 
ctx.mss = skb_shinfo(skb)->gso_size;
if (ctx.mss) {
diff --git a/drivers/net/vmxnet3/vmxnet3_int.h 
b/drivers/net/vmxnet3/vmxnet3_int.h
index cd71c77..6bb769a 100644
--- a/drivers/net/vmxnet3/vmxnet3_int.h
+++ b/drivers/net/vmxnet3/vmxnet3_int.h
@@ -69,10 +69,10 @@
 /*
  * Version numbers
  */
-#define VMXNET3_DRIVER_VERSION_STRING   "1.3.4.0-k"
+#define VMXNET3_DRIVER_VERSION_STRING   "1.3.5.0-k"
 
 /* a 32-bit int, each byte encode a verion number in VMXNET3_DRIVER_VERSION */
-#define VMXNET3_DRIVER_VERSION_NUM  0x01030400
+#define VMXNET3_DRIVER_VERSION_NUM  0x01030500
 
 #if defined(CONFIG_PCI_MSI)
/* RSS only makes sense if MSI-X is supported. */
@@ -211,6 +211,7 @@ struct vmxnet3_tq_driver_stats {
 
 struct vmxnet3_tx_ctx {
bool   ipv4;
+   bool   ipv6;
u16 mss;
u32 eth_ip_hdr_size; /* only valid for pkts requesting tso or csum
 * offloading
-- 
1.8.5.6

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] MAINTAINERS: fix file encoding

[Greg KH]

On Sat, Feb 28, 2015 at 02:53:30PM -0500, Mike Frysinger wrote:
> This file is largely UTF-8 except for this one entry which is ISO-8859-1.
> By mixing the encodings, grep thinks the file is binary.
> 
> Signed-off-by: Mike Frysinger 

Acked-by: Greg Kroah-Hartman 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Generic page fault (Was: libsigsegv ....)

[Benjamin Herrenschmidt]

On Sat, 2015-02-28 at 16:41 -0800, Linus Torvalds wrote:
> On Sat, Feb 28, 2015 at 3:02 PM, Benjamin Herrenschmidt
>  wrote:
> >
> > Anyway, here's the current patch:
> 
> Ok, I think I like this approach better.
> 
> Your FAULT_FLAG_EXEC handling is wrong, though. It shouldn't check
> VM_WRITE, it should check VM_EXEC. A bit too much copy-paste ;)

Ah yes indeed :) I would have caught that pretty quickly once I tried
powerpc.

> Btw, it's quite possible that we could just do all the PF_PROT
> handling at the x86 level, before even calling the generic fault
> handler. It's not like we even need the vma or the mm semaphore: if
> it's a non-write protection fault, we always SIGSEGV. So why even
> bother getting the locks and looking up the page tables etc?

For non-write possibly, though that means we always end up going
through handle_mm_fault for a non-present PTE before we decide
that it wasn't actually accessible.

Not a huge deal I suppose unless something (ab)uses mprotect + emulation
for things like spying on MMIO accesses (been there) or god knows what
other userspace based paging or GC might be out there. It's asking for
trouble but the check in access_error() doesn't hurt much either.

On the other hand, we are all about simplifying code here, aren't
we ? :-) It's not like the early bail-out on x86 will buy us much and
it's going to be more arch specific code since they'll all have a
different variant of PF_PROT.

One thing that worries me a bit, however, with the PF_PROT handling in
the generic case is the case of archs who support
present-but-not-accessible PTEs in "HW" (for us that basically means no
_PAGE_USER), as these might use such fault for NUMA balancing, or
software maintained "young" bit, and in those case, bailing out on
PF_PROT is wrong. I'll have to figure out if that ever happens when I
dig through more archs.

> Now, that PF_PROT handling isn't exactly performance-critical, but it
> might help to remove the odd x86 special case from the generic code.

I don't think it's that odd on x86. If you look at what other archs do,
there's a bit of everything out there. Just powerpc may or may not
support exec permission for example depending on the CPU generation and
when it doesn't it's basically similar to x86. I yet have to fully
understand what ARM does (looks simple, just need to make sure it's what
I think it is and check various ARM generations), sparc has its
oddities, etc...

None of that is terribly urgent and I'm pretty busy so give me a bit
more time now that we have some kind of direction, to go through a few
more archs and see where it takes us. I'll start gathering cross
compilers and qemu debian images in the next few days.

Cheers,
Ben.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] HID: multitouch: Add support for button type usage

[Seth Forshee]

According to [1], Windows Precision Touchpad devices must supply
a button type usage in the device capabilities feature report. A
value of 0 indicates that the device contains a depressible
button (i.e. it's a click-pad) whereas a value of 1 indicates
a non-depressible button. Add support for this usage and set
INPUT_PROP_BUTTONPAD on the touchpad input device whenever a
depressible button is present.

v2: Add string for button type usage in debugfs.

[1] 
https://msdn.microsoft.com/en-us/library/windows/hardware/dn467314(v=vs.85).aspx

Signed-off-by: Seth Forshee 
---
 drivers/hid/hid-debug.c  |  1 +
 drivers/hid/hid-multitouch.c | 19 +++
 include/linux/hid.h  |  1 +
 3 files changed, 21 insertions(+)

diff --git a/drivers/hid/hid-debug.c b/drivers/hid/hid-debug.c
index 8bf61d2..4b2a18a 100644
--- a/drivers/hid/hid-debug.c
+++ b/drivers/hid/hid-debug.c
@@ -165,6 +165,7 @@ static const struct hid_usage_entry hid_usage_table[] = {
 {0, 0x53, "DeviceIndex"},
 {0, 0x54, "ContactCount"},
 {0, 0x55, "ContactMaximumNumber"},
+{0, 0x59, "ButtonType"},
 {0, 0x5A, "SecondaryBarrelSwitch"},
 {0, 0x5B, "TransducerSerialNumber"},
   { 15, 0, "PhysicalInterfaceDevice" },
diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
index f65e78b..b19d721 100644
--- a/drivers/hid/hid-multitouch.c
+++ b/drivers/hid/hid-multitouch.c
@@ -72,6 +72,10 @@ MODULE_LICENSE("GPL");
 #define MT_INPUTMODE_TOUCHSCREEN   0x02
 #define MT_INPUTMODE_TOUCHPAD  0x03
 
+#define MT_BUTTONTYPE_DEPRESSIBLE  0
+#define MT_BUTTONTYPE_NONDEPRESSIBLE   1
+#define MT_BUTTONTYPE_MAX  MT_BUTTONTYPE_NONDEPRESSIBLE
+
 struct mt_slot {
__s32 x, y, cx, cy, p, w, h;
__s32 contactid;/* the device ContactID assigned to this slot */
@@ -116,6 +120,7 @@ struct mt_device {
__u8 touches_by_report; /* how many touches are present in one report:
* 1 means we should use a serial protocol
* > 1 means hybrid (multitouch) protocol */
+   __u8 buttontype;/* depressible or non-depressible touchpad */
bool serial_maybe;  /* need to check for serial protocol */
bool curvalid;  /* is the current contact valid? */
unsigned mt_flags;  /* flags to pass to input-mt */
@@ -334,6 +339,16 @@ static void mt_feature_mapping(struct hid_device *hdev,
td->maxcontacts = td->mtclass.maxcontacts;
 
break;
+   case HID_DG_BUTTONTYPE:
+   if (usage->usage_index >= field->report_count) {
+   dev_err(>dev, "HID_DG_BUTTONTYPE out of range\n");
+   break;
+   }
+
+   if (field->value[usage->usage_index] <= MT_BUTTONTYPE_MAX)
+   td->buttontype = field->value[usage->usage_index];
+
+   break;
}
 }
 
@@ -728,6 +743,9 @@ static void mt_touch_input_configured(struct hid_device 
*hdev,
if (cls->quirks & MT_QUIRK_NOT_SEEN_MEANS_UP)
td->mt_flags |= INPUT_MT_DROP_UNUSED;
 
+   if (td->buttontype == MT_BUTTONTYPE_DEPRESSIBLE)
+   __set_bit(INPUT_PROP_BUTTONPAD, input->propbit);
+
input_mt_init_slots(input, td->maxcontacts, td->mt_flags);
 
td->mt_flags = 0;
@@ -1009,6 +1027,7 @@ static int mt_probe(struct hid_device *hdev, const struct 
hid_device_id *id)
td->inputmode_value = MT_INPUTMODE_TOUCHSCREEN;
td->cc_index = -1;
td->mt_report_id = -1;
+   td->buttontype = MT_BUTTONTYPE_NONDEPRESSIBLE;
hid_set_drvdata(hdev, td);
 
td->fields = devm_kzalloc(>dev, sizeof(struct mt_fields),
diff --git a/include/linux/hid.h b/include/linux/hid.h
index 06c4607..498ddad 100644
--- a/include/linux/hid.h
+++ b/include/linux/hid.h
@@ -269,6 +269,7 @@ struct hid_item {
 #define HID_DG_DEVICEINDEX 0x000d0053
 #define HID_DG_CONTACTCOUNT0x000d0054
 #define HID_DG_CONTACTMAX  0x000d0055
+#define HID_DG_BUTTONTYPE  0x000d0059
 #define HID_DG_BARRELSWITCH2   0x000d005a
 #define HID_DG_TOOLSERIALNUMBER0x000d005b
 
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH net-next] Driver: Vmxnet3: Copy TCP header to mapped frame for IPv6 packets

[Shrikrishna Khare]

On Sat, 28 Feb 2015, Sergei Shtylyov wrote:

> Hello.
> 
> On 02/28/2015 10:58 PM, Shrikrishna Khare wrote:
> 
> > Allows for packet parsing to be done by the fast path. This performance
> > optimization already exists for IPv4. Add similar logic for IPv6.
> 
> > Signed-off-by: Amitabha Banerjee 
> > Signed-off-by: Shrikrishna Khare 
> > ---
> >   drivers/net/vmxnet3/vmxnet3_drv.c | 26 --
> >   drivers/net/vmxnet3/vmxnet3_int.h |  5 +++--
> >   2 files changed, 19 insertions(+), 12 deletions(-)
> 
> > diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c
> > b/drivers/net/vmxnet3/vmxnet3_drv.c
> > index 294214c..9216e6a 100644
> > --- a/drivers/net/vmxnet3/vmxnet3_drv.c
> > +++ b/drivers/net/vmxnet3/vmxnet3_drv.c
> [...]
> > @@ -831,16 +832,20 @@ vmxnet3_parse_and_copy_hdr(struct sk_buff *skb, struct
> > vmxnet3_tx_queue *tq,
> > if (ctx->ipv4) {
> > const struct iphdr *iph = ip_hdr(skb);
> > 
> > -   if (iph->protocol == IPPROTO_TCP)
> > -   ctx->l4_hdr_size = tcp_hdrlen(skb);
> > -   else if (iph->protocol == IPPROTO_UDP)
> > -   ctx->l4_hdr_size = sizeof(struct
> > udphdr);
> > -   else
> > -   ctx->l4_hdr_size = 0;
> > -   } else {
> > -   /* for simplicity, don't copy L4 headers */
> > -   ctx->l4_hdr_size = 0;
> > +   protocol = iph->protocol;
> > +   } else if (ctx->ipv6) {
> > +   const struct ipv6hdr *ipv6h = ipv6_hdr(skb);
> > +
> > +   protocol = ipv6h->nexthdr;
> > }
> > +
> > +   if (protocol == IPPROTO_TCP)
> > +   ctx->l4_hdr_size = tcp_hdrlen(skb);
> > +   else if (protocol == IPPROTO_UDP)
> > +   ctx->l4_hdr_size = sizeof(struct udphdr);
> > +   else
> > +   ctx->l4_hdr_size = 0;
> > +
> 
>I think the above is asking to be a 'switch (protocol)' instead.
> 
> WBR, Sergei
> 
> 

Thanks for the review, Sergei. Would fix it, and resubmit the patch.

Thanks,
Shri
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 15/15] dt-bindings: Add documentation for Rockchip dw-hdmi-audio

[Yakir Yang]

Required properties:
- compatible: platform specific
- i2s-controller: the i2s controller device node

Signed-off-by: Yakir Yang 
---
Changes in v4: None
Changes in v3:
- modify cpu-of-node to i2s-controller

Changes in v2:
- remove codec-name and codec-dai-name
- rename rockchip,rockchip-hdmi-audio.txt to rockchip,rockchip-dw-hdmi-audio.txt

 .../bindings/sound/rockchip,rockchip-dw-hdmi-audio.txt   | 12 
 1 file changed, 12 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/sound/rockchip,rockchip-dw-hdmi-audio.txt

diff --git 
a/Documentation/devicetree/bindings/sound/rockchip,rockchip-dw-hdmi-audio.txt 
b/Documentation/devicetree/bindings/sound/rockchip,rockchip-dw-hdmi-audio.txt
new file mode 100644
index 000..f0d23c5
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/sound/rockchip,rockchip-dw-hdmi-audio.txt
@@ -0,0 +1,12 @@
+Rockchip hdmi audio bindings
+
+Required properties:
+- compatible: platform specific
+- i2s-controller: the i2s controller device node
+
+Example:
+
+sound {
+   compatible = "rockchip,rk3288-hdmi-audio";
+   i2s-controller = <>;
+};
-- 
2.1.2


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 14/15] ASoC: rockchip/rockchip-hdmi-audio: add sound driver for hdmi audio

[Yakir Yang]

Add a sound driver that combines rockchip-i2s cpu_dai and dw-hdmi-codec
as codec_dai to provide hdmi audio output on rk3288 platforms.

Signed-off-by: Yakir Yang 
---
Changes in v4:
- Add ".pm = _soc_pm_ops,"

Changes in v3:
- Delete the operation of jack in rockchip-hdmi-audio driver,
  get ready to switch to simple-audio-card driver.

Changes in v2:
- give "codec-name" & "codec-dai-name" an const name

 sound/soc/rockchip/Kconfig   |   9 ++
 sound/soc/rockchip/Makefile  |   2 +
 sound/soc/rockchip/rockchip_hdmi_audio.c | 169 +++
 3 files changed, 180 insertions(+)
 create mode 100644 sound/soc/rockchip/rockchip_hdmi_audio.c

diff --git a/sound/soc/rockchip/Kconfig b/sound/soc/rockchip/Kconfig
index e181826..ed2b7f0 100644
--- a/sound/soc/rockchip/Kconfig
+++ b/sound/soc/rockchip/Kconfig
@@ -14,3 +14,12 @@ config SND_SOC_ROCKCHIP_I2S
  Say Y or M if you want to add support for I2S driver for
  Rockchip I2S device. The device supports upto maximum of
  8 channels each for play and record.
+
+config SND_SOC_ROCKCHIP_HDMI_AUDIO
+   tristate "ASoC support for Rockchip HDMI audio"
+   depends on SND_SOC_ROCKCHIP
+   select SND_SOC_ROCKCHIP_I2S
+   select SND_SOC_DW_HDMI_AUDIO
+   help
+ Say Y or M here if you want to add support for SoC audio on Rockchip
+ HDMI, such as rk3288 hdmi.
diff --git a/sound/soc/rockchip/Makefile b/sound/soc/rockchip/Makefile
index b921909..b9185b3 100644
--- a/sound/soc/rockchip/Makefile
+++ b/sound/soc/rockchip/Makefile
@@ -1,4 +1,6 @@
 # ROCKCHIP Platform Support
 snd-soc-i2s-objs := rockchip_i2s.o
+snd-soc-rockchip-hdmi-audio-objs := rockchip_hdmi_audio.o
 
 obj-$(CONFIG_SND_SOC_ROCKCHIP_I2S) += snd-soc-i2s.o
+obj-$(CONFIG_SND_SOC_ROCKCHIP_HDMI_AUDIO) += snd-soc-rockchip-hdmi-audio.o
diff --git a/sound/soc/rockchip/rockchip_hdmi_audio.c 
b/sound/soc/rockchip/rockchip_hdmi_audio.c
new file mode 100644
index 000..cf95037
--- /dev/null
+++ b/sound/soc/rockchip/rockchip_hdmi_audio.c
@@ -0,0 +1,169 @@
+/*
+ * rockchip-hdmi-card.c
+ *
+ * ROCKCHIP ALSA SoC DAI driver for HDMI audio on rockchip processors.
+ * Copyright (c) 2014, ROCKCHIP CORPORATION. All rights reserved.
+ * Authors: Yakir Yang 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .*
+ *
+ */
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include "rockchip_i2s.h"
+
+#define DRV_NAME "rockchip-hdmi-audio"
+
+static int rockchip_hdmi_audio_hw_params(struct snd_pcm_substream *substream,
+   struct snd_pcm_hw_params *params)
+{
+   struct snd_soc_pcm_runtime *rtd = substream->private_data;
+   struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
+   unsigned int dai_fmt = rtd->dai_link->dai_fmt;
+   int mclk, ret;
+
+   switch (params_rate(params)) {
+   case 8000:
+   case 16000:
+   case 24000:
+   case 32000:
+   case 48000:
+   case 64000:
+   case 96000:
+   mclk = 12288000;
+   break;
+   case 11025:
+   case 22050:
+   case 44100:
+   case 88200:
+   mclk = 11289600;
+   break;
+   default:
+   return -EINVAL;
+   }
+
+   ret = snd_soc_dai_set_fmt(cpu_dai, dai_fmt);
+   if (ret < 0) {
+   dev_err(cpu_dai->dev, "failed to set cpu_dai fmt.\n");
+   return ret;
+   }
+
+   ret = snd_soc_dai_set_sysclk(cpu_dai, 0, mclk, SND_SOC_CLOCK_OUT);
+   if (ret < 0) {
+   dev_err(cpu_dai->dev, "failed to set cpu_dai sysclk.\n");
+   return ret;
+   }
+
+   return 0;
+}
+
+static struct snd_soc_ops hdmi_audio_dai_ops = {
+   .hw_params = rockchip_hdmi_audio_hw_params,
+};
+
+static struct snd_soc_dai_link hdmi_audio_dai = {
+   .name = "RockchipHDMI",
+   .stream_name = "RockchipHDMI",
+   .codec_name = "dw-hdmi-audio",
+   .codec_dai_name = "dw-hdmi-hifi",
+   .ops = _audio_dai_ops,
+   .dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF |
+  SND_SOC_DAIFMT_CBS_CFS,
+};
+
+static struct snd_soc_card rockchip_hdmi_audio_card = {
+   .name = "RockchipHDMI",
+   .owner = THIS_MODULE,
+   .dai_link = _audio_dai,
+   .num_links = 1,
+};
+
+static int rockchip_hdmi_audio_probe(struct platform_device *pdev)
+{
+   struct snd_soc_card *card = _hdmi_audio_card;
+ 

[PATCH v4 13/15] ASoC: codec/dw-hdmi-audio: add codec driver for dw hdmi audio

[Yakir Yang]

codec driver creat an standard alsa device, than config audio
and report jack status through some callback interfaces that
dw_hdmi driver support.

Signed-off-by: Yakir Yang 
---
Changes in v4:
- Replace delaywork with irq thread, and add suspend/resume interfaces,
  Replace "dw-hdmi-audio" with consecutive strings.

Changes in v3:
- Keep audio format config function in dw-hdmi-audio driver
  and remove audio_config & get_connect_status functions,
  move jack control to dw-hdmi-audio completely.

Changes in v2:
- Update dw_hdmi audio control interfaces, and adjust jack report process

 sound/soc/codecs/Kconfig |   4 +
 sound/soc/codecs/Makefile|   2 +
 sound/soc/codecs/dw-hdmi-audio.c | 379 +++
 sound/soc/codecs/dw-hdmi-audio.h |  74 
 4 files changed, 459 insertions(+)
 create mode 100644 sound/soc/codecs/dw-hdmi-audio.c
 create mode 100644 sound/soc/codecs/dw-hdmi-audio.h

diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 8349f98..b34dd12 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -75,6 +75,7 @@ config SND_SOC_ALL_CODECS
select SND_SOC_MC13783 if MFD_MC13XXX
select SND_SOC_ML26124 if I2C
select SND_SOC_HDMI_CODEC
+   select SND_SOC_DW_HDMI_AUDIO
select SND_SOC_PCM1681 if I2C
select SND_SOC_PCM1792A if SPI_MASTER
select SND_SOC_PCM3008
@@ -459,6 +460,9 @@ config SND_SOC_MAX98095
 config SND_SOC_MAX9850
tristate
 
+config SND_SOC_DW_HDMI_AUDIO
+   tristate
+
 config SND_SOC_PCM1681
tristate "Texas Instruments PCM1681 CODEC"
depends on I2C
diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
index bbdfd1e..0ebb664 100644
--- a/sound/soc/codecs/Makefile
+++ b/sound/soc/codecs/Makefile
@@ -68,6 +68,7 @@ snd-soc-max9850-objs := max9850.o
 snd-soc-mc13783-objs := mc13783.o
 snd-soc-ml26124-objs := ml26124.o
 snd-soc-hdmi-codec-objs := hdmi.o
+snd-soc-dw-hdmi-audio-objs := dw-hdmi-audio.o
 snd-soc-pcm1681-objs := pcm1681.o
 snd-soc-pcm1792a-codec-objs := pcm1792a.o
 snd-soc-pcm3008-objs := pcm3008.o
@@ -249,6 +250,7 @@ obj-$(CONFIG_SND_SOC_MAX9850)   += snd-soc-max9850.o
 obj-$(CONFIG_SND_SOC_MC13783)  += snd-soc-mc13783.o
 obj-$(CONFIG_SND_SOC_ML26124)  += snd-soc-ml26124.o
 obj-$(CONFIG_SND_SOC_HDMI_CODEC) += snd-soc-hdmi-codec.o
+obj-$(CONFIG_SND_SOC_DW_HDMI_AUDIO) += snd-soc-dw-hdmi-audio.o
 obj-$(CONFIG_SND_SOC_PCM1681)  += snd-soc-pcm1681.o
 obj-$(CONFIG_SND_SOC_PCM1792A) += snd-soc-pcm1792a-codec.o
 obj-$(CONFIG_SND_SOC_PCM3008)  += snd-soc-pcm3008.o
diff --git a/sound/soc/codecs/dw-hdmi-audio.c b/sound/soc/codecs/dw-hdmi-audio.c
new file mode 100644
index 000..352a4c3
--- /dev/null
+++ b/sound/soc/codecs/dw-hdmi-audio.c
@@ -0,0 +1,379 @@
+/*
+ * dw-hdmi-codec.c
+ *
+ * DesignerWare ALSA SoC DAI driver for DW HDMI audio.
+ * Copyright (c) 2014,  CORPORATION. All rights reserved.
+ * Authors: Yakir Yang 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .*
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include "dw-hdmi-audio.h"
+
+#define DRV_NAME "dw-hdmi-audio"
+
+struct snd_dw_hdmi {
+   struct device *dev;
+   struct dw_hdmi_audio_data data;
+
+   u8 jack_status;
+   bool is_jack_ready;
+   struct snd_soc_jack jack;
+
+   bool is_playback_status;
+   struct hdmi_audio_fmt fmt;
+};
+
+int snd_dw_hdmi_jack_detect(struct snd_dw_hdmi *hdmi)
+{
+   u8 jack_status;
+
+   if (!hdmi->is_jack_ready)
+   return -EINVAL;
+
+   jack_status = !!(hdmi->data.read(hdmi->data.dw, HDMI_PHY_STAT0)&
+ HDMI_PHY_HPD) ? SND_JACK_LINEOUT : 0;
+
+   if (jack_status != hdmi->jack_status) {
+   snd_soc_jack_report(>jack, jack_status,
+   SND_JACK_LINEOUT);
+   hdmi->jack_status = jack_status;
+
+   dev_info(hdmi->dev, "jack report [%d]\n", hdmi->jack_status);
+   }
+
+   return 0;
+}
+
+/* we don't want this irq mark with IRQF_ONESHOT flags,
+ * so we build an irq_default_primary_handler here */
+static irqreturn_t snd_dw_hdmi_hardirq(int irq, void *dev_id)
+{
+   return IRQ_WAKE_THREAD;
+}
+
+static irqreturn_t snd_dw_hdmi_irq(int irq, void *dev_id)
+{
+   struct snd_dw_hdmi *hdmi = dev_id;
+
+   

[PATCH v4 12/15] drm: bridge/dw_hdmi: creat dw-hdmi-audio platform device

[Yakir Yang]

creat dw-hdmi-audio device dynamically in probe function,
and transfer some interfaces to dw-hdmi-audio driver for
setting hdmi audio format & control hdmi audio clock.

Signed-off-by: Yakir Yang 
---
Changes in v4: None
Changes in v3:
- Remove audio_config & get_connect_status callback functions
  and add write/read/mod register callback functions

Changes in v2:
- Update the audio control interfaces

 drivers/gpu/drm/bridge/dw_hdmi.c | 29 +
 include/drm/bridge/dw_hdmi.h | 15 +++
 2 files changed, 44 insertions(+)

diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index 54185e2..2ffd3e7 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -125,6 +125,8 @@ struct dw_hdmi {
struct drm_encoder *encoder;
struct drm_bridge *bridge;
 
+   struct platform_device *audio_pdev;
+
enum dw_hdmi_devtype dev_type;
struct device *dev;
struct clk *isfr_clk;
@@ -512,6 +514,12 @@ static void hdmi_clk_regenerator_update_pixel_clock(struct 
dw_hdmi *hdmi)
hdmi_set_clk_regenerator(hdmi, hdmi->hdmi_data.video_mode.mpixelclock);
 }
 
+static void hdmi_set_sample_rate(struct dw_hdmi *hdmi, unsigned int 
sample_rate)
+{
+   hdmi->sample_rate = sample_rate;
+   hdmi_set_clk_regenerator(hdmi, hdmi->hdmi_data.video_mode.mpixelclock);
+}
+
 /*
  * this submodule is responsible for the video data synchronization.
  * for example, for RGB 4:4:4 input, the data map is defined as
@@ -1801,6 +1809,8 @@ int dw_hdmi_bind(struct device *dev, struct device 
*master,
 struct resource *iores, int irq,
 const struct dw_hdmi_plat_data *plat_data)
 {
+   struct platform_device_info pdevinfo;
+   struct dw_hdmi_audio_data audio;
struct drm_device *drm = data;
struct device_node *np = dev->of_node;
struct device_node *ddc_node;
@@ -1920,6 +1930,25 @@ int dw_hdmi_bind(struct device *dev, struct device 
*master,
 
dev_set_drvdata(dev, hdmi);
 
+   memset(, 0, sizeof(pdevinfo));
+   pdevinfo.parent = dev;
+   pdevinfo.id = PLATFORM_DEVID_NONE;
+
+   audio.irq = irq;
+   audio.dw = hdmi;
+   audio.mod = hdmi_modb;
+   audio.read = hdmi_readb;
+   audio.write = hdmi_writeb;
+   audio.enable = dw_hdmi_audio_enable;
+   audio.disable = dw_hdmi_audio_disable;
+   audio.set_sample_rate = hdmi_set_sample_rate;
+
+   pdevinfo.name = "dw-hdmi-audio";
+   pdevinfo.data = 
+   pdevinfo.size_data = sizeof(audio);
+   pdevinfo.dma_mask = DMA_BIT_MASK(32);
+   hdmi->audio_pdev = platform_device_register_full();
+
return 0;
 
 err_iahb:
diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
index e8cfe1c..23ca491 100644
--- a/include/drm/bridge/dw_hdmi.h
+++ b/include/drm/bridge/dw_hdmi.h
@@ -12,6 +12,8 @@
 
 #include 
 
+struct dw_hdmi;
+
 enum {
DW_HDMI_RES_8,
DW_HDMI_RES_10,
@@ -44,6 +46,19 @@ struct dw_hdmi_sym_term {
u16 term;   /*transmission termination value*/
 };
 
+struct dw_hdmi_audio_data {
+   int irq;
+   struct dw_hdmi *dw;
+
+   u8 (*read)(struct dw_hdmi *hdmi, int offset);
+   void (*write)(struct dw_hdmi *hdmi, u8 val, int offset);
+   void (*mod)(struct dw_hdmi *hdmi, u8 data, u8 mask, unsigned reg);
+
+   void (*enable)(struct dw_hdmi *hdmi);
+   void (*disable)(struct dw_hdmi *hdmi);
+   void (*set_sample_rate)(struct dw_hdmi *hdmi, unsigned int rate);
+};
+
 struct dw_hdmi_plat_data {
enum dw_hdmi_devtype dev_type;
const struct dw_hdmi_mpll_config *mpll_cfg;
-- 
2.1.2


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 11/15] drm: bridge/dw_hdmi: add enable/disable to dw_hdmi_audio callbacks

[Yakir Yang]

Add enable and disable callbacks to dw_hdmi_audio interface so that
dw_hdmi_audio can enable and disable the dw_hdmi audio.

Signed-off-by: Yakir Yang 
---
Changes in v4:
- Rename "hdmi_audio_*" to "dw_hdmi_audio_*"

Changes in v3:
- Delete hdmi_audio_config interface and modify audio clock control functions

Changes in v2:
- Add audio config interfaces to dw_hdmi driver

 drivers/gpu/drm/bridge/dw_hdmi.c | 62 
 1 file changed, 56 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index 16b8098..54185e2 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -147,6 +148,11 @@ struct dw_hdmi {
void __iomem *regs;
 
unsigned int sample_rate;
+
+   /* this audio mutex works for audio clock control */
+   struct mutex audio_mutex;
+   bool audio_enable;
+
int ratio;
 
void (*write)(struct dw_hdmi *hdmi, u8 val, int offset);
@@ -1245,6 +1251,53 @@ static void dw_hdmi_phy_disable(struct dw_hdmi *hdmi)
hdmi->phy_enabled = false;
 }
 
+static void dw_dw_hdmi_audio_clk_enable(struct dw_hdmi *hdmi)
+{
+   hdmi_modb(hdmi, 0, HDMI_MC_CLKDIS_AUDCLK_DISABLE, HDMI_MC_CLKDIS);
+}
+
+static void dw_dw_hdmi_audio_clk_disable(struct dw_hdmi *hdmi)
+{
+   hdmi_modb(hdmi, HDMI_MC_CLKDIS_AUDCLK_DISABLE,
+ HDMI_MC_CLKDIS_AUDCLK_DISABLE, HDMI_MC_CLKDIS);
+}
+
+static void dw_hdmi_audio_restore(struct dw_hdmi *hdmi)
+{
+   mutex_lock(>audio_mutex);
+
+   if (hdmi->audio_enable)
+   dw_dw_hdmi_audio_clk_enable(hdmi);
+   else
+   dw_dw_hdmi_audio_clk_disable(hdmi);
+
+   mutex_unlock(>audio_mutex);
+}
+
+static void dw_hdmi_audio_enable(struct dw_hdmi *hdmi)
+{
+   mutex_lock(>audio_mutex);
+
+   if (!hdmi->audio_enable) {
+   hdmi->audio_enable = true;
+   dw_dw_hdmi_audio_clk_enable(hdmi);
+   }
+
+   mutex_unlock(>audio_mutex);
+}
+
+static void dw_hdmi_audio_disable(struct dw_hdmi *hdmi)
+{
+   mutex_lock(>audio_mutex);
+
+   if (hdmi->audio_enable) {
+   hdmi->audio_enable = false;
+   dw_dw_hdmi_audio_clk_disable(hdmi);
+   }
+
+   mutex_unlock(>audio_mutex);
+}
+
 /* HDMI Initialization Step B.4 */
 static void dw_hdmi_enable_video_path(struct dw_hdmi *hdmi)
 {
@@ -1275,11 +1328,6 @@ static void dw_hdmi_enable_video_path(struct dw_hdmi 
*hdmi)
}
 }
 
-static void hdmi_enable_audio_clk(struct dw_hdmi *hdmi)
-{
-   hdmi_modb(hdmi, 0, HDMI_MC_CLKDIS_AUDCLK_DISABLE, HDMI_MC_CLKDIS);
-}
-
 /* Workaround to clear the overflow condition */
 static void dw_hdmi_clear_overflow(struct dw_hdmi *hdmi)
 {
@@ -1375,7 +1423,7 @@ static int dw_hdmi_setup(struct dw_hdmi *hdmi, struct 
drm_display_mode *mode)
 
/* HDMI Initialization Step E - Configure audio */
hdmi_clk_regenerator_update_pixel_clock(hdmi);
-   hdmi_enable_audio_clk(hdmi);
+   dw_hdmi_audio_restore(hdmi);
 
/* HDMI Initialization Step F - Configure AVI InfoFrame */
hdmi_config_AVI(hdmi);
@@ -1770,6 +1818,8 @@ int dw_hdmi_bind(struct device *dev, struct device 
*master,
hdmi->sample_rate = 48000;
hdmi->ratio = 100;
hdmi->encoder = encoder;
+   hdmi->audio_enable = false;
+   mutex_init(>audio_mutex);
 
of_property_read_u32(np, "reg-io-width", );
 
-- 
2.1.2


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 10/15] drm: bridge/dw_hdmi: add audio sample channel status setting

[Yakir Yang]

From: Daniel Kurtz 

When transmitting IEC60985 linear PCM audio, we configure the
Audio Sample Channel Status information of all the channel
status bits in the IEC60958 frame.

Signed-off-by: Yakir Yang 
---
Changes in v4:
- Give HDMI_FC_AUD_SCHNL8 an readable value

Changes in v3:
- Determine whether sample channel should set by desig_id.

Changes in v2:
- Add audio sample channel status setting

 drivers/gpu/drm/bridge/dw_hdmi.c | 51 
 drivers/gpu/drm/bridge/dw_hdmi.h | 20 
 2 files changed, 71 insertions(+)

diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index 8894e48..16b8098 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -197,6 +197,55 @@ static void hdmi_mask_writeb(struct dw_hdmi *hdmi, u8 
data, unsigned int reg,
hdmi_modb(hdmi, data << shift, mask, reg);
 }
 
+static void hdmi_set_schnl(struct dw_hdmi *hdmi)
+{
+   u8 aud_schnl_samplerate;
+   u8 aud_schnl_8;
+
+   if (hdmi->id.design != 0x20)
+   return;
+
+   switch (hdmi->sample_rate) {
+   case 32000:
+   aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_32K;
+   break;
+   case 44100:
+   aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_44K1;
+   break;
+   case 48000:
+   aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_48K;
+   break;
+   case 88200:
+   aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_88K2;
+   break;
+   case 96000:
+   aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_96K;
+   break;
+   case 176400:
+   aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_176K4;
+   break;
+   case 192000:
+   aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_192K;
+   break;
+   case 768000:
+   aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_768K;
+   break;
+   default:
+   dev_warn(hdmi->dev, "Unsupported audio sample rate (%u)\n",
+   hdmi->sample_rate);
+   return;
+   }
+
+   /* set channel status register */
+   hdmi_modb(hdmi, aud_schnl_samplerate, HDMI_FC_AUDSCHNLS7_SMPRATE_MASK,
+ HDMI_FC_AUDSCHNLS7);
+
+   aud_schnl_8 = (~aud_schnl_samplerate) <<
+   HDMI_FC_AUDSCHNLS8_ORIGSAMPFREQ_OFFSET;
+   aud_schnl_8 |= 2 << HDMI_FC_AUDSCHNLS8_WORDLEGNTH_OFFSET;
+   hdmi_writeb(hdmi, aud_schnl_8, HDMI_FC_AUDSCHNLS8);
+}
+
 static void hdmi_set_clock_regenerator(struct dw_hdmi *hdmi,
   unsigned int n, unsigned int cts)
 {
@@ -443,6 +492,8 @@ static void hdmi_set_clk_regenerator(struct dw_hdmi *hdmi,
pixel_clk, clk_n, clk_cts);
 
hdmi_set_clock_regenerator(hdmi, clk_n, clk_cts);
+
+   hdmi_set_schnl(hdmi);
 }
 
 static void hdmi_init_clk_regenerator(struct dw_hdmi *hdmi)
diff --git a/drivers/gpu/drm/bridge/dw_hdmi.h b/drivers/gpu/drm/bridge/dw_hdmi.h
index 8e5ad50..23a5a62 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.h
+++ b/drivers/gpu/drm/bridge/dw_hdmi.h
@@ -162,6 +162,17 @@
 #define HDMI_FC_SPDDEVICEINF0x1062
 #define HDMI_FC_AUDSCONF0x1063
 #define HDMI_FC_AUDSSTAT0x1064
+#define HDMI_FC_AUDSV   0x1065
+#define HDMI_FC_AUDSU   0x1066
+#define HDMI_FC_AUDSCHNLS0  0x1067
+#define HDMI_FC_AUDSCHNLS1  0x1068
+#define HDMI_FC_AUDSCHNLS2  0x1069
+#define HDMI_FC_AUDSCHNLS3  0x106a
+#define HDMI_FC_AUDSCHNLS4  0x106b
+#define HDMI_FC_AUDSCHNLS5  0x106c
+#define HDMI_FC_AUDSCHNLS6  0x106d
+#define HDMI_FC_AUDSCHNLS7  0x106e
+#define HDMI_FC_AUDSCHNLS8  0x106f
 #define HDMI_FC_DATACH0FILL 0x1070
 #define HDMI_FC_DATACH1FILL 0x1071
 #define HDMI_FC_DATACH2FILL 0x1072
@@ -754,6 +765,15 @@ enum {
 /* HDMI_FC_AUDSCHNLS7 field values */
HDMI_FC_AUDSCHNLS7_ACCURACY_OFFSET = 4,
HDMI_FC_AUDSCHNLS7_ACCURACY_MASK = 0x30,
+   HDMI_FC_AUDSCHNLS7_SMPRATE_MASK = 0x0f,
+   HDMI_FC_AUDSCHNLS7_SMPRATE_192K = 0xe,
+   HDMI_FC_AUDSCHNLS7_SMPRATE_176K4 = 0xc,
+   HDMI_FC_AUDSCHNLS7_SMPRATE_96K = 0xa,
+   HDMI_FC_AUDSCHNLS7_SMPRATE_768K = 0x9,
+   HDMI_FC_AUDSCHNLS7_SMPRATE_88K2 = 0x8,
+   HDMI_FC_AUDSCHNLS7_SMPRATE_32K = 0x3,
+   HDMI_FC_AUDSCHNLS7_SMPRATE_48K = 0x2,
+   HDMI_FC_AUDSCHNLS7_SMPRATE_44K1 = 0x0,
 
 /* HDMI_FC_AUDSCHNLS8 field values */
HDMI_FC_AUDSCHNLS8_ORIGSAMPFREQ_MASK = 0xf0,
-- 
2.1.2


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a 

[PATCH v4 09/15] drm: bridge/dw_hdmi: enable audio support for No-CEA display resolutions

[Yakir Yang]

If the monitor support audio, so we should support audio for it, even if
the display resolution is No-CEA mode.

Signed-off-by: Yakir Yang 
---
Changes in v4:
- Add hdmi audio support when monitor support audio

Changes in v3: None
Changes in v2:
- Enable audio support for No-CEA display mode

 drivers/gpu/drm/bridge/dw_hdmi.c | 18 ++
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index b34ae80..8894e48 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -98,6 +98,7 @@ struct hdmi_id {
 
 struct hdmi_vmode {
bool mdvi;
+   bool has_audio;
bool mhsyncpolarity;
bool mvsyncpolarity;
bool minterlaced;
@@ -1267,13 +1268,10 @@ static int dw_hdmi_setup(struct dw_hdmi *hdmi, struct 
drm_display_mode *mode)
 
hdmi->vic = drm_match_cea_mode(mode);
 
-   if (!hdmi->vic) {
+   if (!hdmi->vic)
dev_dbg(hdmi->dev, "Non-CEA mode used in HDMI\n");
-   hdmi->hdmi_data.video_mode.mdvi = true;
-   } else {
+   else
dev_dbg(hdmi->dev, "CEA mode used vic=%d\n", hdmi->vic);
-   hdmi->hdmi_data.video_mode.mdvi = false;
-   }
 
if ((hdmi->vic == 6) || (hdmi->vic == 7) ||
(hdmi->vic == 21) || (hdmi->vic == 22) ||
@@ -1319,10 +1317,10 @@ static int dw_hdmi_setup(struct dw_hdmi *hdmi, struct 
drm_display_mode *mode)
dw_hdmi_enable_video_path(hdmi);
 
/* not for DVI mode */
-   if (hdmi->hdmi_data.video_mode.mdvi) {
-   dev_dbg(hdmi->dev, "%s DVI mode\n", __func__);
+   if (!hdmi->hdmi_data.video_mode.has_audio) {
+   dev_info(hdmi->dev, "monitor does not support audio\n");
} else {
-   dev_dbg(hdmi->dev, "%s CEA mode\n", __func__);
+   dev_dbg(hdmi->dev, "monitor support audio\n");
 
/* HDMI Initialization Step E - Configure audio */
hdmi_clk_regenerator_update_pixel_clock(hdmi);
@@ -1541,6 +1539,7 @@ static int dw_hdmi_connector_get_modes(struct 
drm_connector *connector)
 {
struct dw_hdmi *hdmi = container_of(connector, struct dw_hdmi,
 connector);
+   struct hdmi_vmode *vmode = >hdmi_data.video_mode;
struct edid *edid;
int ret;
 
@@ -1552,6 +1551,9 @@ static int dw_hdmi_connector_get_modes(struct 
drm_connector *connector)
dev_dbg(hdmi->dev, "got edid: width[%d] x height[%d]\n",
edid->width_cm, edid->height_cm);
 
+   vmode->mdvi = !drm_detect_hdmi_monitor(edid);
+   vmode->has_audio = drm_detect_monitor_audio(edid);
+
drm_mode_connector_update_edid_property(connector, edid);
ret = drm_add_edid_modes(connector, edid);
kfree(edid);
-- 
2.1.2


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 08/15] drm: bridge/dw_hdmi: add audio support for more display resolutions

[Yakir Yang]

Add more n/cts values, in that case we can support audio for more
display resolutions (128 * SampleRate = PixelClock * N / CTS).

Signed-off-by: Yakir Yang 
---
Changes in v4: None
Changes in v3: None
Changes in v2:
- add more n/cts combinations for more display resolutions

 drivers/gpu/drm/bridge/dw_hdmi.c | 58 
 1 file changed, 58 insertions(+)

diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index 001e5ab..b34ae80 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -247,8 +247,24 @@ static unsigned int hdmi_compute_n(unsigned int freq, 
unsigned long pixel_clk,
case 44100:
if (pixel_clk == 2517)
n = 7007;
+   else if (pixel_clk == 25175000)
+   n = 28224;
+   else if (pixel_clk == 4000)
+   n = 7056;
+   else if (pixel_clk == 5400)
+   n = 6272;
+   else if (pixel_clk == 6500)
+   n = 7056;
else if (pixel_clk == 7417)
n = 17836;
+   else if (pixel_clk == 7425)
+   n = 6272;
+   else if (pixel_clk == 8350)
+   n = 7056;
+   else if (pixel_clk == 10650)
+   n = 4074;
+   else if (pixel_clk == 10800)
+   n = 4018;
else if (pixel_clk == 14835)
n = (ratio == 150) ? 17836 : 8918;
else
@@ -258,10 +274,26 @@ static unsigned int hdmi_compute_n(unsigned int freq, 
unsigned long pixel_clk,
case 48000:
if (pixel_clk == 2517)
n = (ratio == 150) ? 9152 : 6864;
+   else if (pixel_clk == 25175000)
+   n = 12288;
else if (pixel_clk == 2702)
n = (ratio == 150) ? 8192 : 6144;
+   else if (pixel_clk == 4000)
+   n = 6144;
+   else if (pixel_clk == 5400)
+   n = 6144;
+   else if (pixel_clk == 6500)
+   n = 6144;
else if (pixel_clk == 7417)
n = 11648;
+   else if (pixel_clk == 7425)
+   n = 6144;
+   else if (pixel_clk == 8350)
+   n = 6144;
+   else if (pixel_clk == 10650)
+   n = 6144;
+   else if (pixel_clk == 10800)
+   n = 6144;
else if (pixel_clk == 14835)
n = (ratio == 150) ? 11648 : 5824;
else
@@ -309,10 +341,18 @@ static unsigned int hdmi_compute_cts(unsigned int freq, 
unsigned long pixel_clk,
case 96000:
case 192000:
switch (pixel_clk) {
+   case 25175000:
+   cts = 50350;
+   break;
case 2520:
case 2700:
+   case 4000:
case 5400:
+   case 6500:
case 7425:
+   case 8350:
+   case 10650:
+   case 10800:
case 14850:
cts = pixel_clk / 1000;
break;
@@ -333,18 +373,36 @@ static unsigned int hdmi_compute_cts(unsigned int freq, 
unsigned long pixel_clk,
case 88200:
case 176400:
switch (pixel_clk) {
+   case 25175000:
+   cts = 125875;
+   break;
case 2520:
cts = 28000;
break;
case 2700:
cts = 3;
break;
+   case 4000:
+   cts = 5;
+   break;
case 5400:
cts = 6;
break;
+   case 6500:
+   cts = 81250;
+   break;
case 7425:
cts = 82500;
break;
+   case 8350:
+   cts = 104375;
+   break;
+   case 10650:
+   cts = 88750;
+   break;
+   case 10800:
+   cts = 76875;
+   break;
case 14850:
cts = 165000;
break;
-- 
2.1.2


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  

[PATCH v4 07/15] drm: bridge/dw_hdmi: set ncts_atomic_write & cts_manual

[Yakir Yang]

From: Daniel Kurtz 

The ncts_atomic_write & cts_manual bits are present when design id
equal to 0x20.

After setting ncts_atomic_write, new N and CTS values are only used when
aud_n1 register is updated.

After setting cts_manual, new CTS value can set by AUD_CTS registers.

Signed-off-by: Yakir Yang 
---
Changes in v4:
- Combine N3 registers setting

Changes in v3:
- Set ncts_atomic_write & cts_manual

Changes in v2: None

 drivers/gpu/drm/bridge/dw_hdmi.c | 10 +-
 drivers/gpu/drm/bridge/dw_hdmi.h |  4 
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index 12d8b7e..001e5ab 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -199,8 +199,15 @@ static void hdmi_mask_writeb(struct dw_hdmi *hdmi, u8 
data, unsigned int reg,
 static void hdmi_set_clock_regenerator(struct dw_hdmi *hdmi,
   unsigned int n, unsigned int cts)
 {
+   u8 n3 = 0;
u8 cts3 = 0;
 
+   /* First set NCTS_ATOMIC_WRITE (if present) */
+   if (hdmi->id.design == 0x20) {
+   n3 = HDMI_AUD_N3_NCTS_ATOMIC_WRITE;
+   hdmi_writeb(hdmi, n3, HDMI_AUD_N3);
+   }
+
/* set CTS_MANUAL (if present) */
if (hdmi->id.design == 0x20)
cts3 = HDMI_AUD_CTS3_CTS_MANUAL;
@@ -214,7 +221,8 @@ static void hdmi_set_clock_regenerator(struct dw_hdmi *hdmi,
hdmi_writeb(hdmi, cts & 0xff, HDMI_AUD_CTS1);
 
/* write N values; N1 must be written last */
-   hdmi_writeb(hdmi, (n >> 16) & 0xf, HDMI_AUD_N3);
+   n3 |= (n >> 16) & HDMI_AUD_N3_AUDN19_16_MASK;
+   hdmi_writeb(hdmi, n3, HDMI_AUD_N3);
hdmi_writeb(hdmi, (n >> 8) & 0xff, HDMI_AUD_N2);
hdmi_writeb(hdmi, n & 0xff, HDMI_AUD_N1);
 }
diff --git a/drivers/gpu/drm/bridge/dw_hdmi.h b/drivers/gpu/drm/bridge/dw_hdmi.h
index c7ac538..8e5ad50 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.h
+++ b/drivers/gpu/drm/bridge/dw_hdmi.h
@@ -907,6 +907,10 @@ enum {
HDMI_PHY_I2CM_CTLINT_ADDR_ARBITRATION_POL = 0x08,
HDMI_PHY_I2CM_CTLINT_ADDR_ARBITRATION_MASK = 0x04,
 
+/* AUD_N3 field values */
+   HDMI_AUD_N3_NCTS_ATOMIC_WRITE = 0x80,
+   HDMI_AUD_N3_AUDN19_16_MASK = 0x0f,
+
 /* AUD_CTS3 field values */
HDMI_AUD_CTS3_N_SHIFT_OFFSET = 5,
HDMI_AUD_CTS3_N_SHIFT_MASK = 0xe0,
-- 
2.1.2


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 06/15] drm: bridge/dw_hdmi: adjust n/cts setting order

[Yakir Yang]

From: Daniel Kurtz 

This patch changes the order to:
- write CTS3 CTS_manual (if supported) | N_shift | CTS[19:16]
- write CTS2 CTS[15:8]
- write CTS1 CTS[7:0]
- write N3 N[19:16]
- write N2 N[15:8]
- write N1 N[7:0]

Signed-off-by: Yakir Yang 
Signed-off-by: Daniel Kurtz 
---
Changes in v4:
- Combine CTS3 registers setting, reduce register operate times

Changes in v3:
- Only adjust the n/cts setting order

Changes in v2: None

 drivers/gpu/drm/bridge/dw_hdmi.c | 25 +++--
 drivers/gpu/drm/bridge/dw_hdmi.h |  6 --
 2 files changed, 19 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index 3d7c048..12d8b7e 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -199,19 +199,24 @@ static void hdmi_mask_writeb(struct dw_hdmi *hdmi, u8 
data, unsigned int reg,
 static void hdmi_set_clock_regenerator(struct dw_hdmi *hdmi,
   unsigned int n, unsigned int cts)
 {
-   hdmi_writeb(hdmi, n & 0xff, HDMI_AUD_N1);
-   hdmi_writeb(hdmi, (n >> 8) & 0xff, HDMI_AUD_N2);
-   hdmi_writeb(hdmi, (n >> 16) & 0x0f, HDMI_AUD_N3);
+   u8 cts3 = 0;
 
-   /* nshift factor = 0 */
-   hdmi_modb(hdmi, 0, HDMI_AUD_CTS3_N_SHIFT_MASK, HDMI_AUD_CTS3);
-   /* Must be set/cleared first */
-   hdmi_modb(hdmi, 0, HDMI_AUD_CTS3_CTS_MANUAL, HDMI_AUD_CTS3);
+   /* set CTS_MANUAL (if present) */
+   if (hdmi->id.design == 0x20)
+   cts3 = HDMI_AUD_CTS3_CTS_MANUAL;
 
-   hdmi_writeb(hdmi, cts & 0xff, HDMI_AUD_CTS1);
+   cts3 |= HDMI_AUD_CTS3_N_SHIFT_1 << HDMI_AUD_CTS3_N_SHIFT_OFFSET;
+   cts3 |= (cts >> 16) & HDMI_AUD_CTS3_AUDCTS19_16_MASK;
+
+   /* write CTS values; CTS3 must be written first */
+   hdmi_writeb(hdmi, cts3, HDMI_AUD_CTS3);
hdmi_writeb(hdmi, (cts >> 8) & 0xff, HDMI_AUD_CTS2);
-   hdmi_writeb(hdmi, ((cts >> 16) & HDMI_AUD_CTS3_AUDCTS19_16_MASK) |
-   HDMI_AUD_CTS3_CTS_MANUAL, HDMI_AUD_CTS3);
+   hdmi_writeb(hdmi, cts & 0xff, HDMI_AUD_CTS1);
+
+   /* write N values; N1 must be written last */
+   hdmi_writeb(hdmi, (n >> 16) & 0xf, HDMI_AUD_N3);
+   hdmi_writeb(hdmi, (n >> 8) & 0xff, HDMI_AUD_N2);
+   hdmi_writeb(hdmi, n & 0xff, HDMI_AUD_N1);
 }
 
 static unsigned int hdmi_compute_n(unsigned int freq, unsigned long pixel_clk,
diff --git a/drivers/gpu/drm/bridge/dw_hdmi.h b/drivers/gpu/drm/bridge/dw_hdmi.h
index e4ba634..c7ac538 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.h
+++ b/drivers/gpu/drm/bridge/dw_hdmi.h
@@ -916,8 +916,10 @@ enum {
HDMI_AUD_CTS3_N_SHIFT_64 = 0x60,
HDMI_AUD_CTS3_N_SHIFT_128 = 0x80,
HDMI_AUD_CTS3_N_SHIFT_256 = 0xa0,
-   /* note that the CTS3 MANUAL bit has been removed
-  from our part. Can't set it, will read as 0. */
+   /*
+* Note: CTS_MANUAL is not present on iMX6 dw_hdmi, but is present on
+* rk3288 (design_id = 0x20).
+*/
HDMI_AUD_CTS3_CTS_MANUAL = 0x10,
HDMI_AUD_CTS3_AUDCTS19_16_MASK = 0x0f,
 
-- 
2.1.2


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/8] x86, kaslr: get kaslr_enabled back correctly

[Yinghai Lu]

On Sat, Feb 28, 2015 at 6:17 PM, Yinghai Lu  wrote:
> We should access variable with referrence instead of using physical
> address as value.
>
> Cc: Matt Fleming 
> Cc: Borislav Petkov 
> Signed-off-by: Yinghai Lu 
> ---
>  arch/x86/kernel/setup.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index 98dc931..05d444f 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -429,7 +429,13 @@ static void __init reserve_initrd(void)
>
>  static void __init parse_kaslr_setup(u64 pa_data, u32 data_len)
>  {
> -   kaslr_enabled = (bool)(pa_data + sizeof(struct setup_data));
> +   /* kaslr_setup_data is defined in aslr.c */
> +   unsigned char *data;
> +   unsigned long offset = sizeof(struct setup_data);
> +
> +   data = early_memremap(pa_data, offset + 1);
> +   kaslr_enabled = *(data + offset);
> +   early_memunmap(data, offset + 1);
>  }
>
>  static void __init parse_setup_data(void)
> --

oh, no. the offending commit already got into linus tree.

commit f47233c2d34f243ecdaac179c3408a39ff9216a7
Author: Jiri Kosina 
Date:   Fri Feb 13 16:04:55 2015 +0100

x86/mm/ASLR: Propagate base load address calculation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 05/15] drm: bridge/dw_hdmi: combine hdmi_set_clock_regenerator_n() and hdmi_regenerate_cts()

[Yakir Yang]

Signed-off-by: Yakir Yang 
---
Changes in v4: None
Changes in v3:
- Combine hdmi_set_clock_regenerator_n() and hdmi_regenerate_cts()

Changes in v2: None

 drivers/gpu/drm/bridge/dw_hdmi.c | 17 ++---
 1 file changed, 6 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index 937beed..3d7c048 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -196,19 +196,15 @@ static void hdmi_mask_writeb(struct dw_hdmi *hdmi, u8 
data, unsigned int reg,
hdmi_modb(hdmi, data << shift, mask, reg);
 }
 
-static void hdmi_set_clock_regenerator_n(struct dw_hdmi *hdmi,
-unsigned int value)
+static void hdmi_set_clock_regenerator(struct dw_hdmi *hdmi,
+  unsigned int n, unsigned int cts)
 {
-   hdmi_writeb(hdmi, value & 0xff, HDMI_AUD_N1);
-   hdmi_writeb(hdmi, (value >> 8) & 0xff, HDMI_AUD_N2);
-   hdmi_writeb(hdmi, (value >> 16) & 0x0f, HDMI_AUD_N3);
+   hdmi_writeb(hdmi, n & 0xff, HDMI_AUD_N1);
+   hdmi_writeb(hdmi, (n >> 8) & 0xff, HDMI_AUD_N2);
+   hdmi_writeb(hdmi, (n >> 16) & 0x0f, HDMI_AUD_N3);
 
/* nshift factor = 0 */
hdmi_modb(hdmi, 0, HDMI_AUD_CTS3_N_SHIFT_MASK, HDMI_AUD_CTS3);
-}
-
-static void hdmi_regenerate_cts(struct dw_hdmi *hdmi, unsigned int cts)
-{
/* Must be set/cleared first */
hdmi_modb(hdmi, 0, HDMI_AUD_CTS3_CTS_MANUAL, HDMI_AUD_CTS3);
 
@@ -374,8 +370,7 @@ static void hdmi_set_clk_regenerator(struct dw_hdmi *hdmi,
__func__, hdmi->sample_rate, hdmi->ratio,
pixel_clk, clk_n, clk_cts);
 
-   hdmi_set_clock_regenerator_n(hdmi, clk_n);
-   hdmi_regenerate_cts(hdmi, clk_cts);
+   hdmi_set_clock_regenerator(hdmi, clk_n, clk_cts);
 }
 
 static void hdmi_init_clk_regenerator(struct dw_hdmi *hdmi)
-- 
2.1.2


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 04/15] drm: bridge/dw_hdmi: add identification registers parse and record

[Yakir Yang]

By parsing the identification registers we can know what functions
are present on the hdmi ip.

Signed-off-by: Yakir Yang 
---
Changes in v4:
-Correct phy_type assignment bug

Changes in v3:
- Add ID registers parse and record

Changes in v2: None

 drivers/gpu/drm/bridge/dw_hdmi.c | 59 
 drivers/gpu/drm/bridge/dw_hdmi.h | 23 
 2 files changed, 82 insertions(+)

diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index 08f10da..937beed 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -79,6 +79,23 @@ static const u16 csc_coeff_rgb_in_eitu709[3][4] = {
{ 0x6756, 0x78ab, 0x2000, 0x0200 }
 };
 
+struct hdmi_id {
+   u8 design;
+   u8 revision;
+
+   bool prepen;
+   bool audspdif;
+   bool audi2s;
+   bool hdmi14;
+   bool csc;
+   bool hdcp;
+   bool hdmi20;
+   bool confapb;
+   bool ahbauddma;
+   bool gpaud;
+   u8 phy_type;
+};
+
 struct hdmi_vmode {
bool mdvi;
bool mhsyncpolarity;
@@ -111,6 +128,8 @@ struct dw_hdmi {
struct clk *isfr_clk;
struct clk *iahb_clk;
 
+   struct hdmi_id id;
+
struct hdmi_data_info hdmi_data;
const struct dw_hdmi_plat_data *plat_data;
 
@@ -1259,6 +1278,36 @@ static int dw_hdmi_setup(struct dw_hdmi *hdmi, struct 
drm_display_mode *mode)
return 0;
 }
 
+static void hdmi_parse_id(struct dw_hdmi *hdmi)
+{
+   u8 config0_id, config1_id, config2_id, config3_id;
+
+   config0_id = hdmi_readb(hdmi, HDMI_CONFIG0_ID);
+   config1_id = hdmi_readb(hdmi, HDMI_CONFIG1_ID);
+   config2_id = hdmi_readb(hdmi, HDMI_CONFIG2_ID);
+   config3_id = hdmi_readb(hdmi, HDMI_CONFIG3_ID);
+
+   hdmi->id.prepen = config0_id & HDMI_CONFIG0_ID_PREPEN ? true : false;
+   hdmi->id.audi2s = config0_id & HDMI_CONFIG0_ID_AUDI2S ? true : false;
+   hdmi->id.hdmi14 = config0_id & HDMI_CONFIG0_ID_HDMI14 ? true : false;
+   hdmi->id.hdcp = config0_id & HDMI_CONFIG0_ID_HDCP ? true : false;
+   hdmi->id.csc = config0_id & HDMI_CONFIG0_ID_CSC ? true : false;
+   hdmi->id.audspdif = config0_id & HDMI_CONFIG0_ID_AUDSPDIF ?
+   true : false;
+
+   hdmi->id.confapb = config1_id & HDMI_CONFIG1_ID_CONFAPB ? true : false;
+   hdmi->id.hdmi20 = config1_id & HDMI_CONFIG1_ID_HDMI20 ? true : false;
+
+   hdmi->id.phy_type = config2_id;
+
+   hdmi->id.gpaud = config3_id & HDMI_CONFIG3_ID_GPAUD ? true : false;
+   hdmi->id.ahbauddma = config3_id & HDMI_CONFIG3_ID_AHBAUDDMA ?
+true : false;
+
+   hdmi->id.design = hdmi_readb(hdmi, HDMI_DESIGN_ID);
+   hdmi->id.revision = hdmi_readb(hdmi, HDMI_REVISION_ID);
+}
+
 /* Wait until we are registered to enable interrupts */
 static int dw_hdmi_fb_registered(struct dw_hdmi *hdmi)
 {
@@ -1670,6 +1719,16 @@ int dw_hdmi_bind(struct device *dev, struct device 
*master,
 hdmi_readb(hdmi, HDMI_PRODUCT_ID0),
 hdmi_readb(hdmi, HDMI_PRODUCT_ID1));
 
+   /* Config IDs */
+   dev_info(dev,
+"Detected HDMI config_id 0x%x:0x%x:0x%x:0x%x\n",
+hdmi_readb(hdmi, HDMI_CONFIG0_ID),
+hdmi_readb(hdmi, HDMI_CONFIG1_ID),
+hdmi_readb(hdmi, HDMI_CONFIG2_ID),
+hdmi_readb(hdmi, HDMI_CONFIG3_ID));
+
+   hdmi_parse_id(hdmi);
+
initialize_hdmi_ih_mutes(hdmi);
 
ret = devm_request_threaded_irq(dev, irq, dw_hdmi_hardirq,
diff --git a/drivers/gpu/drm/bridge/dw_hdmi.h b/drivers/gpu/drm/bridge/dw_hdmi.h
index 175dbc8..e4ba634 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.h
+++ b/drivers/gpu/drm/bridge/dw_hdmi.h
@@ -545,6 +545,29 @@
 #define HDMI_I2CM_FS_SCL_LCNT_0_ADDR0x7E12
 
 enum {
+/* HDMI_CONFIG0_ID */
+   HDMI_CONFIG0_ID_PREPEN = 0x80,
+   HDMI_CONFIG0_ID_AUDSPDIF = 0x20,
+   HDMI_CONFIG0_ID_AUDI2S = 0x10,
+   HDMI_CONFIG0_ID_HDMI14 = 0x08,
+   HDMI_CONFIG0_ID_CSC = 0x04,
+   HDMI_CONFIG0_ID_HDCP = 0x01,
+
+/* HDMI_CONFIG1_ID */
+   HDMI_CONFIG1_ID_HDMI20 = 0x20,
+   HDMI_CONFIG1_ID_CONFAPB = 0x02,
+
+/* HDMI_CONFIG2_ID */
+   HDMI_CONFIG2_ID_PHY_GEN2 = 0xf2,
+   HDMI_CONFIG2_ID_PHY_GEN2_HECA = 0xe2,
+   HDMI_CONFIG2_ID_PHY_HDMI_MHL = 0xc2,
+   HDMI_CONFIG2_ID_PHY_HDMI_MHL_HECA = 0xb2,
+   HDMI_CONFIG2_ID_LEGACY_PHY = 0x00,
+
+/* HDMI_CONFIG3_ID */
+   HDMI_CONFIG3_ID_AHBAUDDMA = 0x02,
+   HDMI_CONFIG3_ID_GPAUD = 0x01,
+
 /* IH_FC_INT2 field values */
HDMI_IH_FC_INT2_OVERFLOW_MASK = 0x03,
HDMI_IH_FC_INT2_LOW_PRIORITY_OVERFLOW = 0x02,
-- 
2.1.2


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 03/15] drm: rockchip/dw_hdmi_rockchip: add resume/suspend support

[Yakir Yang]

Signed-off-by: Yakir Yang 
---
Changes in v4: None
Changes in v3:
- Setting the .pm member instead of suspend/resume

Changes in v2:
- Add suspend/resume support for dw_hdmi_rockchip driver

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

diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c 
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index d236faa..fc1d02e 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -323,11 +323,27 @@ static int dw_hdmi_rockchip_remove(struct platform_device 
*pdev)
return 0;
 }
 
+static int dw_hdmi_rockchip_suspend(struct device *dev)
+{
+   return dw_hdmi_suspend(dev);
+}
+
+static int dw_hdmi_rockchip_resume(struct device *dev)
+{
+   return dw_hdmi_resume(dev);
+}
+
+static const struct dev_pm_ops dw_hdmi_rockchip_pm = {
+   .resume = dw_hdmi_rockchip_resume,
+   .suspend = dw_hdmi_rockchip_suspend,
+};
+
 static struct platform_driver dw_hdmi_rockchip_pltfm_driver = {
.probe  = dw_hdmi_rockchip_probe,
.remove = dw_hdmi_rockchip_remove,
.driver = {
.name = "dwhdmi-rockchip",
+   .pm = _hdmi_rockchip_pm,
.of_match_table = dw_hdmi_rockchip_dt_ids,
},
 };
-- 
2.1.2


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] fanotify: Fix event filtering with FAN_ONDIR set

[Lino Sanfilippo]

Hi Suzuki,

On 27.02.2015 12:40, Suzuki K. Poulose wrote:
> From: "Suzuki K. Poulose" 
> 
> With FAN_ONDIR set, the user can end up getting events, which
> it hasn't marked. This was revealed with fanotify04 testcase
> failure on Linux-4.0-rc1, and is a regression from 3.19, revealed
> with commit (66ba93c0d7fe6: fanotify: don't set FAN_ONDIR implicitly
> on a marks ignored mask).
> 

> 
> Fix this by masking the outgoing events to the user, as we
> already take care of FAN_ONDIR and FAN_EVENT_ON_CHILD.
> 

thank you for fixing this. I tested your solution and it works, so you
can add Tested-by: Lino Sanfilippo .

Regards,
Lino




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 02/15] drm: bridge/dw_hdmi: wrap irq control in fucntions

[Yakir Yang]

Wrap irq control in functions, and then we can call in
dw_hdmi_bind/dw_hdmi_unbind/dw_hdmi_resume/dw_hdmi_suspend
functions.

Signed-off-by: Yakir Yang 
---
Changes in v4: None
Changes in v3:
- Wrap irq control in fucntions

Changes in v2: None

 drivers/gpu/drm/bridge/dw_hdmi.c | 75 
 1 file changed, 37 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index dc314f5..08f10da 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -1330,6 +1330,40 @@ static void initialize_hdmi_ih_mutes(struct dw_hdmi 
*hdmi)
hdmi_writeb(hdmi, ih_mute, HDMI_IH_MUTE);
 }
 
+static void hdmi_mute_interrupts(struct dw_hdmi *hdmi)
+{
+   u8 ih_mute;
+
+   /* Disable all interrupts */
+   hdmi_writeb(hdmi, ~0, HDMI_IH_MUTE_PHY_STAT0);
+
+/* Disable top level interrupt bits in HDMI block */
+   ih_mute = hdmi_readb(hdmi, HDMI_IH_MUTE) |
+ HDMI_IH_MUTE_MUTE_WAKEUP_INTERRUPT |
+ HDMI_IH_MUTE_MUTE_ALL_INTERRUPT;
+
+   hdmi_writeb(hdmi, ih_mute, HDMI_IH_MUTE);
+}
+
+static void hdmi_unmute_interrupts(struct dw_hdmi *hdmi)
+{
+   initialize_hdmi_ih_mutes(hdmi);
+
+   /*
+* Configure registers related to HDMI interrupt
+* generation before registering IRQ.
+*/
+   hdmi_writeb(hdmi, HDMI_PHY_HPD, HDMI_PHY_POL0);
+
+   /* Clear Hotplug interrupts */
+   hdmi_writeb(hdmi, HDMI_IH_PHY_STAT0_HPD, HDMI_IH_PHY_STAT0);
+
+   dw_hdmi_fb_registered(hdmi);
+
+   /* Unmute interrupts */
+   hdmi_writeb(hdmi, ~HDMI_IH_PHY_STAT0_HPD, HDMI_IH_MUTE_PHY_STAT0);
+}
+
 static void dw_hdmi_poweron(struct dw_hdmi *hdmi)
 {
dw_hdmi_setup(hdmi, >previous_mode);
@@ -1650,25 +1684,11 @@ int dw_hdmi_bind(struct device *dev, struct device 
*master,
 */
hdmi_init_clk_regenerator(hdmi);
 
-   /*
-* Configure registers related to HDMI interrupt
-* generation before registering IRQ.
-*/
-   hdmi_writeb(hdmi, HDMI_PHY_HPD, HDMI_PHY_POL0);
-
-   /* Clear Hotplug interrupts */
-   hdmi_writeb(hdmi, HDMI_IH_PHY_STAT0_HPD, HDMI_IH_PHY_STAT0);
-
-   ret = dw_hdmi_fb_registered(hdmi);
-   if (ret)
-   goto err_iahb;
-
ret = dw_hdmi_register(drm, hdmi);
if (ret)
goto err_iahb;
 
-   /* Unmute interrupts */
-   hdmi_writeb(hdmi, ~HDMI_IH_PHY_STAT0_HPD, HDMI_IH_MUTE_PHY_STAT0);
+   hdmi_unmute_interrupts(hdmi);
 
dev_set_drvdata(dev, hdmi);
 
@@ -1702,17 +1722,8 @@ EXPORT_SYMBOL_GPL(dw_hdmi_unbind);
 int dw_hdmi_suspend(struct device *dev)
 {
struct dw_hdmi *hdmi = dev_get_drvdata(dev);
-   u8 ih_mute;
-
-   /* Disable all interrupts */
-   hdmi_writeb(hdmi, ~0, HDMI_IH_MUTE_PHY_STAT0);
-
-/* Disable top level interrupt bits in HDMI block */
-   ih_mute = hdmi_readb(hdmi, HDMI_IH_MUTE) |
- HDMI_IH_MUTE_MUTE_WAKEUP_INTERRUPT |
- HDMI_IH_MUTE_MUTE_ALL_INTERRUPT;
 
-   hdmi_writeb(hdmi, ih_mute, HDMI_IH_MUTE);
+   hdmi_mute_interrupts(hdmi);
 
return 0;
 }
@@ -1722,19 +1733,7 @@ int dw_hdmi_resume(struct device *dev)
 {
struct dw_hdmi *hdmi = dev_get_drvdata(dev);
 
-   /*
-* Configure registers related to HDMI interrupt
-* generation before registering IRQ.
-*/
-   hdmi_writeb(hdmi, HDMI_PHY_HPD, HDMI_PHY_POL0);
-
-   /* Clear Hotplug interrupts */
-   hdmi_writeb(hdmi, HDMI_IH_PHY_STAT0_HPD, HDMI_IH_PHY_STAT0);
-
-   dw_hdmi_fb_registered(hdmi);
-
-   /* Unmute interrupts */
-   hdmi_writeb(hdmi, ~HDMI_IH_PHY_STAT0_HPD, HDMI_IH_MUTE_PHY_STAT0);
+   hdmi_unmute_interrupts(hdmi);
 
return 0;
 }
-- 
2.1.2


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/8] x86, efi: copy SETUP_EFI data and access directly

[Yinghai Lu]

the copy will be in __initdata, and it is small.

We can use pointer to access the setup_data instead of keeping on
early_memmap and early_memunmap everywhere.

Cc: Matt Fleming 
Cc: linux-...@vger.kernel.org
Signed-off-by: Yinghai Lu 
---
 arch/x86/include/asm/efi.h |  2 +-
 arch/x86/platform/efi/efi.c| 13 ++---
 arch/x86/platform/efi/efi_64.c | 13 -
 arch/x86/platform/efi/quirks.c | 23 ++-
 4 files changed, 21 insertions(+), 30 deletions(-)

diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
index 25bce45..edbecd6 100644
--- a/arch/x86/include/asm/efi.h
+++ b/arch/x86/include/asm/efi.h
@@ -114,7 +114,7 @@ struct efi_setup_data {
u64 reserved[8];
 };
 
-extern u64 efi_setup;
+extern struct efi_setup_data *efi_setup;
 
 #ifdef CONFIG_EFI
 
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index dbc8627..1cd38e8 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -68,7 +68,7 @@ static efi_config_table_type_t arch_tables[] __initdata = {
{NULL_GUID, NULL, NULL},
 };
 
-u64 efi_setup; /* efi setup_data physical address */
+struct efi_setup_data *efi_setup __initdata; /* cached efi setup_data pointer 
*/
 
 static int add_efi_memmap __initdata;
 static int __init setup_add_efi_memmap(char *arg)
@@ -225,20 +225,13 @@ static int __init efi_systab_init(void *phys)
 {
if (efi_enabled(EFI_64BIT)) {
efi_system_table_64_t *systab64;
-   struct efi_setup_data *data = NULL;
+   struct efi_setup_data *data = efi_setup;
u64 tmp = 0;
 
-   if (efi_setup) {
-   data = early_memremap(efi_setup, sizeof(*data));
-   if (!data)
-   return -ENOMEM;
-   }
systab64 = early_memremap((unsigned long)phys,
 sizeof(*systab64));
if (systab64 == NULL) {
pr_err("Couldn't map the system table!\n");
-   if (data)
-   early_memunmap(data, sizeof(*data));
return -ENOMEM;
}
 
@@ -271,8 +264,6 @@ static int __init efi_systab_init(void *phys)
tmp |= data ? data->tables : systab64->tables;
 
early_memunmap(systab64, sizeof(*systab64));
-   if (data)
-   early_memunmap(data, sizeof(*data));
 #ifdef CONFIG_X86_32
if (tmp >> 32) {
pr_err("EFI data located above 4GB, disabling EFI.\n");
diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
index 17e80d8..a541c6c 100644
--- a/arch/x86/platform/efi/efi_64.c
+++ b/arch/x86/platform/efi/efi_64.c
@@ -292,9 +292,20 @@ void __iomem *__init efi_ioremap(unsigned long phys_addr, 
unsigned long size,
return (void __iomem *)__va(phys_addr);
 }
 
+static struct efi_setup_data efi_setup_data __initdata;
+
 void __init parse_efi_setup(u64 phys_addr, u32 data_len)
 {
-   efi_setup = phys_addr + sizeof(struct setup_data);
+   struct efi_setup_data *data;
+
+   data = early_memremap(phys_addr + sizeof(struct setup_data),
+ sizeof(*data));
+   if (!data)
+   return;
+
+   efi_setup_data = *data;
+   early_memunmap(data, sizeof(*data));
+   efi_setup = _setup_data;
 }
 
 void __init efi_runtime_mkexec(void)
diff --git a/arch/x86/platform/efi/quirks.c b/arch/x86/platform/efi/quirks.c
index 1c7380d..45fec7d 100644
--- a/arch/x86/platform/efi/quirks.c
+++ b/arch/x86/platform/efi/quirks.c
@@ -203,9 +203,8 @@ void __init efi_free_boot_services(void)
  */
 int __init efi_reuse_config(u64 tables, int nr_tables)
 {
-   int i, sz, ret = 0;
+   int i, sz;
void *p, *tablep;
-   struct efi_setup_data *data;
 
if (!efi_setup)
return 0;
@@ -213,22 +212,15 @@ int __init efi_reuse_config(u64 tables, int nr_tables)
if (!efi_enabled(EFI_64BIT))
return 0;
 
-   data = early_memremap(efi_setup, sizeof(*data));
-   if (!data) {
-   ret = -ENOMEM;
-   goto out;
-   }
-
-   if (!data->smbios)
-   goto out_memremap;
+   if (!efi_setup->smbios)
+   return 0;
 
sz = sizeof(efi_config_table_64_t);
 
p = tablep = early_memremap(tables, nr_tables * sz);
if (!p) {
pr_err("Could not map Configuration table!\n");
-   ret = -ENOMEM;
-   goto out_memremap;
+   return -ENOMEM;
}
 
for (i = 0; i < efi.systab->nr_tables; i++) {
@@ -237,15 +229,12 @@ int __init efi_reuse_config(u64 tables, int nr_tables)
guid = ((efi_config_table_64_t *)p)->guid;
 
if (!efi_guidcmp(guid, SMBIOS_TABLE_GUID))
-   

[PATCH v4 01/15] drm: bridge/dw_hdmi: add irq control to suspend/resume

[Yakir Yang]

when kernel enter into suspend, cpus will shutdown, hdmi registers
will reset invisibly. After kernel resume, drm core will call the
bridge enable function. All of hdmi registers will be setup again
except the interrupt registers. In that case we should mute all the
interrupt in suspend stage, and umnute the interrupt we need in the
resume stage.

Signed-off-by: Yakir Yang 
---
Changes in v4: None
Changes in v3:
- Clear Hotplug interrupts before dw_hdmi_fb_register

Changes in v2:
- Add irq control to suspend/resume interfaces

 drivers/gpu/drm/bridge/dw_hdmi.c | 41 
 include/drm/bridge/dw_hdmi.h |  2 ++
 2 files changed, 43 insertions(+)

diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index cd6a706..dc314f5 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -1699,6 +1699,47 @@ void dw_hdmi_unbind(struct device *dev, struct device 
*master, void *data)
 }
 EXPORT_SYMBOL_GPL(dw_hdmi_unbind);
 
+int dw_hdmi_suspend(struct device *dev)
+{
+   struct dw_hdmi *hdmi = dev_get_drvdata(dev);
+   u8 ih_mute;
+
+   /* Disable all interrupts */
+   hdmi_writeb(hdmi, ~0, HDMI_IH_MUTE_PHY_STAT0);
+
+/* Disable top level interrupt bits in HDMI block */
+   ih_mute = hdmi_readb(hdmi, HDMI_IH_MUTE) |
+ HDMI_IH_MUTE_MUTE_WAKEUP_INTERRUPT |
+ HDMI_IH_MUTE_MUTE_ALL_INTERRUPT;
+
+   hdmi_writeb(hdmi, ih_mute, HDMI_IH_MUTE);
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(dw_hdmi_suspend);
+
+int dw_hdmi_resume(struct device *dev)
+{
+   struct dw_hdmi *hdmi = dev_get_drvdata(dev);
+
+   /*
+* Configure registers related to HDMI interrupt
+* generation before registering IRQ.
+*/
+   hdmi_writeb(hdmi, HDMI_PHY_HPD, HDMI_PHY_POL0);
+
+   /* Clear Hotplug interrupts */
+   hdmi_writeb(hdmi, HDMI_IH_PHY_STAT0_HPD, HDMI_IH_PHY_STAT0);
+
+   dw_hdmi_fb_registered(hdmi);
+
+   /* Unmute interrupts */
+   hdmi_writeb(hdmi, ~HDMI_IH_PHY_STAT0_HPD, HDMI_IH_MUTE_PHY_STAT0);
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(dw_hdmi_resume);
+
 MODULE_AUTHOR("Sascha Hauer ");
 MODULE_AUTHOR("Andy Yan ");
 MODULE_AUTHOR("Yakir Yang ");
diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
index 5a4f490..e8cfe1c 100644
--- a/include/drm/bridge/dw_hdmi.h
+++ b/include/drm/bridge/dw_hdmi.h
@@ -53,6 +53,8 @@ struct dw_hdmi_plat_data {
   struct drm_display_mode *mode);
 };
 
+int dw_hdmi_resume(struct device *dev);
+int dw_hdmi_suspend(struct device *dev);
 void dw_hdmi_unbind(struct device *dev, struct device *master, void *data);
 int dw_hdmi_bind(struct device *dev, struct device *master,
 void *data, struct drm_encoder *encoder,
-- 
2.1.2


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 7/8] x86, pci: convert SETUP_PCI data to list

[Yinghai Lu]

So we could avoid ioremap every time later.

Cc: Bjorn Helgaas 
Cc: linux-...@vger.kernel.org
Signed-off-by: Yinghai Lu 
---
 arch/x86/pci/common.c | 77 +--
 1 file changed, 63 insertions(+), 14 deletions(-)

diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c
index 4846db7..7b6fb94 100644
--- a/arch/x86/pci/common.c
+++ b/arch/x86/pci/common.c
@@ -680,10 +680,41 @@ void __init add_pci(u64 pa_data)
early_memunmap(data, sizeof(*data));
 }
 
-int pcibios_add_device(struct pci_dev *dev)
+struct firmware_setup_pci_entry {
+   struct list_head list;
+   uint16_t vendor;
+   uint16_t devid;
+   uint64_t pcilen;
+   unsigned long segment;
+   unsigned long bus;
+   unsigned long device;
+   unsigned long function;
+   phys_addr_t rom;
+};
+
+static LIST_HEAD(setup_pci_entries);
+
+static void __init firmware_setup_pci_add_entry(struct pci_setup_rom *rom,
+   u64 pa_data,
+   struct firmware_setup_pci_entry *entry)
+{
+   entry->segment = rom->segment;
+   entry->bus = rom->bus;
+   entry->device = rom->device;
+   entry->function = rom->function;
+   entry->vendor = rom->vendor;
+   entry->devid = rom->devid;
+   entry->rom = pa_data + offsetof(struct pci_setup_rom, romdata);
+   entry->pcilen = rom->pcilen;
+
+   list_add(>list, _pci_entries);
+}
+
+static __init int fill_setup_pci_entries(void)
 {
struct setup_data *data;
struct pci_setup_rom *rom;
+   struct firmware_setup_pci_entry *entry;
u64 pa_data;
 
pa_data = pci_setup_data;
@@ -692,24 +723,42 @@ int pcibios_add_device(struct pci_dev *dev)
if (!data)
return -ENOMEM;
 
-   rom = (struct pci_setup_rom *)data;
-
-   if ((pci_domain_nr(dev->bus) == rom->segment) &&
-   (dev->bus->number == rom->bus) &&
-   (PCI_SLOT(dev->devfn) == rom->device) &&
-   (PCI_FUNC(dev->devfn) == rom->function) &&
-   (dev->vendor == rom->vendor) &&
-   (dev->device == rom->devid)) {
-   dev->rom = pa_data +
- offsetof(struct pci_setup_rom, romdata);
-   dev->romlen = rom->pcilen;
+   entry = kzalloc(sizeof(struct firmware_setup_pci_entry),
+   GFP_ATOMIC);
+   if (!entry) {
+   iounmap(data);
+   return -ENOMEM;
+   }
+
+   firmware_setup_pci_add_entry((struct pci_setup_rom *)data,
+pa_data, entry);
+   pa_data = data->next;
+   iounmap(data);
+   }
+
+   return 0;
+}
+postcore_initcall(fill_setup_pci_entries);
+
+int pcibios_add_device(struct pci_dev *dev)
+{
+   struct firmware_setup_pci_entry *entry;
+
+   list_for_each_entry(entry, _pci_entries, list) {
+   if ((pci_domain_nr(dev->bus) == entry->segment) &&
+   (dev->bus->number == entry->bus) &&
+   (PCI_SLOT(dev->devfn) == entry->device) &&
+   (PCI_FUNC(dev->devfn) == entry->function) &&
+   (dev->vendor == entry->vendor) &&
+   (dev->device == entry->devid)) {
+   dev->rom = entry->rom;
+   dev->romlen = entry->pcilen;
dev_printk(KERN_DEBUG, >dev, "set rom to [%#010lx, 
%#010lx] via SETUP_PCI\n",
   (unsigned long)dev->rom,
   (unsigned long)(dev->rom + dev->romlen - 1));
}
-   pa_data = data->next;
-   iounmap(data);
}
+
return 0;
 }
 
-- 
1.8.4.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 8/8] x86, pci: export SETUP_PCI data via sysfs

[Yinghai Lu]

So we could let kexec-tools to rebuild SETUP_PCI and pass it to
second kernel.
Now kexec-tools only can build SETUP_EFI and SETUP_E820EXT.

Cc: Bjorn Helgaas 
Cc: linux-...@vger.kernel.org
Signed-off-by: Yinghai Lu 
---
 arch/x86/pci/common.c | 188 ++
 1 file changed, 188 insertions(+)

diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c
index 7b6fb94..bf0209a 100644
--- a/arch/x86/pci/common.c
+++ b/arch/x86/pci/common.c
@@ -682,6 +682,8 @@ void __init add_pci(u64 pa_data)
 
 struct firmware_setup_pci_entry {
struct list_head list;
+   struct kobject kobj;
+   struct bin_attribute *rom_attr;
uint16_t vendor;
uint16_t devid;
uint64_t pcilen;
@@ -762,6 +764,192 @@ int pcibios_add_device(struct pci_dev *dev)
return 0;
 }
 
+#ifdef CONFIG_SYSFS
+static inline struct firmware_setup_pci_entry *
+to_setup_pci_entry(struct kobject *kobj)
+{
+   return container_of(kobj, struct firmware_setup_pci_entry, kobj);
+}
+
+static ssize_t vendor_show(struct firmware_setup_pci_entry *entry, char *buf)
+{
+   return snprintf(buf, PAGE_SIZE, "0x%04llx\n",
+   (unsigned long long)entry->vendor);
+}
+
+static ssize_t devid_show(struct firmware_setup_pci_entry *entry, char *buf)
+{
+   return snprintf(buf, PAGE_SIZE, "0x%04llx\n",
+   (unsigned long long)entry->devid);
+}
+
+static ssize_t pcilen_show(struct firmware_setup_pci_entry *entry, char *buf)
+{
+   return snprintf(buf, PAGE_SIZE, "0x%llx\n",
+   (unsigned long long)entry->pcilen);
+}
+
+static ssize_t segment_show(struct firmware_setup_pci_entry *entry, char *buf)
+{
+   return snprintf(buf, PAGE_SIZE, "0x%04llx\n",
+   (unsigned long long)entry->segment);
+}
+
+static ssize_t bus_show(struct firmware_setup_pci_entry *entry, char *buf)
+{
+   return snprintf(buf, PAGE_SIZE, "0x%02llx\n",
+   (unsigned long long)entry->bus);
+}
+
+static ssize_t device_show(struct firmware_setup_pci_entry *entry, char *buf)
+{
+   return snprintf(buf, PAGE_SIZE, "0x%02llx\n",
+   (unsigned long long)entry->device);
+}
+
+static ssize_t function_show(struct firmware_setup_pci_entry *entry, char *buf)
+{
+   return snprintf(buf, PAGE_SIZE, "0x%1llx\n",
+   (unsigned long long)entry->function);
+}
+
+struct setup_pci_attribute {
+   struct attribute attr;
+   ssize_t (*show)(struct firmware_setup_pci_entry *entry, char *buf);
+};
+
+static inline struct setup_pci_attribute *to_setup_pci_attr(
+   struct attribute *attr)
+{
+   return container_of(attr, struct setup_pci_attribute, attr);
+}
+
+static ssize_t setup_pci_attr_show(struct kobject *kobj,
+  struct attribute *attr, char *buf)
+{
+   struct firmware_setup_pci_entry *entry = to_setup_pci_entry(kobj);
+   struct setup_pci_attribute *setup_pci_attr = to_setup_pci_attr(attr);
+
+   return setup_pci_attr->show(entry, buf);
+}
+
+static struct setup_pci_attribute setup_pci_vendor_attr = __ATTR_RO(vendor);
+static struct setup_pci_attribute setup_pci_devid_attr = __ATTR_RO(devid);
+static struct setup_pci_attribute setup_pci_pcilen_attr = __ATTR_RO(pcilen);
+static struct setup_pci_attribute setup_pci_segment_attr = __ATTR_RO(segment);
+static struct setup_pci_attribute setup_pci_bus_attr = __ATTR_RO(bus);
+static struct setup_pci_attribute setup_pci_device_attr = __ATTR_RO(device);
+static struct setup_pci_attribute setup_pci_function_attr = 
__ATTR_RO(function);
+
+/*
+ * These are default attributes that are added for every memmap entry.
+ */
+static struct attribute *def_attrs[] = {
+   _pci_vendor_attr.attr,
+   _pci_devid_attr.attr,
+   _pci_pcilen_attr.attr,
+   _pci_segment_attr.attr,
+   _pci_bus_attr.attr,
+   _pci_device_attr.attr,
+   _pci_function_attr.attr,
+   NULL
+};
+
+static const struct sysfs_ops setup_pci_attr_ops = {
+   .show = setup_pci_attr_show,
+};
+
+static struct kobj_type __refdata setup_pci_ktype = {
+   .sysfs_ops  = _pci_attr_ops,
+   .default_attrs  = def_attrs,
+};
+
+static ssize_t setup_pci_rom_read(struct file *filp, struct kobject *kobj,
+ struct bin_attribute *bin_attr, char *buf,
+ loff_t off, size_t count)
+{
+   struct firmware_setup_pci_entry *entry = to_setup_pci_entry(kobj);
+
+   if (off >= entry->pcilen)
+   count = 0;
+   else {
+   unsigned long start_pfn, end_pfn;
+   void *rom;
+
+   if (off + count > entry->pcilen)
+   count = entry->pcilen - off;
+
+   start_pfn = PFN_DOWN(entry->rom + off);
+   end_pfn = PFN_UP(entry->rom + off + count);
+   if (pfn_range_is_mapped(start_pfn, 

[PATCH 5/8] x86, boot: Add add_pci handler for SETUP_PCI

[Yinghai Lu]

Let it reserve setup_data, and keep it's own list.

Also clear the hdr.setup_data, as all handler will handle or
reserve setup_data locally already.

Cc: Bjorn Helgaas 
Cc: Matt Fleming 
Cc: linux-...@vger.kernel.org
Signed-off-by: Yinghai Lu 
---
 arch/x86/include/asm/pci.h |  2 ++
 arch/x86/kernel/setup.c|  6 ++
 arch/x86/pci/common.c  | 42 --
 3 files changed, 36 insertions(+), 14 deletions(-)

diff --git a/arch/x86/include/asm/pci.h b/arch/x86/include/asm/pci.h
index 4e370a5..aa25a22 100644
--- a/arch/x86/include/asm/pci.h
+++ b/arch/x86/include/asm/pci.h
@@ -155,4 +155,6 @@ struct pci_setup_rom {
uint8_t romdata[0];
 };
 
+void add_pci(u64 pa_data);
+
 #endif /* _ASM_X86_PCI_H */
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index c9b3e2f..93c0adb 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -460,6 +460,9 @@ static void __init parse_setup_data(void)
case SETUP_DTB:
add_dtb(pa_data);
break;
+   case SETUP_PCI:
+   add_pci(pa_data);
+   break;
case SETUP_EFI:
parse_efi_setup(pa_data, data_len);
break;
@@ -467,10 +470,13 @@ static void __init parse_setup_data(void)
parse_kaslr_setup(pa_data, data_len);
break;
default:
+   pr_warn("Unknown setup_data type: %d ignored!\n",
+   data_type);
break;
}
pa_data = pa_next;
}
+   boot_params.hdr.setup_data = 0; /* all done */
 }
 
 static void __init memblock_x86_reserve_range_setup_data(void)
diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c
index 3d2612b..4846db7 100644
--- a/arch/x86/pci/common.c
+++ b/arch/x86/pci/common.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -667,31 +668,44 @@ unsigned int pcibios_assign_all_busses(void)
return (pci_probe & PCI_ASSIGN_ALL_BUSSES) ? 1 : 0;
 }
 
+static u64 pci_setup_data;
+void __init add_pci(u64 pa_data)
+{
+   struct setup_data *data;
+
+   data = early_memremap(pa_data, sizeof(*data));
+   memblock_reserve(pa_data, sizeof(*data) + data->len);
+   data->next = pci_setup_data;
+   pci_setup_data = pa_data;
+   early_memunmap(data, sizeof(*data));
+}
+
 int pcibios_add_device(struct pci_dev *dev)
 {
struct setup_data *data;
struct pci_setup_rom *rom;
u64 pa_data;
 
-   pa_data = boot_params.hdr.setup_data;
+   pa_data = pci_setup_data;
while (pa_data) {
data = ioremap(pa_data, sizeof(*rom));
if (!data)
return -ENOMEM;
 
-   if (data->type == SETUP_PCI) {
-   rom = (struct pci_setup_rom *)data;
-
-   if ((pci_domain_nr(dev->bus) == rom->segment) &&
-   (dev->bus->number == rom->bus) &&
-   (PCI_SLOT(dev->devfn) == rom->device) &&
-   (PCI_FUNC(dev->devfn) == rom->function) &&
-   (dev->vendor == rom->vendor) &&
-   (dev->device == rom->devid)) {
-   dev->rom = pa_data +
- offsetof(struct pci_setup_rom, romdata);
-   dev->romlen = rom->pcilen;
-   }
+   rom = (struct pci_setup_rom *)data;
+
+   if ((pci_domain_nr(dev->bus) == rom->segment) &&
+   (dev->bus->number == rom->bus) &&
+   (PCI_SLOT(dev->devfn) == rom->device) &&
+   (PCI_FUNC(dev->devfn) == rom->function) &&
+   (dev->vendor == rom->vendor) &&
+   (dev->device == rom->devid)) {
+   dev->rom = pa_data +
+ offsetof(struct pci_setup_rom, romdata);
+   dev->romlen = rom->pcilen;
+   dev_printk(KERN_DEBUG, >dev, "set rom to [%#010lx, 
%#010lx] via SETUP_PCI\n",
+  (unsigned long)dev->rom,
+  (unsigned long)(dev->rom + dev->romlen - 1));
}
pa_data = data->next;
iounmap(data);
-- 
1.8.4.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 4/8] x86, of: let add_dtb reserve by itself

[Yinghai Lu]

We will not reserve setup_data in general code. Every handler
need to reserve and copy.

Current dtd handling already have code copying, just add reserve code ...

also simplify code a bit with storing real dtb size.

Cc: Rob Herring 
Cc: David Vrabel 
Signed-off-by: Yinghai Lu 
---
 arch/x86/include/asm/prom.h  |  9 ++---
 arch/x86/kernel/devicetree.c | 39 +--
 2 files changed, 27 insertions(+), 21 deletions(-)

diff --git a/arch/x86/include/asm/prom.h b/arch/x86/include/asm/prom.h
index 1d081ac..fb716eddc 100644
--- a/arch/x86/include/asm/prom.h
+++ b/arch/x86/include/asm/prom.h
@@ -24,17 +24,20 @@
 
 #ifdef CONFIG_OF
 extern int of_ioapic;
-extern u64 initial_dtb;
-extern void add_dtb(u64 data);
 void x86_of_pci_init(void);
 void x86_dtb_init(void);
 #else
-static inline void add_dtb(u64 data) { }
 static inline void x86_of_pci_init(void) { }
 static inline void x86_dtb_init(void) { }
 #define of_ioapic 0
 #endif
 
+#ifdef CONFIG_OF_FLATTREE
+extern void add_dtb(u64 data);
+#else
+static inline void add_dtb(u64 data) { }
+#endif
+
 extern char cmd_line[COMMAND_LINE_SIZE];
 
 #endif /* __ASSEMBLY__ */
diff --git a/arch/x86/kernel/devicetree.c b/arch/x86/kernel/devicetree.c
index 3d35033..cc2fb61 100644
--- a/arch/x86/kernel/devicetree.c
+++ b/arch/x86/kernel/devicetree.c
@@ -2,6 +2,7 @@
  * Architecture specific OF callbacks.
  */
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -23,7 +24,6 @@
 #include 
 #include 
 
-__initdata u64 initial_dtb;
 char __initdata cmd_line[COMMAND_LINE_SIZE];
 
 int __initdata of_ioapic;
@@ -43,11 +43,23 @@ void * __init early_init_dt_alloc_memory_arch(u64 size, u64 
align)
return __alloc_bootmem(size, align, __pa(MAX_DMA_ADDRESS));
 }
 
+#ifdef CONFIG_OF_FLATTREE
+static u64 initial_dtb __initdata;
+static u32 initial_dtb_size __initdata;
 void __init add_dtb(u64 data)
 {
+   u32 map_len;
+
initial_dtb = data + offsetof(struct setup_data, data);
-}
 
+   map_len = max(PAGE_SIZE - (initial_dtb & ~PAGE_MASK), (u64)128);
+   initial_boot_params = early_memremap(initial_dtb, map_len);
+   initial_dtb_size = of_get_flat_dt_size();
+   early_memunmap(initial_boot_params, map_len);
+   initial_boot_params = NULL;
+   memblock_reserve(initial_dtb, initial_dtb_size);
+}
+#endif
 /*
  * CE4100 ids. Will be moved to machine_device_initcall() once we have it.
  */
@@ -272,31 +284,22 @@ static void __init dtb_apic_setup(void)
dtb_ioapic_setup();
 }
 
-#ifdef CONFIG_OF_FLATTREE
 static void __init x86_flattree_get_config(void)
 {
-   u32 size, map_len;
+#ifdef CONFIG_OF_FLATTREE
void *dt;
 
if (!initial_dtb)
return;
 
-   map_len = max(PAGE_SIZE - (initial_dtb & ~PAGE_MASK), (u64)128);
-
-   initial_boot_params = dt = early_memremap(initial_dtb, map_len);
-   size = of_get_flat_dt_size();
-   if (map_len < size) {
-   early_iounmap(dt, map_len);
-   initial_boot_params = dt = early_memremap(initial_dtb, size);
-   map_len = size;
-   }
-
+   initial_boot_params = dt = early_memremap(initial_dtb,
+ initial_dtb_size);
unflatten_and_copy_device_tree();
-   early_iounmap(dt, map_len);
-}
-#else
-static inline void x86_flattree_get_config(void) { }
+   early_memunmap(dt, initial_dtb_size);
+
+   memblock_free(initial_dtb, initial_dtb_size);
 #endif
+}
 
 void __init x86_dtb_init(void)
 {
-- 
1.8.4.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/8] x86: Kill E820_RESERVED_KERN

[Yinghai Lu]

Now we are using memblock to do early resource reserver/allocation
instead of using e820 map directly, and setup_data is reserved in
memblock early already.
Also kexec will generate setup_data and pass pointer to second kernel,
so second kernel will reserve setup_data by their own.

We can kill E820_RESERVED_KERN and not touch e820 map at all.

That will fix bug in mark_nonsave_region that can not handle that
case: E820_RAM and E820_RESERVED_KERN ranges are continuous and
boundary is not page aligned.

Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=913885
Reported-by: "Lee, Chun-Yi" 
Tested-by: "Lee, Chun-Yi" 
Cc: "Lee, Chun-Yi" 
Signed-off-by: Yinghai Lu 
Cc: sta...@vger.kernel.org
---
 arch/x86/include/uapi/asm/e820.h |  9 -
 arch/x86/kernel/e820.c   |  6 ++
 arch/x86/kernel/setup.c  | 26 --
 arch/x86/kernel/tboot.c  |  3 +--
 arch/x86/mm/init_64.c| 11 ---
 5 files changed, 7 insertions(+), 48 deletions(-)

diff --git a/arch/x86/include/uapi/asm/e820.h b/arch/x86/include/uapi/asm/e820.h
index d993e33..edc8a71 100644
--- a/arch/x86/include/uapi/asm/e820.h
+++ b/arch/x86/include/uapi/asm/e820.h
@@ -33,15 +33,6 @@
 #define E820_NVS   4
 #define E820_UNUSABLE  5
 
-
-/*
- * reserved RAM used by kernel itself
- * if CONFIG_INTEL_TXT is enabled, memory of this type will be
- * included in the S3 integrity calculation and so should not include
- * any memory that BIOS might alter over the S3 transition
- */
-#define E820_RESERVED_KERN128
-
 #ifndef __ASSEMBLY__
 #include 
 struct e820entry {
diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index 46201de..2a6bed9 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -134,7 +134,6 @@ static void __init e820_print_type(u32 type)
 {
switch (type) {
case E820_RAM:
-   case E820_RESERVED_KERN:
printk(KERN_CONT "usable");
break;
case E820_RESERVED:
@@ -688,7 +687,7 @@ void __init e820_mark_nosave_regions(unsigned long 
limit_pfn)
register_nosave_region(pfn, PFN_UP(ei->addr));
 
pfn = PFN_DOWN(ei->addr + ei->size);
-   if (ei->type != E820_RAM && ei->type != E820_RESERVED_KERN)
+   if (ei->type != E820_RAM)
register_nosave_region(PFN_UP(ei->addr), pfn);
 
if (pfn >= limit_pfn)
@@ -902,7 +901,6 @@ void __init finish_e820_parsing(void)
 static inline const char *e820_type_to_string(int e820_type)
 {
switch (e820_type) {
-   case E820_RESERVED_KERN:
case E820_RAM:  return "System RAM";
case E820_ACPI: return "ACPI Tables";
case E820_NVS:  return "ACPI Non-volatile Storage";
@@ -1077,7 +1075,7 @@ void __init memblock_x86_fill(void)
if (end != (resource_size_t)end)
continue;
 
-   if (ei->type != E820_RAM && ei->type != E820_RESERVED_KERN)
+   if (ei->type != E820_RAM)
continue;
 
memblock_add(ei->addr, ei->size);
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 05d444f..c9b3e2f 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -473,30 +473,6 @@ static void __init parse_setup_data(void)
}
 }
 
-static void __init e820_reserve_setup_data(void)
-{
-   struct setup_data *data;
-   u64 pa_data;
-   int found = 0;
-
-   pa_data = boot_params.hdr.setup_data;
-   while (pa_data) {
-   data = early_memremap(pa_data, sizeof(*data));
-   e820_update_range(pa_data, sizeof(*data)+data->len,
-E820_RAM, E820_RESERVED_KERN);
-   found = 1;
-   pa_data = data->next;
-   early_iounmap(data, sizeof(*data));
-   }
-   if (!found)
-   return;
-
-   sanitize_e820_map(e820.map, ARRAY_SIZE(e820.map), _map);
-   memcpy(_saved, , sizeof(struct e820map));
-   printk(KERN_INFO "extended physical RAM map:\n");
-   e820_print_map("reserve setup_data");
-}
-
 static void __init memblock_x86_reserve_range_setup_data(void)
 {
struct setup_data *data;
@@ -1032,8 +1008,6 @@ void __init setup_arch(char **cmdline_p)
early_dump_pci_devices();
 #endif
 
-   /* update the e820_saved too */
-   e820_reserve_setup_data();
finish_e820_parsing();
 
if (efi_enabled(EFI_BOOT))
diff --git a/arch/x86/kernel/tboot.c b/arch/x86/kernel/tboot.c
index 91a4496..3c2752a 100644
--- a/arch/x86/kernel/tboot.c
+++ b/arch/x86/kernel/tboot.c
@@ -195,8 +195,7 @@ static int tboot_setup_sleep(void)
tboot->num_mac_regions = 0;
 
for (i = 0; i < e820.nr_map; i++) {
-   if ((e820.map[i].type != E820_RAM)
-&& (e820.map[i].type != E820_RESERVED_KERN))
+   if (e820.map[i].type != E820_RAM)
continue;
 
   

[PATCH 6/8] x86: kill not used setup_data handling code

[Yinghai Lu]

Cc: Matt Fleming 
Signed-off-by: Yinghai Lu 
---
 arch/x86/kernel/kdebugfs.c | 142 -
 arch/x86/kernel/setup.c|  17 --
 2 files changed, 159 deletions(-)

diff --git a/arch/x86/kernel/kdebugfs.c b/arch/x86/kernel/kdebugfs.c
index dc1404b..c8ca86c 100644
--- a/arch/x86/kernel/kdebugfs.c
+++ b/arch/x86/kernel/kdebugfs.c
@@ -21,142 +21,6 @@ struct dentry *arch_debugfs_dir;
 EXPORT_SYMBOL(arch_debugfs_dir);
 
 #ifdef CONFIG_DEBUG_BOOT_PARAMS
-struct setup_data_node {
-   u64 paddr;
-   u32 type;
-   u32 len;
-};
-
-static ssize_t setup_data_read(struct file *file, char __user *user_buf,
-  size_t count, loff_t *ppos)
-{
-   struct setup_data_node *node = file->private_data;
-   unsigned long remain;
-   loff_t pos = *ppos;
-   struct page *pg;
-   void *p;
-   u64 pa;
-
-   if (pos < 0)
-   return -EINVAL;
-
-   if (pos >= node->len)
-   return 0;
-
-   if (count > node->len - pos)
-   count = node->len - pos;
-
-   pa = node->paddr + sizeof(struct setup_data) + pos;
-   pg = pfn_to_page((pa + count - 1) >> PAGE_SHIFT);
-   if (PageHighMem(pg)) {
-   p = ioremap_cache(pa, count);
-   if (!p)
-   return -ENXIO;
-   } else
-   p = __va(pa);
-
-   remain = copy_to_user(user_buf, p, count);
-
-   if (PageHighMem(pg))
-   iounmap(p);
-
-   if (remain)
-   return -EFAULT;
-
-   *ppos = pos + count;
-
-   return count;
-}
-
-static const struct file_operations fops_setup_data = {
-   .read   = setup_data_read,
-   .open   = simple_open,
-   .llseek = default_llseek,
-};
-
-static int __init
-create_setup_data_node(struct dentry *parent, int no,
-  struct setup_data_node *node)
-{
-   struct dentry *d, *type, *data;
-   char buf[16];
-
-   sprintf(buf, "%d", no);
-   d = debugfs_create_dir(buf, parent);
-   if (!d)
-   return -ENOMEM;
-
-   type = debugfs_create_x32("type", S_IRUGO, d, >type);
-   if (!type)
-   goto err_dir;
-
-   data = debugfs_create_file("data", S_IRUGO, d, node, _setup_data);
-   if (!data)
-   goto err_type;
-
-   return 0;
-
-err_type:
-   debugfs_remove(type);
-err_dir:
-   debugfs_remove(d);
-   return -ENOMEM;
-}
-
-static int __init create_setup_data_nodes(struct dentry *parent)
-{
-   struct setup_data_node *node;
-   struct setup_data *data;
-   int error;
-   struct dentry *d;
-   struct page *pg;
-   u64 pa_data;
-   int no = 0;
-
-   d = debugfs_create_dir("setup_data", parent);
-   if (!d)
-   return -ENOMEM;
-
-   pa_data = boot_params.hdr.setup_data;
-
-   while (pa_data) {
-   node = kmalloc(sizeof(*node), GFP_KERNEL);
-   if (!node) {
-   error = -ENOMEM;
-   goto err_dir;
-   }
-
-   pg = pfn_to_page((pa_data+sizeof(*data)-1) >> PAGE_SHIFT);
-   if (PageHighMem(pg)) {
-   data = ioremap_cache(pa_data, sizeof(*data));
-   if (!data) {
-   kfree(node);
-   error = -ENXIO;
-   goto err_dir;
-   }
-   } else
-   data = __va(pa_data);
-
-   node->paddr = pa_data;
-   node->type = data->type;
-   node->len = data->len;
-   error = create_setup_data_node(d, no, node);
-   pa_data = data->next;
-
-   if (PageHighMem(pg))
-   iounmap(data);
-   if (error)
-   goto err_dir;
-   no++;
-   }
-
-   return 0;
-
-err_dir:
-   debugfs_remove(d);
-   return error;
-}
-
 static struct debugfs_blob_wrapper boot_params_blob = {
.data   = _params,
.size   = sizeof(boot_params),
@@ -181,14 +45,8 @@ static int __init boot_params_kdebugfs_init(void)
if (!data)
goto err_version;
 
-   error = create_setup_data_nodes(dbp);
-   if (error)
-   goto err_data;
-
return 0;
 
-err_data:
-   debugfs_remove(data);
 err_version:
debugfs_remove(version);
 err_dir:
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 93c0adb..b9f1687 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -479,20 +479,6 @@ static void __init parse_setup_data(void)
boot_params.hdr.setup_data = 0; /* all done */
 }
 
-static void __init memblock_x86_reserve_range_setup_data(void)
-{
-   struct setup_data *data;
-   u64 pa_data;
-
-   pa_data = boot_params.hdr.setup_data;
-   while (pa_data) {
-

[PATCH 0/8] x86, boot: clean up setup_data handling

[Yinghai Lu]

Now we setup_data is reserved via memblock and e820 and different
handlers have different ways, and it is confusing.
1. SETUP_E820_EXT: is consumed early and will not copy or access again.
have memory wasted.
2. SETUP_EFI: is accessed via ioremap every time at early stage.
have memory wasted.
3. SETUP_DTB: is copied locally.
have memory wasted.
4. SETUP_PCI: is accessed via ioremap for every pci devices, even run-time.
5. SETUP_KASLR: is accessed early, will not copy or access again.
have memory wasted.

Also setup_data is exported to debugfs for debug purpose.

Here will convert to let every handler to decide how to handle it.
and will not reserve the setup_data generally, so will not
waste memory and also make memblock/e820 keep page aligned.
1. not touch E820 anymore.
2. copy SETUP_EFI to __initdata variable and access it without ioremap.
3. SETUP_DTB: reserver and copy to local and free.
4. SETUP_PCI: reverve localy and convert to list, to avoid keeping ioremap.
5. SETUP_KASLR: fix accessing kaslr_enabled accessing...
6. export SETUP_PCI via sysfs.

Those patches could be applied on top of tip/x86/urgent with SETUP_KASLR
support.

Yinghai Lu (8):
  x86, kaslr: get kaslr_enabled back correctly
  x86: Kill E820_RESERVED_KERN
  x86, efi: copy SETUP_EFI data and access directly
  x86, of: let add_dtb reserve by itself
  x86, boot: Add add_pci handler for SETUP_PCI
  x86: kill not used setup_data handling code
  x86, pci: convert SETUP_PCI data to list
  x86, pci: export SETUP_PCI data via sysfs

 arch/x86/include/asm/efi.h   |   2 +-
 arch/x86/include/asm/pci.h   |   2 +
 arch/x86/include/asm/prom.h  |   9 +-
 arch/x86/include/uapi/asm/e820.h |   9 --
 arch/x86/kernel/devicetree.c |  39 +++---
 arch/x86/kernel/e820.c   |   6 +-
 arch/x86/kernel/kdebugfs.c   | 142 
 arch/x86/kernel/setup.c  |  57 ++--
 arch/x86/kernel/tboot.c  |   3 +-
 arch/x86/mm/init_64.c|  11 +-
 arch/x86/pci/common.c| 281 ---
 arch/x86/platform/efi/efi.c  |  13 +-
 arch/x86/platform/efi/efi_64.c   |  13 +-
 arch/x86/platform/efi/quirks.c   |  23 +---
 14 files changed, 336 insertions(+), 274 deletions(-)

-- 
1.8.4.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/8] x86, kaslr: get kaslr_enabled back correctly

[Yinghai Lu]

We should access variable with referrence instead of using physical
address as value.

Cc: Matt Fleming 
Cc: Borislav Petkov 
Signed-off-by: Yinghai Lu 
---
 arch/x86/kernel/setup.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 98dc931..05d444f 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -429,7 +429,13 @@ static void __init reserve_initrd(void)
 
 static void __init parse_kaslr_setup(u64 pa_data, u32 data_len)
 {
-   kaslr_enabled = (bool)(pa_data + sizeof(struct setup_data));
+   /* kaslr_setup_data is defined in aslr.c */
+   unsigned char *data;
+   unsigned long offset = sizeof(struct setup_data);
+
+   data = early_memremap(pa_data, offset + 1);
+   kaslr_enabled = *(data + offset);
+   early_memunmap(data, offset + 1);
 }
 
 static void __init parse_setup_data(void)
-- 
1.8.4.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Avoid null-pointer access in w1/slaves/w1_therm

[David Fries]

On Sun, Mar 01, 2015 at 04:48:22AM +0300, ??? ??? wrote:
> Hi everyone
> 
> 28.02.2015, 23:18, "David Fries" :
> > Thanks for preparing the patch, it looks like it will go another
> > round, but that happens to everyone.
> 
> Patch itself doesn't solve the problem, it only adds a workaround.
> There is a reference counter issue - reading data via sysfs only holds
> a reference to device, w1 slave structure will be deleted by w1 search core.
> 
> I believe it only accidentally doesn't crash because of kernel memory 
> allocator
> hasn't yet reclaimed memory.

Good point, it does look like that's the case.

w1_unref_slave calls w1_family_notify(BUS_NOTIFY_DEL_DEVICE, sl);
which calls sl->family->fops->remove_slave(sl);
which kfree and sl->family_data = NULL;

In that case what do you think about in w1_slave_show after getting
bus_mutex,
atomic_inc(>refcnt);

then add
w1_unref_slave(sl);
in each return path, or do a goto and consolidate them.

or just increment it while sleeping, which is when it's needed, which
also looks simpler.

if (external_power) {
+   int refcnt;
mutex_unlock(>bus_mutex);

+   /* prevent the slave from going away */
+   atomic_inc(>refcnt);
sleep_rem = msleep_interruptible(tm);
+   refcnt = w1_unref_slave(sl);
-   if (sleep_rem != 0)
+   if (sleep_rem != 0 || !refcnt)
return -EINTR;

i = mutex_lock_interruptible(>bus_mutex);
if (i != 0)
return i;
} else if (!w1_strong_pullup) {


-- 
David Fries PGP pub CB1EE8F0
http://fries.net/~david/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 0/15] Those patches is used for dw_hdmi audio support

[Yakir Yang]

We found Designware hdmi driver only support audio clock config, we can not 
play sound through it.
To add Designware HDMI Audio support, we make those patch set:
1): fixed dw_hdmi irq bug, add irq control to suspend/resume interfaces.
2): add suspend/resume callback for dw_hdmi rockchip driver.
3): Warp irq control in functions.
4): Combine hdmi_set_clock_regenerator_n() and hdmi_regenerate_cts()
5): Adjust n/cts config order.
6): Set ncts_atomic_write & cts_manual, according to dw_hdmi document.
7): Add audio support for more display resolutions(eg. 800x600).
8): Add audio support for No-CEA display resolutions.
9): Add Audio Sample Channel Status config interfaces to dw_hdmi driver.
10): add audio clock control interfaces to dw_hdmi driver.
11): creat "dw_hdmi-audio" platform device in dw_hdmi driver.
12): add codec driver for hdmi audio, callback dw_hdmi audio config functions.
13): add sound driver for hdmi audio, creat hdmi audio sound card.
14): add dt-bings file and add hdmi_audio node to corresponding dt file.

Changes in v4:
-Correct phy_type assignment bug
- Combine CTS3 registers setting, reduce register operate times
- Combine N3 registers setting
- Add hdmi audio support when monitor support audio
- Give HDMI_FC_AUD_SCHNL8 an readable value
- Rename "hdmi_audio_*" to "dw_hdmi_audio_*"
- Replace delaywork with irq thread, and add suspend/resume interfaces,
  Replace "dw-hdmi-audio" with consecutive strings.
- Add ".pm = _soc_pm_ops,"

Changes in v3:
- Clear Hotplug interrupts before dw_hdmi_fb_register
- Wrap irq control in fucntions
- Setting the .pm member instead of suspend/resume
- Add ID registers parse and record
- Combine hdmi_set_clock_regenerator_n() and hdmi_regenerate_cts()
- Only adjust the n/cts setting order
- Set ncts_atomic_write & cts_manual
- Determine whether sample channel should set by desig_id.
- Delete hdmi_audio_config interface and modify audio clock control functions
- Remove audio_config & get_connect_status callback functions
  and add write/read/mod register callback functions
- Keep audio format config function in dw-hdmi-audio driver
  and remove audio_config & get_connect_status functions,
  move jack control to dw-hdmi-audio completely.
- Delete the operation of jack in rockchip-hdmi-audio driver,
  get ready to switch to simple-audio-card driver.
- modify cpu-of-node to i2s-controller

Changes in v2:
- Add irq control to suspend/resume interfaces
- Add suspend/resume support for dw_hdmi_rockchip driver
- add more n/cts combinations for more display resolutions
- Enable audio support for No-CEA display mode
- Add audio sample channel status setting
- Add audio config interfaces to dw_hdmi driver
- Update the audio control interfaces
- Update dw_hdmi audio control interfaces, and adjust jack report process
- give "codec-name" & "codec-dai-name" an const name
- remove codec-name and codec-dai-name
- rename rockchip,rockchip-hdmi-audio.txt to rockchip,rockchip-dw-hdmi-audio.txt

Daniel Kurtz (3):
  drm: bridge/dw_hdmi: adjust n/cts setting order
  drm: bridge/dw_hdmi: set ncts_atomic_write & cts_manual
  drm: bridge/dw_hdmi: add audio sample channel status setting

Yakir Yang (12):
  drm: bridge/dw_hdmi: add irq control to suspend/resume
  drm: bridge/dw_hdmi: wrap irq control in fucntions
  drm: rockchip/dw_hdmi_rockchip: add resume/suspend support
  drm: bridge/dw_hdmi: add identification registers parse and record
  drm: bridge/dw_hdmi: combine hdmi_set_clock_regenerator_n() and
hdmi_regenerate_cts()
  drm: bridge/dw_hdmi: add audio support for more display resolutions
  drm: bridge/dw_hdmi: enable audio support for No-CEA display
resolutions
  drm: bridge/dw_hdmi: add enable/disable to dw_hdmi_audio callbacks
  drm: bridge/dw_hdmi: creat dw-hdmi-audio platform device
  ASoC: codec/dw-hdmi-audio: add codec driver for dw hdmi audio
  ASoC: rockchip/rockchip-hdmi-audio: add sound driver for hdmi audio
  dt-bindings: Add documentation for Rockchip dw-hdmi-audio

 .../sound/rockchip,rockchip-dw-hdmi-audio.txt  |  12 +
 drivers/gpu/drm/bridge/dw_hdmi.c   | 385 ++---
 drivers/gpu/drm/bridge/dw_hdmi.h   |  53 ++-
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c|  16 +
 include/drm/bridge/dw_hdmi.h   |  17 +
 sound/soc/codecs/Kconfig   |   4 +
 sound/soc/codecs/Makefile  |   2 +
 sound/soc/codecs/dw-hdmi-audio.c   | 379 
 sound/soc/codecs/dw-hdmi-audio.h   |  74 
 sound/soc/rockchip/Kconfig |   9 +
 sound/soc/rockchip/Makefile|   2 +
 sound/soc/rockchip/rockchip_hdmi_audio.c   | 169 +
 12 files changed, 1076 insertions(+), 46 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/sound/rockchip,rockchip-dw-hdmi-audio.txt
 create mode 100644 sound/soc/codecs/dw-hdmi-audio.c
 create mode 100644 

Re: [patch] w1: small cleanup in w1_family_notify()

[Евгений Поляков]

Hi Dan

20.02.2015, 13:53, "Dan Carpenter" :
> "sl->family->fops" and "fops" are the same thing, but it's nicer to use
> "fops" everywhere.
>
> Signed-off-by: Dan Carpenter 

Looks good to me, thank you

Acked-by: Evgeniy Polyakov 

> diff --git a/drivers/w1/w1.c b/drivers/w1/w1.c
> index 181f41c..59f932f 100644
> --- a/drivers/w1/w1.c
> +++ b/drivers/w1/w1.c
> @@ -649,7 +649,7 @@ static int w1_family_notify(unsigned long action, struct 
> w1_slave *sl)
>  break;
>  case BUS_NOTIFY_DEL_DEVICE:
>  if (fops->remove_slave)
> - sl->family->fops->remove_slave(sl);
> + fops->remove_slave(sl);
>  if (fops->groups)
>  sysfs_remove_groups(>dev.kobj, fops->groups);
>  break;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Generic page fault (Was: libsigsegv ....)

[Linus Torvalds]

On Sat, Feb 28, 2015 at 3:02 PM, Benjamin Herrenschmidt
 wrote:
>
> Anyway, here's the current patch:

Ok, I think I like this approach better.

Your FAULT_FLAG_EXEC handling is wrong, though. It shouldn't check
VM_WRITE, it should check VM_EXEC. A bit too much copy-paste ;)

Btw, it's quite possible that we could just do all the PF_PROT
handling at the x86 level, before even calling the generic fault
handler. It's not like we even need the vma or the mm semaphore: if
it's a non-write protection fault, we always SIGSEGV. So why even
bother getting the locks and looking up the page tables etc?

Now, that PF_PROT handling isn't exactly performance-critical, but it
might help to remove the odd x86 special case from the generic code.

  Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCHv3] [media] saa7164: use an MSI interrupt when available

[Brendan McGrath]

Enhances driver to use an MSI interrupt when available.

Adds the module option 'enable_msi' (type bool) which by default is
enabled. Can be set to 'N' to disable.

Fixes (or can reduce the occurrence of) a crash which is most commonly
reported when multiple saa7164 chips are in use. A reported example can
be found here:
http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/83948

Reviewed-by: Steven Toth 
Signed-off-by: Brendan McGrath 
---

Changes since v3:
 * Added link to reported incident in comments
 * Added Reviewed-by tag from Steven Toth
 * Used git send-mail (as my patch got mangled using Thunderbird)
 * Added the linux-kernel mailing list to the recipient list

Note I have not included the Tested-by tag from Kyle Sanderson as his test was 
on v1 (which did not include the module option 'enable_msi') - although much of 
the code in v3 was there is v1.

 drivers/media/pci/saa7164/saa7164-core.c | 40 ++--
 drivers/media/pci/saa7164/saa7164.h  |  1 +
 2 files changed, 39 insertions(+), 2 deletions(-)

diff --git a/drivers/media/pci/saa7164/saa7164-core.c 
b/drivers/media/pci/saa7164/saa7164-core.c
index 4b0bec3..c9a6447 100644
--- a/drivers/media/pci/saa7164/saa7164-core.c
+++ b/drivers/media/pci/saa7164/saa7164-core.c
@@ -85,6 +85,11 @@ module_param(guard_checking, int, 0644);
 MODULE_PARM_DESC(guard_checking,
"enable dma sanity checking for buffer overruns");
 
+static bool enable_msi = true;
+module_param(enable_msi, bool, 0444);
+MODULE_PARM_DESC(enable_msi,
+   "enable the use of an msi interrupt if available");
+
 static unsigned int saa7164_devcount;
 
 static DEFINE_MUTEX(devlist);
@@ -1230,8 +1235,34 @@ static int saa7164_initdev(struct pci_dev *pci_dev,
goto fail_irq;
}
 
-   err = request_irq(pci_dev->irq, saa7164_irq,
-   IRQF_SHARED, dev->name, dev);
+   /* irq bit */
+   if (enable_msi)
+   err = pci_enable_msi(pci_dev);
+
+   if (!err && enable_msi) {
+   /* no error - so request an msi interrupt */
+   err = request_irq(pci_dev->irq, saa7164_irq, 0,
+ dev->name, dev);
+
+   if (err) {
+   /* fall back to legacy interrupt */
+   printk(KERN_ERR "%s() Failed to get an MSI interrupt."
+  " Falling back to a shared IRQ\n", __func__);
+   pci_disable_msi(pci_dev);
+   } else {
+   dev->msi = true;
+   }
+   }
+
+   if ((!enable_msi) || err) {
+   dev->msi = false;
+   /* if we have an error (i.e. we don't have an interrupt)
+or msi is not enabled - fallback to shared interrupt */
+
+   err = request_irq(pci_dev->irq, saa7164_irq,
+ IRQF_SHARED, dev->name, dev);
+   }
+
if (err < 0) {
printk(KERN_ERR "%s: can't get IRQ %d\n", dev->name,
pci_dev->irq);
@@ -1441,6 +1472,11 @@ static void saa7164_finidev(struct pci_dev *pci_dev)
/* unregister stuff */
free_irq(pci_dev->irq, dev);
 
+   if (dev->msi) {
+   pci_disable_msi(pci_dev);
+   dev->msi = false;
+   }
+
mutex_lock();
list_del(>devlist);
mutex_unlock();
diff --git a/drivers/media/pci/saa7164/saa7164.h 
b/drivers/media/pci/saa7164/saa7164.h
index cd1a07c..6df4b252 100644
--- a/drivers/media/pci/saa7164/saa7164.h
+++ b/drivers/media/pci/saa7164/saa7164.h
@@ -459,6 +459,7 @@ struct saa7164_dev {
/* Interrupt status and ack registers */
u32 int_status;
u32 int_ack;
+   u32 msi;
 
struct cmd  cmds[SAA_CMD_MAX_MSG_UNITS];
struct mutexlock;
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ACPI regression with 3.19+

[Rafael J. Wysocki]

On Saturday, February 28, 2015 10:35:21 AM Prakash Punnoor wrote:
> This is a multi-part message in MIME format.
> --080704070901080904040008
> Content-Type: text/plain; charset=utf-8
> Content-Transfer-Encoding: 7bit
> 
> Hallo,
> 
> my system won't boot with current GIT kernel (see attached screenshot).
> The system seems somewhat frozen (cannot ssh into it), but magic sysrq
> still works. I bisected the problem to commit
> 593669c2ac0fe18baee04a3cd5539a148aa48574.

Thanks for reporting, we're working on it.


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/2] drivers: cpuidle: minor suspend-to-idle fixes

[Rafael J. Wysocki]

On Saturday, February 28, 2015 11:54:23 AM Lorenzo Pieralisi wrote:
> On Fri, Feb 27, 2015 at 10:11:54PM +, Rafael J. Wysocki wrote:
> > On Friday, February 27, 2015 10:00:00 AM Lorenzo Pieralisi wrote:
> > > [CC'ed Preeti]
> > > 
> > > On Thu, Feb 26, 2015 at 11:37:54PM +, Rafael J. Wysocki wrote:
> > > > Me versions of the two $subject patches follow.
> > > 
> > > Thank you. I am testing them and I have run into the following issue.
> > > 
> > > Starting with:
> > > 
> > > 3810631 ("PM / sleep: Re-implement suspend-to-idle handling")
> > > 
> > > the suspend-to-idle code path in the cpuidle_idle_call() bypasses
> > > the CPUIDLE_FLAG_TIMER_STOP code path entirely.
> > 
> > Hmm, this looks like a mistake.  Sorry about that.
> 
> Thank you for looking into this !
> 
> > > Now, on most of
> > > the current ARM platforms, the deepest idle state loses the tick device
> > > context, therefore this means that going to idle through
> > > suspend-to-idle becomes a brute force way of nuking the tick,
> > > unless I am missing something here.
> > > 
> > > I am experiencing hangs on resume from suspend-to-idle when the broadcast
> > > timer is the broadast-hrtimer (ie there is no HW broadcast timer in the
> > > platform) and the deepest idle states lose the tick device context (ie
> > > they are CPUIDLE_FLAG_TIMER_STOP), I hope Preeti can help me test this on
> > > Power, still chasing the issue.
> > > 
> > > I could not reproduce the issue with a HW broadcast timer device.
> > > 
> > > Platform has deepest idle states that allow CPUs shutdown where the
> > > local tick device is gone on entry, I am trying to provide you with a
> > > backtrace, I need time to debug.
> > > 
> > > The question I have: is it safe to bypass the CPUIDLE_FLAG_TIMER_STOP
> > > and related broadcast mode entry/exit in the suspend-to-idle path ?
> > > 
> > > I do not think it is, but I am asking.
> > 
> > It isn't in general, but it would be OK in the enter_freeze_proper() path
> > where the tick is suspended anyway.
> 
> Entering state through enter_freeze() (ie adding the function pointer
> in the idle states, on platforms where it is appropriate), therefore
> freezing the tick solves the issue, so I think we should patch all ARM
> drivers that can benefit from this interesting new feature.
> 
> > > I can "force" tick freeze by initializing the enter_freeze pointer
> > > in the idle states (that's the next thing I will test), but still, for
> > > platforms where that's not possible my question above is still valid.
> > 
> > Right.
> > 
> > Does the patch below help (on top of the previous ones)?
> 
> I need HW to test, I will do that first thing on Monday, and send
> you the appropriate tags. I already put together a similar patch
> and tested it yesterday, so I can say already that it solves the
> problem, I will test your patch on Monday and get back to you
> (patch 1 and 2 in this series already tested on a platform with no
> CPUidle driver registered, and they work and fix the NULL drv
> dereference issue).

Cool, thanks!

Below is a slightly cleaner version of the patch with a changelog.  Can you
please test this one?

Rafael


---
From: Rafael J. Wysocki 
Subject: cpuidle / sleep: Use broadcast timer for states that stop local timer

Commit 381063133246 (PM / sleep: Re-implement suspend-to-idle handling)
overlooked the fact that entering some sufficiently deep idle states
by CPUs may cause their local timers to stop and in those cases it
is necessary to switch over to a broadcase timer prior to entering
the idle state.  If the cpuidle driver in use does not provide
the new ->enter_freeze callback for any of the idle states, that
problem affects suspend-to-idle too, but it is not taken into account
after the changes made by commit 381063133246.

Fix that by moving the CPUIDLE_FLAG_TIMER_STOP flag check and the
broadcast timer manipulations following it from cpuidle_idle_call()
to cpuidle_enter() which will cause them to be done, if necessary,
in the suspend-to-idle case as well as for runtime idle.

Fixes: 381063133246 (PM / sleep: Re-implement suspend-to-idle handling)
Reported-by: Lorenzo Pieralisi 
Signed-off-by: Rafael J. Wysocki 
---
 drivers/cpuidle/cpuidle.c |   34 +-
 kernel/sched/idle.c   |   17 ++---
 2 files changed, 31 insertions(+), 20 deletions(-)

Index: linux-pm/drivers/cpuidle/cpuidle.c
===
--- linux-pm.orig/drivers/cpuidle/cpuidle.c
+++ linux-pm/drivers/cpuidle/cpuidle.c
@@ -230,15 +230,39 @@ int cpuidle_select(struct cpuidle_driver
  * @dev:   the cpuidle device
  * @index: the index in the idle state table
  *
- * Returns the index in the idle state, < 0 in case of error.
- * The error code depends on the backend driver
+ * Returns the index in the idle state, < 0 in case of error.  -EBUSY is
+ * returned to indicate that the target state was temporarily inaccessible.
+ * The other error codes 

Re: [PATCH] ipc/sem.c: Update/correct memory barriers.

[Paul E. McKenney]

On Sat, Feb 28, 2015 at 10:45:33PM +0100, Peter Zijlstra wrote:
> On Sat, Feb 28, 2015 at 09:36:15PM +0100, Manfred Spraul wrote:
> > +/*
> > + * Place this after a control barrier (such as e.g. a spin_unlock_wait())
> > + * to ensure that reads cannot be moved ahead of the control_barrier.
> > + * Writes do not need a barrier, they are not speculated and thus cannot
> > + * pass the control barrier.
> > + */
> > +#ifndef smp_mb__after_control_barrier
> > +#define smp_mb__after_control_barrier()smp_rmb()
> > +#endif
> 
> Sorry to go bike shedding again; but should we call this:
> 
> smp_acquire__after_control_barrier() ?
> 
> The thing is; its not a full MB because:
> 
>  - stores might actually creep into it; while the control dependency
>guarantees stores will not creep out, nothing is stopping them from
>getting in;
> 
>  - its not transitive, and our MB is defined to be so.
> 
> Oleg, Paul?

The idea is that this would become a no-op on x86, s390, sparc , an isb
instruction on ARM, an isync instruction on Power, and I cannot remember
what on Itanium?  The other idea being to provide read-to-read control
ordering in addition to the current read-to-write control ordering?

Thanx, Paul

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH] module: Optimize __module_address() using a latched RB-tree

[Paul E. McKenney]

On Sat, Feb 28, 2015 at 05:56:54PM +0100, Peter Zijlstra wrote:
> On Sat, Feb 28, 2015 at 05:41:12PM +0100, Peter Zijlstra wrote:
> > > > > + rb_link_node(>node, parent, link);
> > > > 
> > > > This makes the new module visible to readers, if I understand correctly.
> > > 
> > > You do.
> > 
> > I think I have reconsidered; this does not in fact make it visible.
> 
> Ah; never mind, it is. An iterator could have started in data[0], gone
> on holiday while the modification took place, and resumed once it is
> done and magically see the element appear.
> 
> Therefore we do indeed need the atomic publishing and I think this also
> settles my question about Alpha.

Whew!

Though otherwise whatever you were doing would have been pretty cool
and fun to learn about.  ;-)

Thanx, Paul

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH] module: Optimize __module_address() using a latched RB-tree

[Paul E. McKenney]

On Fri, Feb 27, 2015 at 11:01:14AM +0100, Peter Zijlstra wrote:
> On Thu, Feb 26, 2015 at 11:41:44AM -0800, Paul E. McKenney wrote:
> > > As per the above argument; without doing the whole READ/WRITE_ONCE for
> > > the rb tree primitives, I think we're fine. We don't actually need the
> > > read_barrier_depends() I think.
> > > 
> > > I think this because raw_read_seqcount() will issue an rmb, which should
> > > be enough for the 'stable' tree. For the unstable one we don't care as
> > > long as we don't see split loads/stores.
> > 
> > I agree that raw_read_seqcount() will issue an rmb(), but that won't help.
> > For Alpha, you need the smp_rmb() to be between the load of any given
> > pointer and the first dereference of that same pointer.
> 
> OK, it seems I'm confused on Alpha, perhaps you can clarify.
> 
> My confusion stems from the fact that when things are properly
> serialized with locks we do not need these additional barriers.

The readers hold locks?  Keep in mind that raw_read_seqcount() isn't
really a lock -- updates can run concurrently with a read.  A doomed
read, to be sure, but nevertheless a read that is traversing pointers
that are changing out from under it.

> Then why would we need them to correctly iterate the stable copy of the
> tree?
> 
> I appreciate we would need them to correctly iterate an true lockless
> data structure, but our in-flight copy of the tree cannot be correctly
> iterated anyway, all we want is for that iteration to:
> 
>   1) only observe valid nodes -- ie. no pointers out into the wild due
>   to split load/stores.
> 
>   2) terminate -- ie. not get stuck in loops.

True, but don't new nodes get inserted into a tree that might possibly
be concurrently read?

> And I don't see that read_barrier_depends() helping with either for the
> unstable tree; 1) is guaranteed by my patch making the modifiers user
> WRITE_ONCE(), and 2) we agreed is guaranteed by the modifiers not having
> loops in program order, any cache effects will disappear over time.

Well, if the readers and writer are really truly excluding each other,
then no problem.  But if the readers really can run concurrently with
writers, even if the readers will subsequently retry, you do need those
barriers on Alpha.

The canonical URL on this topic:

http://www.openvms.compaq.com/wizard/wiz_2637.html

> > > No, I think someone is 'hoping' sync_rcu() implies sync_sched(). But
> > > yes, I should look harder at this. I was assuming the existing code was
> > > OK here.
> > 
> > I am not blaming you for the code itself, but rather just blaming you
> > for causing me to notice that the code was broken.  ;-)
> > 
> > How about if I make something that allows overlapping grace periods,
> > so that we could be safe without latency penalty?  One approach would
> > be a synchronize_rcu_mult() with a bitmask indicating which to wait for.
> > Another would be to make variants of get_state_synchronize_rcu() and
> > cond_synchronize_rcu() for RCU-sched as well as for RCU, but also to
> > make get_state_synchronize_rcu() force a grace period to start if
> > one was not already in progress.
> 
> This is module unload, not a fast path by anyones measure I think.
> However if you do go about making such a primitive I know of at least
> one other place this could be used; we have the following in
> _cpu_down():
> 
> #ifdef CONFIG_PREEMPT
>   synchronize_sched();
> #endif
>   synchronize_rcu();

OK, definitely seems worth thinking about, then.

Thanx, Paul

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RFC 0/2] add nproc cgroup subsystem

[Johannes Weiner]

On Sat, Feb 28, 2015 at 02:26:58PM -0800, Tim Hockin wrote:
> On Sat, Feb 28, 2015 at 8:57 AM, Tejun Heo  wrote:
> >
> > On Sat, Feb 28, 2015 at 08:48:12AM -0800, Tim Hockin wrote:
> > > I am sorry that real-user problems are not perceived as substantial.  This
> > > was/is a real issue for us.  Being in limbo for years on end might not be 
> > > a
> > > technical point, but I do think it matters, and that was my point.
> >
> > It's a problem which is localized to you and caused by the specific
> > problems of your setup.  This isn't a wide-spread problem at all and
> > the world doesn't revolve around you.  If your setup is so messed up
> > as to require sticking to 16bit pids, handle that locally.  If
> > something at larger scale eases that handling, you get lucky.  If not,
> > it's *your* predicament to deal with.  The rest of the world doesn't
> > exist to wipe your ass.
> 
> Wow, so much anger.

Yeah, quite surprising after such an intellectually honest discussion:

: On Fri, Feb 27, 2015 at 01:45:09PM -0800, Tim Hockin wrote:
: > At least 3 or 4 people have INDEPENDENTLY decided this is what is
: > causing them pain and tried to fix it and invested the time to send a
: > patch says that it is actually a thing.  There exists a problem that
: > you are disallowing to be fixed.  Do you recognize that users are
: > experiencing pain?  Why do you hate your users? :)

[...]

: > Are you willing to put a drop-dead date on it?  If we don't have
: > kmemcg working well enough to _actually_ bound PID usage and FD usage
: > by, say, June 1st, will you then accept a patch to this effect?  If
: > the answer is no, then I have zero faith that it's coming any time
: > soon - I heard this 2 years ago.  I believed you then.

> I'm not even sure how to respond, so I'll just say this and sign
> off.  All I want is a better, friendlier, more useful system
> overall.  We clearly have different ways of looking at the problem.

Overlapping features and inconsistent userspace interfaces are only
better for the people that pick the hacks.  They are the opposite of
friendly and useful.  They are also horrible to maintain, which could
be a reason why you constantly disagree with the people that cleaned
up this unholy mess and are now trying to keep a balance between your
short term interests and the long-term health of the Linux kernel.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH net-next] Driver: Vmxnet3: Copy TCP header to mapped frame for IPv6 packets

[Sergei Shtylyov]

Hello.

On 02/28/2015 10:58 PM, Shrikrishna Khare wrote:


Allows for packet parsing to be done by the fast path. This performance
optimization already exists for IPv4. Add similar logic for IPv6.



Signed-off-by: Amitabha Banerjee 
Signed-off-by: Shrikrishna Khare 
---
  drivers/net/vmxnet3/vmxnet3_drv.c | 26 --
  drivers/net/vmxnet3/vmxnet3_int.h |  5 +++--
  2 files changed, 19 insertions(+), 12 deletions(-)



diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c 
b/drivers/net/vmxnet3/vmxnet3_drv.c
index 294214c..9216e6a 100644
--- a/drivers/net/vmxnet3/vmxnet3_drv.c
+++ b/drivers/net/vmxnet3/vmxnet3_drv.c

[...]

@@ -831,16 +832,20 @@ vmxnet3_parse_and_copy_hdr(struct sk_buff *skb, struct 
vmxnet3_tx_queue *tq,
if (ctx->ipv4) {
const struct iphdr *iph = ip_hdr(skb);

-   if (iph->protocol == IPPROTO_TCP)
-   ctx->l4_hdr_size = tcp_hdrlen(skb);
-   else if (iph->protocol == IPPROTO_UDP)
-   ctx->l4_hdr_size = sizeof(struct 
udphdr);
-   else
-   ctx->l4_hdr_size = 0;
-   } else {
-   /* for simplicity, don't copy L4 headers */
-   ctx->l4_hdr_size = 0;
+   protocol = iph->protocol;
+   } else if (ctx->ipv6) {
+   const struct ipv6hdr *ipv6h = ipv6_hdr(skb);
+
+   protocol = ipv6h->nexthdr;
}
+
+   if (protocol == IPPROTO_TCP)
+   ctx->l4_hdr_size = tcp_hdrlen(skb);
+   else if (protocol == IPPROTO_UDP)
+   ctx->l4_hdr_size = sizeof(struct udphdr);
+   else
+   ctx->l4_hdr_size = 0;
+


   I think the above is asking to be a 'switch (protocol)' instead.

WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] rtc: add Abracon ABx80x driver

[Alexandre Belloni]

On 28/02/2015 at 13:22:54 -0800, Joe Perches wrote :
> My thought was that it might be better to
> use a local struct rtc_time r like
> 
>   r.tm_sec = bcd2bin(date[AB08XX_REG_SC] & 0x7F);
>   r.tm_min = bcd2bin(date[AB08XX_REG_MN] & 0x7F);
>   r.tm_hour = bcd2bin(date[AB08XX_REG_HR] & 0x3F);
>   r.tm_wday = date[AB08XX_REG_WD] & 0x7;
>   r.tm_mday = bcd2bin(date[AB08XX_REG_DA] & 0x3F);
>   r.tm_mon = bcd2bin(date[AB08XX_REG_MO] & 0x1F) - 1;
>   r.tm_year = bcd2bin(date[AB08XX_REG_YR]);
>   if (r.tm_year < 70)
>   r.tm_year += 100;
> 
>   err = rtc_valid_tm();
>   if (!err)
>   *tm = r;
>   else
>   dev_err(>dev, "retrieved date/time is not valid\n");
> 
>   return err;
> 

I'm sure this is not needed as userspace has to bail out if the ioctl
fails. I'll let that up to the rtc maintainers though.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Generic page fault (Was: libsigsegv ....)

[Benjamin Herrenschmidt]

On Sun, 2015-03-01 at 09:16 +1100, Benjamin Herrenschmidt wrote:
> So for error handling, I'm trying to simply return the VM_FAULT_* flags
> from generic_page_fault see where that takes us. That's a way to avoid
> passing an arch specific struct around. It also allows my hack to
> account major faults with the hypervisor to be done outside the generic
> code completely (no hook).
>
> .../...

Here's what it looks like for x86 only and without completely sorting
out the fatal signal business. However I might still have to do the
arch pointer you mentioned for sparc and possibly other archs, but so
far it looks better already.

Note that if I add that arch pointer, I might stop messing around
or even returning "fault" and instead just return a simple enum
minor,major,error and let inline arch hooks populate the arch pointer
with the error details in whatever fashion the arch prefers. However
I suspect they'll all end up with sig and si_code in there...

Anyway, here's the current patch:

 arch/x86/include/asm/fault.h |  21 
 arch/x86/mm/fault.c  | 233 ---
 include/linux/fault.h|  24 +
 include/linux/mm.h   |   5 +-
 mm/Makefile  |   2 +-
 mm/fault.c   | 196 
 6 files changed, 266 insertions(+), 215 deletions(-)
 create mode 100644 arch/x86/include/asm/fault.h
 create mode 100644 include/linux/fault.h
 create mode 100644 mm/fault.c

diff --git a/arch/x86/include/asm/fault.h b/arch/x86/include/asm/fault.h
new file mode 100644
index 000..04263ec
--- /dev/null
+++ b/arch/x86/include/asm/fault.h
@@ -0,0 +1,21 @@
+#ifndef _ASM_X86_FAULT_H
+#define _ASM_X86_FAULT_H
+
+#include 
+#include 
+
+/* Check if the stack is allowed to grow during a user page fault */
+static inline bool stack_can_grow(struct pt_regs *regs, unsigned long flags,
+ unsigned long address,
+ struct vm_area_struct *vma)
+{
+   /*
+* Accessing the stack below %sp is always a bug.
+* The large cushion allows instructions like enter
+* and pusha to work. ("enter $65535, $31" pushes
+* 32 pointers and then decrements %sp by 65535.)
+*/
+   return address + 65536 + 32 * sizeof(unsigned long) >= regs->sp;
+}
+
+#endif /*  _ASM_X86_FAULT_H */
diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index ede025f..19a8a91 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -13,6 +13,7 @@
 #include  /* hstate_index_to_shift*/
 #include /* prefetchw*/
 #include /* exception_enter(), ...   */
+#include 
 
 #include  /* dotraplinkage, ...   */
 #include/* pgd_*(), ... */
@@ -748,8 +749,7 @@ show_signal_msg(struct pt_regs *regs, unsigned long 
error_code,
printk(KERN_CONT "\n");
 }
 
-static void
-__bad_area_nosemaphore(struct pt_regs *regs, unsigned long error_code,
+static void __bad_area(struct pt_regs *regs, unsigned long error_code,
   unsigned long address, int si_code)
 {
struct task_struct *tsk = current;
@@ -804,39 +804,10 @@ __bad_area_nosemaphore(struct pt_regs *regs, unsigned 
long error_code,
no_context(regs, error_code, address, SIGSEGV, si_code);
 }
 
-static noinline void
-bad_area_nosemaphore(struct pt_regs *regs, unsigned long error_code,
-unsigned long address)
-{
-   __bad_area_nosemaphore(regs, error_code, address, SEGV_MAPERR);
-}
-
-static void
-__bad_area(struct pt_regs *regs, unsigned long error_code,
-  unsigned long address, int si_code)
-{
-   struct mm_struct *mm = current->mm;
-
-   /*
-* Something tried to access memory that isn't in our memory map..
-* Fix it, but check if it's kernel or user first..
-*/
-   up_read(>mmap_sem);
-
-   __bad_area_nosemaphore(regs, error_code, address, si_code);
-}
-
-static noinline void
-bad_area(struct pt_regs *regs, unsigned long error_code, unsigned long address)
-{
-   __bad_area(regs, error_code, address, SEGV_MAPERR);
-}
-
-static noinline void
-bad_area_access_error(struct pt_regs *regs, unsigned long error_code,
- unsigned long address)
+static inline void bad_area(struct pt_regs *regs, unsigned long error_code,
+   unsigned long address, int si_code)
 {
-   __bad_area(regs, error_code, address, SEGV_ACCERR);
+   __bad_area(regs, error_code, address, si_code);
 }
 
 static void
@@ -871,40 +842,6 @@ do_sigbus(struct pt_regs *regs, unsigned long error_code, 
unsigned long address,
force_sig_info_fault(SIGBUS, code, address, tsk, fault);
 }
 
-static noinline void
-mm_fault_error(struct pt_regs *regs, unsigned long error_code,
-  unsigned long address, unsigned int fault)
-{
-   if (fatal_signal_pending(current) && 

Re: [PATCH] perf tools: Fix pthread_attr_setaffinity_np() feature detection on Ubuntu systems

[Jiri Olsa]

On Sat, Feb 28, 2015 at 08:49:27AM +0100, Ingo Molnar wrote:

SNIP

> 
>   0695e57b9a6a perf tools: Factor features display code
> 
> Firstly, 'factor' isn't a verb we use for code, 'factor out' is. But 
> it's not really factoring out - it separates the code. Did this title 
> want to say:
> 
>perf tools: Separate feature display code into three parts
> 
> ? The title was absolutely unreadable.
> 
> Then it introduces two new makefile variables: LIB_FEATURE_TESTS and 
> VF_FEATURE_TESTS. LIB_FEATURE_TESTS is reasonably self-explanatory, 
> but wth is VF_FEATURE_TESTS?
> 
> More importantly, why isn't there a _single_ comment explaining their 
> use in the Makefile - _especially_ since CORE_FEATURE_TESTS is 
> explained so well, it's not like a bad example had to be followed.
> 
> Using cryptic abbreviations like 'VF' adds insult to injury. It took 
> me some time to figure out that it probably means 'Verbose Features'.
> 
> New feature detection adds to all these variables so people will just 
> guess to which to add and why.
> 
> Guys, this particular change was rushed and not explained well enough, 
> and it made debugging from that point on harder. Please slow down a 
> bit.

agreed, sry about that.. I'll try to clean it up while moving
features detection into tools/ as you suggested before

> 
> 
> 

SNIP

> diff --git 
> a/tools/perf/config/feature-checks/test-pthread-attr-setaffinity-np.c 
> b/tools/perf/config/feature-checks/test-pthread-attr-setaffinity-np.c
> index 0a0d3ecb4e8a..85ab83e6a42f 100644
> --- a/tools/perf/config/feature-checks/test-pthread-attr-setaffinity-np.c
> +++ b/tools/perf/config/feature-checks/test-pthread-attr-setaffinity-np.c
> @@ -5,10 +5,12 @@ int main(void)
>  {
>   int ret = 0;
>   pthread_attr_t thread_attr;
> + cpu_set_t cpu_mask;
>  
>   pthread_attr_init(_attr);
> - /* don't care abt exact args, just the API itself in libpthread */
> - ret = pthread_attr_setaffinity_np(_attr, 0, NULL);
> + CPU_ZERO(_mask);
> +
> + ret = pthread_attr_setaffinity_np(_attr, sizeof(cpu_mask), 
> _mask);

I think Arnaldo got this one covered in perf/urgent already,
but I might have missed something..

jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: 3.19 kernel: BUG: unable to handle kernel NULL pointer dereference

[Justin Piszcz]

> -Original Message-
> From: Justin Piszcz [mailto:jpis...@lucidpixels.com]
> Sent: Saturday, February 28, 2015 5:19 PM
> To: linux-kernel@vger.kernel.org
> Subject: RE: 3.19 kernel: BUG: unable to handle kernel NULL pointer
> dereference
> 
> 
> 
> > -Original Message-
> > From: Justin Piszcz [mailto:jpis...@lucidpixels.com]
> > Sent: Friday, February 27, 2015 10:54 AM
> > To: linux-kernel@vger.kernel.org
> > Subject: RE: 3.19 kernel: BUG: unable to handle kernel NULL pointer
> > dereference
> >
> >
> >
> > > -Original Message-
> > > From: Justin Piszcz [mailto:jpis...@lucidpixels.com]
> > > Sent: Friday, February 27, 2015 9:54 AM
> > > To: linux-kernel@vger.kernel.org
> > > Subject: 3.19 kernel: BUG: unable to handle kernel NULL pointer
> > dereference
> > >
> > > Hello,
> > >
> > > With kernel 3.15, I do not recall having any issues, with 3.19, I am
> > getting
> > > a kernel crash when I copy files over NFS from machine A to B.
> > > Is this a known issue?
> > >
> > > I suspect it has to do something with this:
> > > Feb 27 09:31:20 remote-host [   15.745342] dmar: DRHD: handling fault
> > status
> > > reg 2
> > > Feb 27 09:31:20 remote-host [   15.745361] dmar: DMAR:[DMA Read]
> > Request
> > > device [04:00.0] fault addr 0 #012[   15.745361] DMAR:[fault reason
06]
> > PTE
> > > Read access is not set
> > >
> >
> > [ .. ]
> >
> > Here is another crash with debugging enabled:
> >
> 
> [ .. ]
> 

[ . ]

Sorry for the spam-- still occurs, will remove the NVIDIA card, looks like
it is still an issue for users--
https://bugs.freedesktop.org/show_bug.cgi?id=66696

Justin.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RFC 0/2] add nproc cgroup subsystem

[Tejun Heo]

On Sat, Feb 28, 2015 at 02:26:58PM -0800, Tim Hockin wrote:
> Wow, so much anger.  I'm not even sure how to respond, so I'll just
> say this and sign off.  All I want is a better, friendlier, more
> useful system overall.  We clearly have different ways of looking at
> the problem.

Can you communicate anything w/o passive aggression?  If you have a
technical point, just state that.  Can you at least agree that we
shouldn't be making design decisions based on 16bit pid_t?

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Generic page fault (Was: libsigsegv ....)

[Benjamin Herrenschmidt]

On Sun, 2015-03-01 at 09:16 +1100, Benjamin Herrenschmidt wrote:
> So for error handling, I'm trying to simply return the VM_FAULT_* flags
> from generic_page_fault see where that takes us. That's a way to avoid
> passing an arch specific struct around. It also allows my hack to
> account major faults with the hypervisor to be done outside the generic
> code completely (no hook).

I suspect sparc64 will defeat the "not passing an arch struct around"
though... oh well.

Ben.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Generic page fault (Was: libsigsegv ....)

[Benjamin Herrenschmidt]

On Sat, 2015-02-28 at 13:49 -0800, Linus Torvalds wrote:

 .../...

>  - we handle write faults separately (see the first part of access_error()
> 
>  - so now we know it was a read or an instruction fetch
> 
>  - if PF_PROT is set, that means that the present bit was set in the
> page tables, so it must have been an exec access to a NX page
> 
>  - otherwise, we just say "PROTNONE means no access, otherwise
> populate the page tables"
> 
> .. and if it turns out that it was a PF_INSTR to a NX page, we'll end
> up taking the page fault *again* after it's been populated, and now
> since the page table was populated, the access_error() will catch it
> with the PF_PROT case.
> 
> Or something like that. I might have screwed up some detail, but it
> should all work.

I see, it should work yes, I'll still add that FAULT_FLAG_EXEC for
those who can tell reliably but it shouldn't hurt for x86 to not set it.

Cheers,
Ben.


>  Linus
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arch" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RFC 0/2] add nproc cgroup subsystem

[Tim Hockin]

On Sat, Feb 28, 2015 at 8:57 AM, Tejun Heo  wrote:
>
> On Sat, Feb 28, 2015 at 08:48:12AM -0800, Tim Hockin wrote:
> > I am sorry that real-user problems are not perceived as substantial.  This
> > was/is a real issue for us.  Being in limbo for years on end might not be a
> > technical point, but I do think it matters, and that was my point.
>
> It's a problem which is localized to you and caused by the specific
> problems of your setup.  This isn't a wide-spread problem at all and
> the world doesn't revolve around you.  If your setup is so messed up
> as to require sticking to 16bit pids, handle that locally.  If
> something at larger scale eases that handling, you get lucky.  If not,
> it's *your* predicament to deal with.  The rest of the world doesn't
> exist to wipe your ass.

Wow, so much anger.  I'm not even sure how to respond, so I'll just
say this and sign off.  All I want is a better, friendlier, more
useful system overall.  We clearly have different ways of looking at
the problem.

No antagonism intended

Tim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch] perf_event_open.2: 3.19 PERF_SAMPLE_REGS_INTR support

[Jiri Olsa]

On Thu, Feb 12, 2015 at 12:33:09AM -0500, Vince Weaver wrote:
> 
> This manpage patch relates to the addition of PERF_SAMPLE_REGS_INTR
> support added in the following commit:

hi,
sorry for late response..

> 
> perf_sample_regs_intr; Linux 3.19
>   commit 60e2364e60e86e81bc6377f49779779e6120977f
>   Author: Stephane Eranian 
> 
> perf: Add ability to sample machine state on interrupt
> 
>   Reviewed-by: Jiri Olsa 
>   Signed-off-by: Stephane Eranian 
>   Signed-off-by: Peter Zijlstra (Intel) 
>   Cc: cebbert.l...@gmail.com
>   Cc: Arnaldo Carvalho de Melo 
>   Cc: Linus Torvalds 
>   Cc: linux-...@vger.kernel.org
>   Link: 
> http://lkml.kernel.org/r/1411559322-16548-2-git-send-email-eran...@google.com
>   Signed-off-by: Ingo Molnar 
> 
> From what I can tell the primary difference between 
> PERF_SAMPLE_REGS_INTR and the existing PERF_SAMPLE_REGS_USER
> is that the new support will return kernel register values

correct

> (I assume that's not some sort of info leak?).
> 
> In theory also when precise_ip is set high enough you should
> get the PEBS register state rather than the PMU interrupt
> register state, but I was unable to construct a test case

yep, if precise_ip is set you'll get the registers values
from PEBS for PERF_SAMPLE_REGS_INTR set.. I dont think we
do this for PERF_SAMPLE_REGS_USER regs

> on a Haswell system where I got different values with
> precise_ip=0, precise_ip=2, or by using PERF_SAMPLE_REGS_USER
> instead.  Am I missing something about how to use this new 
> interface?

Could you please describe in more details what was your test doing?

the man page change below looks good to me

thanks,
jirka

> 
> Signed-off-by: Vince Weaver 
> 
> diff --git a/man2/perf_event_open.2 b/man2/perf_event_open.2
> index 39c8d8c..ca03928 100644
> --- a/man2/perf_event_open.2
> +++ b/man2/perf_event_open.2
> @@ -256,7 +256,7 @@ struct perf_event_attr {
>  __u32 sample_stack_user;/* size of stack to dump on
> samples */
>  __u32 __reserved_2; /* Align to u64 */
> -
> +__u64 sample_regs_intr; /* regs to dump on samples */
>  };
>  .fi
>  .in
> @@ -350,6 +350,11 @@ and
>  .I sample_stack_user
>  in Linux 3.7.
>  .\" commit 1659d129ed014b715b0b2120e6fd929bdd33ed03
> +.B PERF_ATTR_SIZE_VER4
> +is 104 corresponding to the addition of
> +.I sample_regs_intr
> +in Linux 3.19.
> +.\" commit 60e2364e60e86e81bc6377f49779779e6120977f
>  .TP
>  .I "config"
>  This specifies which event you want, in conjunction with
> @@ -752,6 +757,23 @@ event must be measured or no values will be recorded.
>  Also note that some perf_event measurements, such as sampled
>  cycle counting, may cause extraneous aborts (by causing an
>  interrupt during a transaction).
> +.TP
> +.BR PERF_SAMPLE_REGS_INTR " (since Linux 3.19)"
> +.\" commit 60e2364e60e86e81bc6377f49779779e6120977f
> +Records a subset of the current CPU register state
> +as specified by
> +.IR sample_regs_intr .
> +Unlike
> +.B PERF_SAMPLE_REGS_USER
> +the register values will return kernel register
> +state if the overflow happened while kernel
> +code is running.
> +If the CPU supports hardware sampling of
> +register state (as does PEBS on x86) and
> +.I precise_ip
> +is set higher than zero then the register
> +values returned are those captured by
> +hardware.
>  .RE
>  .TP
>  .IR "read_format"
> @@ -1855,6 +1877,9 @@ struct {
>  u64   weight; /* if PERF_SAMPLE_WEIGHT */
>  u64   data_src;   /* if PERF_SAMPLE_DATA_SRC */
>  u64   transaction;/* if PERF_SAMPLE_TRANSACTION */
> +u64   abi;/* if PERF_SAMPLE_REGS_INTR */
> +u64   regs[weight(mask)];
> +  /* if PERF_SAMPLE_REGS_INTR */
>  };
>  .fi
>  .RS 4
> @@ -2242,6 +2267,27 @@ the high 32 bits of the field by shifting right by
>  .B PERF_TXN_ABORT_SHIFT
>  and masking with
>  .BR PERF_TXN_ABORT_MASK .
> +.TP
> +.IR abi ", " regs[weight(mask)]
> +If
> +.B PERF_SAMPLE_REGS_INTR
> +is enabled, then the user CPU registers are recorded.
> +
> +The
> +.I abi
> +field is one of
> +.BR PERF_SAMPLE_REGS_ABI_NONE ", " PERF_SAMPLE_REGS_ABI_32 " or "
> +.BR PERF_SAMPLE_REGS_ABI_64 .
> +
> +The
> +.I regs
> +field is an array of the CPU registers that were specified by
> +the
> +.I sample_regs_intr
> +attr field.
> +The number of values is the number of bits set in the
> +.I sample_regs_intr
> +bit mask.
>  .RE
>  .TP
>  .B PERF_RECORD_MMAP2
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH][v2] dmaengine: s3c24xx: Fix spelling mistake in dev_err mistake

[Colin King]

From: Colin Ian King 

Fix spelling mistake, "aquire" -> "acquire" and missing newline (as
spotted by Joe Perches.

Signed-off-by: Colin Ian King 
---
 drivers/dma/s3c24xx-dma.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/dma/s3c24xx-dma.c b/drivers/dma/s3c24xx-dma.c
index 2f91da3..4eae6d5 100644
--- a/drivers/dma/s3c24xx-dma.c
+++ b/drivers/dma/s3c24xx-dma.c
@@ -1238,7 +1238,7 @@ static int s3c24xx_dma_probe(struct platform_device *pdev)
if (!s3cdma->phy_chans)
return -ENOMEM;
 
-   /* aquire irqs and clocks for all physical channels */
+   /* acquire irqs and clocks for all physical channels */
for (i = 0; i < pdata->num_phy_channels; i++) {
struct s3c24xx_dma_phy *phy = >phy_chans[i];
char clk_name[6];
@@ -1266,7 +1266,7 @@ static int s3c24xx_dma_probe(struct platform_device *pdev)
sprintf(clk_name, "dma.%d", i);
phy->clk = devm_clk_get(>dev, clk_name);
if (IS_ERR(phy->clk) && sdata->has_clocks) {
-   dev_err(>dev, "unable to aquire clock for 
channel %d, error %lu",
+   dev_err(>dev, "unable to acquire clock 
for channel %d, error %lu\n",
i, PTR_ERR(phy->clk));
continue;
}
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: 3.19 kernel: BUG: unable to handle kernel NULL pointer dereference

[Justin Piszcz]

> -Original Message-
> From: Justin Piszcz [mailto:jpis...@lucidpixels.com]
> Sent: Friday, February 27, 2015 10:54 AM
> To: linux-kernel@vger.kernel.org
> Subject: RE: 3.19 kernel: BUG: unable to handle kernel NULL pointer
> dereference
> 
> 
> 
> > -Original Message-
> > From: Justin Piszcz [mailto:jpis...@lucidpixels.com]
> > Sent: Friday, February 27, 2015 9:54 AM
> > To: linux-kernel@vger.kernel.org
> > Subject: 3.19 kernel: BUG: unable to handle kernel NULL pointer
> dereference
> >
> > Hello,
> >
> > With kernel 3.15, I do not recall having any issues, with 3.19, I am
> getting
> > a kernel crash when I copy files over NFS from machine A to B.
> > Is this a known issue?
> >
> > I suspect it has to do something with this:
> > Feb 27 09:31:20 remote-host [   15.745342] dmar: DRHD: handling fault
> status
> > reg 2
> > Feb 27 09:31:20 remote-host [   15.745361] dmar: DMAR:[DMA Read]
> Request
> > device [04:00.0] fault addr 0 #012[   15.745361] DMAR:[fault reason 06]
> PTE
> > Read access is not set
> >
> 
> [ .. ]
> 
> Here is another crash with debugging enabled:
> 

[ .. ] 

https://bbs.archlinux.org/viewtopic.php?id=176398
https://forums.opensuse.org/showthread.php/497436-DMAR-errors-with-VT-d-enab
led

I disabled Virtualization in the kernel and this works around the problem.

Justin.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Generic page fault (Was: libsigsegv ....)

[Benjamin Herrenschmidt]

So for error handling, I'm trying to simply return the VM_FAULT_* flags
from generic_page_fault see where that takes us. That's a way to avoid
passing an arch specific struct around. It also allows my hack to
account major faults with the hypervisor to be done outside the generic
code completely (no hook).

We will process generically some of the flags first such as the repeat
logic or major/minor accounting of course.

For that to work, I'm adding a VM_FAULT_ACCESS (that gets OR'ed with
VM_FAULT_SIGSEGV) to differentiate SEGV_MAPERR and SEGV_ACCERR. So far
so good.

However, I noticed a small discrepancy on x86 in the handling of fatal
signals:

I see two path that can be hit on a fatal signal. The "obvious"
one is the one in access_error() which calls no_context() with a 0
signal argument, the other path is in the retry handling, which will in
this case call no_context() with SIGBUS/BUS_ADRERR. 

Now, the only place in there that seems to care about the signal that
gets passed in is the sig_on_uaccess_error case. On one case (0 sig),
that test will be skipped, on the other case (SIGBUS), that test will be
done and might result in a sigbus being generated, which might override
the original deadly signal (or am I missing something ?)

Now I don't completely understand how the x86 vsyscall stuff works so I
don't know precisely in what circumstances that test matters, I'll need
you help there.

Cheers,
Ben.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 2/2] Input: bcm-keypad: Add Broadcom keypad controller

[Dmitry Torokhov]

On Sat, Feb 28, 2015 at 02:10:22PM -0800, Dmitry Torokhov wrote:
> Hi Scott,
> 
> On Sat, Feb 28, 2015 at 08:35:57AM -0800, Scott Branden wrote:
> > +   /* Enable clock */
> > +
> > +   kp->clk = devm_clk_get(>dev, "peri_clk");
> > +   if (IS_ERR(kp->clk)) {
> > +   dev_info(>dev,
> > +   "No clock specified. Assuming it's enabled\n");
> 
> I was doing the final pass before applying and I think that this is not
> quite correct, as it does not handle -EPROBE_DEFER properly which is
> quite common. I think we should do something like this:
> 
>   error = PTR_ERR(kp->clk);
>   if (error != -ENOENT) {
>   if (error != -EPROBE_DEFER)
>   dev_err(.. "Failed to get clock" ...);
>   return error;
>   }
>   dev_dbg(... "No clock specified" ...);
> 
> No need to resubmit if you are OK with this, I can make the change
> locally.

Hmm, also bcm_kp_start() and bcm_kp_stop() should check if kp->clk is
valid before trying to enable/disable it.

> 
> > +   }
> > +   else {
> 
> Checkpach should have warned you that it should have been "} else {";
> I'll fix it up locally along with few other cosmetic changes and
> dropping a few extra headers.
> 
> Thanks.
> 
> -- 
> Dmitry

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 2/2] Input: bcm-keypad: Add Broadcom keypad controller

[Dmitry Torokhov]

Hi Scott,

On Sat, Feb 28, 2015 at 08:35:57AM -0800, Scott Branden wrote:
> + /* Enable clock */
> +
> + kp->clk = devm_clk_get(>dev, "peri_clk");
> + if (IS_ERR(kp->clk)) {
> + dev_info(>dev,
> + "No clock specified. Assuming it's enabled\n");

I was doing the final pass before applying and I think that this is not
quite correct, as it does not handle -EPROBE_DEFER properly which is
quite common. I think we should do something like this:

error = PTR_ERR(kp->clk);
if (error != -ENOENT) {
if (error != -EPROBE_DEFER)
dev_err(.. "Failed to get clock" ...);
return error;
}
dev_dbg(... "No clock specified" ...);

No need to resubmit if you are OK with this, I can make the change
locally.

> + }
> + else {

Checkpach should have warned you that it should have been "} else {";
I'll fix it up locally along with few other cosmetic changes and
dropping a few extra headers.

Thanks.

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Intel-gfx] [Regression] BUG: unable to handle kernel NULL pointer dereference

[Andrey Skvortsov]

On 28 Feb, Chris Wilson wrote:
> On Sat, Feb 28, 2015 at 03:20:37PM +0300, Andrey Skvortsov wrote:
> > Unfortunately this is not the last bug, that breaks i915/drm working
> > on my laptop. Sometimes system successfully loads with couple warnings 
> > mentioned in
> > previous mail:
> > 
> > [   26.922953] WARNING: CPU: 1 PID: 767 at 
> > drivers/gpu/drm/i915/i915_gem.c:4525 i915_gem_free_object+0x13f/0x288 
> > [i915]()
> > [   26.922954] WARN_ON(obj->frontbuffer_bits)
> 
> That's inocuous, but for the serious hang, you may want to try
> video=SVIDEO-1:d on the kernel commandline to workaround the hang. (Check
> /sys/class/drm/card/ for the actual name of the connector for TV). I
> think Ville mentioned he was looking/looked at the atomic-vs-load_detect
> changes that is at the heart of the issue here. (Admittedly he did say
> it was worthy of a drink or two.)
> -Chris

Thank you for the help. I've tried to add to the kernel command line
'video=card0-SVIDEO-1:d video=card0-VGA-1:d'. But despite of that
kernel crashes with 'BUG: unable to handle kernel NULL pointer
dereference at' occasionally.

-- 
Best regards,
Andrey Skvortsov





signature.asc
Description: Digital signature

Re: [PATCH net-next] hyperv: Implement netvsc_get_channels() ethool op

[David Miller]

From: Andrew Schwartzmeyer 
Date: Thu, 26 Feb 2015 16:27:14 -0800

> This adds support for reporting the actual and maximum combined channels
> count of the hv_netvsc driver via 'ethtool --show-channels'.
> 
> This required adding 'max_chn' to 'struct netvsc_device', and assigning
> it 'rsscap.num_recv_que' in 'rndis_filter_device_add'. Now we can access
> the combined maximum channel count via 'struct netvsc_device' in the
> ethtool callback.
> 
> Signed-off-by: Andrew Schwartzmeyer 

Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Generic page fault (Was: libsigsegv ....)

[Linus Torvalds]

On Sat, Feb 28, 2015 at 1:14 PM, Benjamin Herrenschmidt
 wrote:
>
> BTW. I fail to see how x86 checks PF_INSTR vs. VM_NOEXEC ... or it doesn't ?

It doesn't. x86 traditionally doesn't have an execute bit, so
traditionally "read == exec".

So PF_INSTR really wasn't historically very useful, in that it would
only show if the *first* access to a page was an instruction fetch -
if you did a regular read to brign the page in, then subsequent
instruction fetches would just work.

Then NX came along, and what happens now is

 - we handle write faults separately (see the first part of access_error()

 - so now we know it was a read or an instruction fetch

 - if PF_PROT is set, that means that the present bit was set in the
page tables, so it must have been an exec access to a NX page

 - otherwise, we just say "PROTNONE means no access, otherwise
populate the page tables"

.. and if it turns out that it was a PF_INSTR to a NX page, we'll end
up taking the page fault *again* after it's been populated, and now
since the page table was populated, the access_error() will catch it
with the PF_PROT case.

Or something like that. I might have screwed up some detail, but it
should all work.

 Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ipc/sem.c: Update/correct memory barriers.

[Peter Zijlstra]

On Sat, Feb 28, 2015 at 09:36:15PM +0100, Manfred Spraul wrote:
> +/*
> + * Place this after a control barrier (such as e.g. a spin_unlock_wait())
> + * to ensure that reads cannot be moved ahead of the control_barrier.
> + * Writes do not need a barrier, they are not speculated and thus cannot
> + * pass the control barrier.
> + */
> +#ifndef smp_mb__after_control_barrier
> +#define smp_mb__after_control_barrier()  smp_rmb()
> +#endif

Sorry to go bike shedding again; but should we call this:

smp_acquire__after_control_barrier() ?

The thing is; its not a full MB because:

 - stores might actually creep into it; while the control dependency
   guarantees stores will not creep out, nothing is stopping them from
   getting in;

 - its not transitive, and our MB is defined to be so.

Oleg, Paul?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC][PATCH 5/9] rbtree: Make lockless searches non-fatal

[Peter Zijlstra]

Change the insert and erase code such that lockless searches are
non-fatal.

In and of itself an rbtree cannot be correctly searched while
in-modification, we can however provide weaker guarantees that will
allow the rbtree to be used in conjunction with other techniques, such
as latches; see 9b0fd802e8c0 ("seqcount: Add raw_write_seqcount_latch()").

For this to work we need the following guarantees from the rbtree
code:

 1) a lockless reader must not see partial stores, this would allow it
to observe nodes that are invalid memory.

 2) there must not be (temporary) loops in the tree structure in the
modifier's program order, this would cause a lookup which
interrupts the modifier to get stuck indefinitely.

For 1) we must use WRITE_ONCE() for all updates to the tree structure;
in particular this patch only does rb_{left,right} as those are the
only element required for simple searches.

It generates slightly worse code, probably because gcc stinks at
volatile. But in pointer chasing heavy code a few instructions more
should not matter.

For 2) I have carefully audited the code and drawn every intermediate
link state and not found a loop.

Cc: Oleg Nesterov 
Cc: Michel Lespinasse 
Cc: Andrea Arcangeli 
Cc: David Woodhouse 
Cc: Rik van Riel 
Cc: Mathieu Desnoyers 
Cc: "Paul E. McKenney" 
Signed-off-by: Peter Zijlstra (Intel) 
---
 include/linux/rbtree.h   |   10 +
 include/linux/rbtree_augmented.h |   21 +++
 lib/rbtree.c |   71 ++-
 3 files changed, 73 insertions(+), 29 deletions(-)

--- a/include/linux/rbtree.h
+++ b/include/linux/rbtree.h
@@ -31,6 +31,7 @@
 
 #include 
 #include 
+#include 
 
 struct rb_node {
unsigned long  __rb_parent_color;
@@ -85,6 +86,15 @@ static inline void rb_link_node(struct r
*rb_link = node;
 }
 
+static inline void rb_link_node_rcu(struct rb_node * node, struct rb_node * 
parent,
+   struct rb_node ** rb_link)
+{
+   node->__rb_parent_color = (unsigned long)parent;
+   node->rb_left = node->rb_right = NULL;
+
+   rcu_assign_pointer(*rb_link, node);
+}
+
 #define rb_entry_safe(ptr, type, member) \
({ typeof(ptr) ptr = (ptr); \
   ptr ? rb_entry(ptr, type, member) : NULL; \
--- a/include/linux/rbtree_augmented.h
+++ b/include/linux/rbtree_augmented.h
@@ -123,11 +123,11 @@ __rb_change_child(struct rb_node *old, s
 {
if (parent) {
if (parent->rb_left == old)
-   parent->rb_left = new;
+   WRITE_ONCE(parent->rb_left, new);
else
-   parent->rb_right = new;
+   WRITE_ONCE(parent->rb_right, new);
} else
-   root->rb_node = new;
+   WRITE_ONCE(root->rb_node, new);
 }
 
 extern void __rb_erase_color(struct rb_node *parent, struct rb_root *root,
@@ -137,7 +137,8 @@ static __always_inline struct rb_node *
 __rb_erase_augmented(struct rb_node *node, struct rb_root *root,
 const struct rb_augment_callbacks *augment)
 {
-   struct rb_node *child = node->rb_right, *tmp = node->rb_left;
+   struct rb_node *child = node->rb_right;
+   struct rb_node *tmp = node->rb_left;
struct rb_node *parent, *rebalance;
unsigned long pc;
 
@@ -167,6 +168,7 @@ __rb_erase_augmented(struct rb_node *nod
tmp = parent;
} else {
struct rb_node *successor = child, *child2;
+
tmp = child->rb_left;
if (!tmp) {
/*
@@ -180,6 +182,7 @@ __rb_erase_augmented(struct rb_node *nod
 */
parent = successor;
child2 = successor->rb_right;
+
augment->copy(node, successor);
} else {
/*
@@ -201,19 +204,23 @@ __rb_erase_augmented(struct rb_node *nod
successor = tmp;
tmp = tmp->rb_left;
} while (tmp);
-   parent->rb_left = child2 = successor->rb_right;
-   successor->rb_right = child;
+   child2 = successor->rb_right;
+   WRITE_ONCE(parent->rb_left, child2);
+   WRITE_ONCE(successor->rb_right, child);
rb_set_parent(child, successor);
+
augment->copy(node, successor);
augment->propagate(parent, successor);
}
 
-   successor->rb_left = tmp = node->rb_left;
+   tmp = node->rb_left;
+   WRITE_ONCE(successor->rb_left, tmp);
rb_set_parent(tmp, successor);
 
pc = node->__rb_parent_color;
tmp = __rb_parent(pc);
__rb_change_child(node, successor, tmp, root);
+

[RFC][PATCH 9/9] module: Use __module_address() for module_address_lookup()

[Peter Zijlstra]

Use the generic __module_address() addr to struct module lookup
instead of open coding it once more.

Cc: Rusty Russell 
Signed-off-by: Peter Zijlstra (Intel) 
---
 kernel/module.c |   17 +++--
 1 file changed, 7 insertions(+), 10 deletions(-)

--- a/kernel/module.c
+++ b/kernel/module.c
@@ -3515,19 +3515,15 @@ const char *module_address_lookup(unsign
char **modname,
char *namebuf)
 {
-   struct module *mod;
const char *ret = NULL;
+   struct module *mod;
 
preempt_disable();
-   list_for_each_entry_rcu(mod, , list) {
-   if (mod->state == MODULE_STATE_UNFORMED)
-   continue;
-   if (within_module(addr, mod)) {
-   if (modname)
-   *modname = mod->name;
-   ret = get_ksymbol(mod, addr, size, offset);
-   break;
-   }
+   mod = __module_address(addr);
+   if (mod) {
+   if (modname)
+   *modname = mod->name;
+   ret = get_ksymbol(mod, addr, size, offset);
}
/* Make a copy in here where it's safe */
if (ret) {
@@ -3535,6 +3531,7 @@ const char *module_address_lookup(unsign
ret = namebuf;
}
preempt_enable();
+
return ret;
 }
 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC][PATCH 7/9] rbtree: Implement generic latch_tree

[Peter Zijlstra]

Implement a latched RB-tree in order to get RCU style lookups.

Cc: Michel Lespinasse 
Cc: Andrea Arcangeli 
Cc: David Woodhouse 
Cc: Rik van Riel 
Cc: Mathieu Desnoyers 
Cc: "Paul E. McKenney" 
Cc: Oleg Nesterov 
Signed-off-by: Peter Zijlstra (Intel) 
---
 include/linux/rbtree_latch.h |  140 +++
 1 file changed, 140 insertions(+)

--- /dev/null
+++ b/include/linux/rbtree_latch.h
@@ -0,0 +1,140 @@
+/*
+ * Latched RB-trees
+ *
+ * Copyright (C) 2015 Intel Corp., Peter Zijlstra 
+ */
+
+#ifndef RB_TREE_LATCH_H
+#define RB_TREE_LATCH_H
+
+#include 
+#include 
+
+/*
+ * Since RB-trees have non atomic modifications they're not suited for
+ * RCU/lockless queries.
+ *
+ * Employ the latch technique -- see @raw_write_seqcount_latch -- to implement
+ * a latched RB-tree which does allow this by virtue of always having (at
+ * least) one stable copy of the tree.
+ *
+ * However, while we have the guarantee that there is at all times one stable
+ * copy, this does not guarantee an iteration will not observe modifications.
+ * What might have been a stable copy at the start of the iteration, need not
+ * remain so for the duration of the iteration.
+ *
+ * Therefore, this does require a lockless RB-tree iteration to be non-fatal in
+ * all circumstances; see the comment in lib/rbtree.c.
+ */
+
+struct latch_tree_node {
+   void*priv;
+   struct rb_node  node;
+};
+
+struct latch_tree_nodes {
+   struct latch_tree_node node[2];
+};
+
+struct latch_tree_root {
+   seqcount_t  seq;
+   struct rb_root  tree[2];
+};
+
+struct latch_tree_ops {
+   bool (*less)(struct latch_tree_node *a, struct latch_tree_node *b);
+   int  (*comp)(void *key, struct latch_tree_node *b);
+};
+
+static __always_inline void
+__lt_insert(struct latch_tree_node *ltn, struct rb_root *root,
+   bool (*less)(struct latch_tree_node *a, struct latch_tree_node *b))
+{
+   struct rb_node **link = >rb_node;
+   struct rb_node *parent = NULL;
+   struct latch_tree_node *ltp;
+
+   while (*link) {
+   parent = *link;
+   ltp = container_of(parent, struct latch_tree_node, node);
+
+   if (less(ltn, ltp))
+   link = >rb_left;
+   else
+   link = >rb_right;
+   }
+
+   rb_link_node_rcu(>node, parent, link);
+   rb_insert_color(>node, root);
+}
+
+static __always_inline void
+__lt_erase(struct latch_tree_node *ltn, struct rb_root *root)
+{
+   rb_erase(>node, root);
+}
+
+static __always_inline struct latch_tree_node *
+__lt_find(void *key, struct rb_root *root,
+ int (*comp)(void *key, struct latch_tree_node *ltn))
+{
+   struct rb_node *n = rcu_dereference_raw(root->rb_node);
+   struct latch_tree_node *ltn;
+   int c;
+
+   while (n) {
+   ltn = container_of(n, struct latch_tree_node, node);
+   c = comp(key, ltn);
+
+   if (c < 0)
+   n = rcu_dereference_raw(n->rb_left);
+   else if (c > 0)
+   n = rcu_dereference_raw(n->rb_right);
+   else
+   return ltn;
+   }
+
+   return NULL;
+}
+
+static __always_inline void
+latch_tree_insert(struct latch_tree_nodes *nodes,
+ struct latch_tree_root *root,
+ void *priv,
+ const struct latch_tree_ops *ops)
+{
+   nodes->node[0].priv = nodes->node[1].priv = priv;
+
+   raw_write_seqcount_latch(>seq);
+   __lt_insert(>node[0], >tree[0], ops->less);
+   raw_write_seqcount_latch(>seq);
+   __lt_insert(>node[1], >tree[1], ops->less);
+}
+
+static __always_inline void
+latch_tree_erase(struct latch_tree_nodes *nodes,
+struct latch_tree_root *root,
+const struct latch_tree_ops *ops)
+{
+   raw_write_seqcount_latch(>seq);
+   __lt_erase(>node[0], >tree[0]);
+   raw_write_seqcount_latch(>seq);
+   __lt_erase(>node[1], >tree[1]);
+}
+
+static __always_inline struct latch_tree_node *
+latch_tree_find(void *key, struct latch_tree_root *root,
+   const struct latch_tree_ops *ops)
+{
+   struct latch_tree_node *node;
+   unsigned int seq;
+
+   do {
+   seq = raw_read_seqcount(>seq);
+   node = __lt_find(key, >tree[seq & 1], ops->comp);
+   } while (read_seqcount_retry(>seq, seq));
+
+   return node;
+}
+
+#endif /* RB_TREE_LATCH_H */


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC][PATCH 0/9] latched RB-trees and __module_address()

[Peter Zijlstra]

This series is aimed at making __module_address() go fast(er).

On the way there it:
 - annotates and sanitizes module locking
 - introduces the latched RB-tree
 - employs it to make __module_address() go fast

I've build and boot tested this on x86_64 with modules and lockdep enabled.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC][PATCH 1/9] klp: Fix obvious RCU fail

[Peter Zijlstra]

While one must hold RCU-sched (aka. preempt_disable) for find_symbol()
one must equally hold it over the use of the object returned.

The moment you release the RCU-sched read lock, the object can be dead
and gone.

Cc: Seth Jennings 
Cc: Josh Poimboeuf 
Cc: Masami Hiramatsu 
Cc: Miroslav Benes 
Cc: Petr Mladek 
Cc: Jiri Kosina 
Cc: "Paul E. McKenney" 
Cc: Rusty Russell 
Signed-off-by: Peter Zijlstra (Intel) 
---
 kernel/livepatch/core.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/kernel/livepatch/core.c
+++ b/kernel/livepatch/core.c
@@ -248,11 +248,12 @@ static int klp_find_external_symbol(stru
/* first, check if it's an exported symbol */
preempt_disable();
sym = find_symbol(name, NULL, NULL, true, true);
-   preempt_enable();
if (sym) {
*addr = sym->value;
+   preempt_enable();
return 0;
}
+   preempt_enable();
 
/* otherwise check if it's in another .o within the patch module */
return klp_find_object_symbol(pmod->name, name, addr);


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC][PATCH 6/9] seqlock: Better document raw_write_seqcount_latch()

[Peter Zijlstra]

Improve the documentation of the latch technique as used in the
current timekeeping code, such that it can be readily employed
elsewhere.

Borrow from the comments in timekeeping and replace those with a
reference to this more generic comment.

Cc: Oleg Nesterov 
Cc: Michel Lespinasse 
Cc: Andrea Arcangeli 
Cc: David Woodhouse 
Cc: Rik van Riel 
Cc: Mathieu Desnoyers 
Cc: "Paul E. McKenney" 
Signed-off-by: Peter Zijlstra (Intel) 
---
 include/linux/seqlock.h   |   74 +-
 kernel/time/timekeeping.c |   27 
 2 files changed, 74 insertions(+), 27 deletions(-)

--- a/include/linux/seqlock.h
+++ b/include/linux/seqlock.h
@@ -233,9 +233,81 @@ static inline void raw_write_seqcount_en
s->sequence++;
 }
 
-/*
+/**
  * raw_write_seqcount_latch - redirect readers to even/odd copy
  * @s: pointer to seqcount_t
+ *
+ * The latch technique is a multiversion concurrency control method that allows
+ * queries during non atomic modifications. If you can guarantee queries never
+ * interrupt the modification -- e.g. the concurrency is strictly between CPUs
+ * -- you most likely do not need this.
+ *
+ * Where the traditional RCU/lockless data structures rely on atomic
+ * modifications to ensure queries observe either the old or the new state the
+ * latch allows the same for non atomic updates. The trade-off is doubling the
+ * cost of storage; we have to maintain two copies of the entire data
+ * structure.
+ *
+ * Very simply put: we first modify one copy and then the other. This ensures
+ * there is always one copy in a stable state, ready to give us an answer.
+ *
+ * The basic form is a data structure like:
+ *
+ * struct latch_struct {
+ * seqcount_t  seq;
+ * struct data_struct  data[2];
+ * };
+ *
+ * Where a modification, which is assumed to be externally serialized, does the
+ * following:
+ *
+ * void latch_modify(struct latch_struct *latch, ...)
+ * {
+ * smp_wmb();  <- Ensure that the last data[1] update is visible
+ * latch->seq++;
+ * smp_wmb();  <- Ensure that the seqcount update is visible
+ *
+ * modify(latch->data[0], ...);
+ *
+ * smp_wmb();  <- Ensure that the data[0] update is visible
+ * latch->seq++;
+ * smp_wmb();  <- Ensure that the seqcount update is visible
+ *
+ * modify(latch->data[1], ...);
+ * }
+ *
+ * The query will have a form like:
+ *
+ * struct entry *latch_query(struct latch_struct *latch, ...)
+ * {
+ * struct entry *entry;
+ * unsigned seq;
+ * int idx;
+ *
+ * do {
+ * seq = latch->seq;
+ * smp_rmb();
+ *
+ * idx = seq & 0x01;
+ * entry = data_query(latch->data[idx], ...);
+ *
+ * smp_rmb();
+ * } while (seq != latch->seq);
+ *
+ * return entry;
+ * }
+ *
+ * So during the modification, queries are first redirected to data[1]. Then we
+ * modify data[0]. When that is complete, we redirect queries back to data[0]
+ * and we can modify data[1].
+ *
+ * NOTE: The non-requirement for atomic modifications does _NOT_ include
+ *   the publishing of new entries in the case where data is a dynamic
+ *   data structure.
+ *
+ *   An iteration might start in data[0] and get suspended long enough
+ *   to miss an entire modification sequence, once it resumes it might
+ *   observe the new entry.
  */
 static inline void raw_write_seqcount_latch(seqcount_t *s)
 {
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -235,32 +235,7 @@ static inline s64 timekeeping_get_ns_raw
  * We want to use this from any context including NMI and tracing /
  * instrumenting the timekeeping code itself.
  *
- * So we handle this differently than the other timekeeping accessor
- * functions which retry when the sequence count has changed. The
- * update side does:
- *
- * smp_wmb();  <- Ensure that the last base[1] update is visible
- * tkf->seq++;
- * smp_wmb();  <- Ensure that the seqcount update is visible
- * update(tkf->base[0], tkr);
- * smp_wmb();  <- Ensure that the base[0] update is visible
- * tkf->seq++;
- * smp_wmb();  <- Ensure that the seqcount update is visible
- * update(tkf->base[1], tkr);
- *
- * The reader side does:
- *
- * do {
- * seq = tkf->seq;
- * smp_rmb();
- * idx = seq & 0x01;
- * now = now(tkf->base[idx]);
- * smp_rmb();
- * } while (seq != tkf->seq)
- *
- * As long as we update base[0] readers are forced off to
- * base[1]. Once base[0] is updated readers are redirected to base[0]
- * and the base[1] update takes place.
+ * Employ the latch technique; see @raw_write_seqcount_latch.
  *
  * So if a NMI hits the update of base[0] then it will use base[1]
  * which is still consistent. In the worst case this can result is a


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  

[RFC][PATCH 8/9] module: Optimize __module_address() using a latched RB-tree

[Peter Zijlstra]

Currently __module_address() is using a linear search through all
modules in order to find the module corresponding to the provided
address. With a lot of modules this can take a lot of time.

One of the users of this is kernel_text_address() which is employed
in many stack unwinders; which in turn are used by perf-callchain and
ftrace (possibly from NMI context).

So by optimizing __module_address() we optimize many stack unwinders
which are used by both perf and tracing in performance sensitive code.

Cc: Mathieu Desnoyers 
Cc: Oleg Nesterov 
Cc: "Paul E. McKenney" 
Cc: Rusty Russell 
Cc: Steven Rostedt 
Signed-off-by: Peter Zijlstra (Intel) 
---
 include/linux/module.h |   22 --
 kernel/module.c|  107 ++---
 2 files changed, 121 insertions(+), 8 deletions(-)

--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -269,8 +270,15 @@ struct module {
/* Startup function. */
int (*init)(void);
 
-   /* If this is non-NULL, vfree after init() returns */
-   void *module_init;
+   /*
+* If this is non-NULL, vfree after init() returns.
+*
+* Cacheline align here, such that:
+*   module_init, module_core, init_size, core_size,
+*   init_text_size, core_text_size and ltn_core.node[0]
+* are on the same cacheline.
+*/
+   void *module_init   cacheline_aligned;
 
/* Here is the actual code + data, vfree'd on unload. */
void *module_core;
@@ -281,6 +289,14 @@ struct module {
/* The size of the executable code in each section.  */
unsigned int init_text_size, core_text_size;
 
+   /*
+* We rely on the order of these two entries; not only do we want
+* core.node[0] to be in the same cacheline as the above entries,
+* we also assume ltn_init has a higher address than ltn_core.
+*/
+   struct latch_tree_nodes ltn_core;
+   struct latch_tree_nodes ltn_init;
+
/* Size of RO sections of the module (text+rodata) */
unsigned int init_ro_size, core_ro_size;
 
@@ -361,7 +377,7 @@ struct module {
ctor_fn_t *ctors;
unsigned int num_ctors;
 #endif
-};
+} cacheline_aligned;
 #ifndef MODULE_ARCH_INIT
 #define MODULE_ARCH_INIT {}
 #endif
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -102,6 +102,99 @@
 DEFINE_MUTEX(module_mutex);
 EXPORT_SYMBOL_GPL(module_mutex);
 static LIST_HEAD(modules);
+
+/*
+ * Use a latched RB-tree for __module_address(); this allows us to use
+ * RCU-sched lookups of the address from any context.
+ *
+ * Because modules have two address ranges: init and core, we need two
+ * latch_tree_nodes entries. We use the order they appear in struct module to
+ * determine if we need to use the init or core values for the comparisons.
+ */
+
+static __always_inline unsigned long __mod_tree_val(struct latch_tree_node *n)
+{
+   struct module *mod = n->priv;
+
+   if (n >= mod->ltn_init.node)
+   return (unsigned long)mod->module_init;
+   else
+   return (unsigned long)mod->module_core;
+}
+
+static __always_inline unsigned long __mod_tree_size(struct latch_tree_node *n)
+{
+   struct module *mod = n->priv;
+
+   if (n >= mod->ltn_init.node)
+   return (unsigned long)mod->init_size;
+   else
+   return (unsigned long)mod->core_size;
+}
+
+static __always_inline bool
+mod_tree_less(struct latch_tree_node *a, struct latch_tree_node *b)
+{
+   return __mod_tree_val(a) < __mod_tree_val(b);
+}
+
+static __always_inline int
+mod_tree_comp(void *key, struct latch_tree_node *n)
+{
+   unsigned long val = (unsigned long)key;
+   unsigned long start, end;
+
+   end = start = __mod_tree_val(n);
+   end += __mod_tree_size(n);
+
+   if (val < start)
+   return -1;
+
+   if (val >= end)
+   return 1;
+
+   return 0;
+}
+
+static const struct latch_tree_ops mod_tree_ops = {
+   .less = mod_tree_less,
+   .comp = mod_tree_comp,
+};
+
+static struct latch_tree_root mod_tree __cacheline_aligned;
+
+/*
+ * These modifications: insert, remove_init and remove; are serialized by the
+ * module_mutex.
+ */
+static void mod_tree_insert(struct module *mod)
+{
+   latch_tree_insert(>ltn_core, _tree, mod, _tree_ops);
+   if (mod->init_size)
+   latch_tree_insert(>ltn_init, _tree, mod, 
_tree_ops);
+}
+
+static void mod_tree_remove_init(struct module *mod)
+{
+   if (mod->init_size)
+   latch_tree_erase(>ltn_init, _tree, _tree_ops);
+}
+
+static void mod_tree_remove(struct module *mod)
+{
+   latch_tree_erase(>ltn_core, _tree, _tree_ops);
+   mod_tree_remove_init(mod);
+}
+
+static struct module *mod_tree_find(unsigned long addr)
+{
+   struct latch_tree_node *ltn;
+
+   ltn = latch_tree_find((void *)addr, 

[RFC][PATCH 4/9] module, jump_label: Fix module locking

[Peter Zijlstra]

As per the module core lockdep annotations:

[   18.034047] ---[ end trace 9294429076a9c673 ]---
[   18.047760] Hardware name: Intel Corporation S2600GZ/S2600GZ, BIOS 
SE5C600.86B.02.02.0002.122320131210 12/23/2013
[   18.059228]  817d8676 880036683c38 8157e98b 
0001
[   18.067541]   880036683c78 8105fbc7 
880036683c68
[   18.075851]  a0046b08  a0046d00 
a0046cc8
[   18.084173] Call Trace:
[   18.086906]  [] dump_stack+0x4f/0x7b
[   18.092649]  [] warn_slowpath_common+0x97/0xe0
[   18.099361]  [] warn_slowpath_null+0x1a/0x20
[   18.105880]  [] __module_address+0x1d2/0x1e0
[   18.112400]  [] jump_label_module_notify+0x143/0x1e0
[   18.119710]  [] notifier_call_chain+0x4f/0x70
[   18.126326]  [] __blocking_notifier_call_chain+0x5e/0x90
[   18.134009]  [] blocking_notifier_call_chain+0x16/0x20
[   18.141490]  [] load_module+0x1b50/0x2660
[   18.147720]  [] SyS_init_module+0xce/0x100
[   18.154045]  [] system_call_fastpath+0x12/0x17
[   18.160748] ---[ end trace 9294429076a9c674 ]---

Jump labels is not doing it right; fix this.

Cc: Rusty Russell 
Cc: Jason Baron 
Signed-off-by: Peter Zijlstra (Intel) 
---
 kernel/jump_label.c |   21 +
 1 file changed, 17 insertions(+), 4 deletions(-)

--- a/kernel/jump_label.c
+++ b/kernel/jump_label.c
@@ -280,6 +280,17 @@ void jump_label_apply_nops(struct module
}
 }
 
+static inline bool address_in_module(unsigned long addr, struct module *mod)
+{
+   bool ret;
+
+   preempt_disable();
+   ret = __module_address(addr) == mod;
+   preempt_enable();
+
+   return ret;
+}
+
 static int jump_label_add_module(struct module *mod)
 {
struct jump_entry *iter_start = mod->jump_entries;
@@ -302,7 +313,7 @@ static int jump_label_add_module(struct
continue;
 
key = iterk;
-   if (__module_address(iter->key) == mod) {
+   if (address_in_module(iter->key, mod)) {
/*
 * Set key->entries to iter, but preserve 
JUMP_LABEL_TRUE_BRANCH.
 */
@@ -339,7 +350,7 @@ static void jump_label_del_module(struct
 
key = (struct static_key *)(unsigned long)iter->key;
 
-   if (__module_address(iter->key) == mod)
+   if (address_in_module(iter->key, mod))
continue;
 
prev = >next;
@@ -443,14 +454,16 @@ static void jump_label_update(struct sta
 {
struct jump_entry *stop = __stop___jump_table;
struct jump_entry *entry = jump_label_get_entries(key);
-
 #ifdef CONFIG_MODULES
-   struct module *mod = __module_address((unsigned long)key);
+   struct module *mod;
 
__jump_label_mod_update(key, enable);
 
+   preempt_disable();
+   mod = __module_address((unsigned long)key);
if (mod)
stop = mod->jump_entries + mod->num_jump_entries;
+   preempt_enable();
 #endif
/* if there are no users, entry can be NULL */
if (entry)


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC][PATCH 3/9] module: Annotate module version magic

[Peter Zijlstra]

Due to the new lockdep checks we go:

[9.759380] [ cut here ]
[9.759389] WARNING: CPU: 31 PID: 597 at ../kernel/module.c:216 
each_symbol_section+0x121/0x130()
[9.759391] Modules linked in:
[9.759393] CPU: 31 PID: 597 Comm: modprobe Not tainted 4.0.0-rc1+ #65
[9.759393] Hardware name: Intel Corporation S2600GZ/S2600GZ, BIOS 
SE5C600.86B.02.02.0002.122320131210 12/23/2013
[9.759396]  817d8676 880424567ca8 8157e98b 
0001
[9.759398]   880424567ce8 8105fbc7 
880424567cd8
[9.759400]   810ec160 880424567d40 

[9.759400] Call Trace:
[9.759407]  [] dump_stack+0x4f/0x7b
[9.759410]  [] warn_slowpath_common+0x97/0xe0
[9.759412]  [] ? section_objs+0x60/0x60
[9.759414]  [] warn_slowpath_null+0x1a/0x20
[9.759415]  [] each_symbol_section+0x121/0x130
[9.759417]  [] find_symbol+0x31/0x70
[9.759420]  [] load_module+0x20f/0x2660
[9.759422]  [] ? __do_page_fault+0x190/0x4e0
[9.759426]  [] ? retint_restore_args+0x13/0x13
[9.759427]  [] ? retint_restore_args+0x13/0x13
[9.759433]  [] ? trace_hardirqs_on_caller+0x11d/0x1e0
[9.759437]  [] ? trace_hardirqs_on_thunk+0x3a/0x3f
[9.759439]  [] ? retint_restore_args+0x13/0x13
[9.759441]  [] SyS_init_module+0xce/0x100
[9.759443]  [] system_call_fastpath+0x12/0x17
[9.759445] ---[ end trace 9294429076a9c644 ]---

As per the comment this site should be fine, but lets wrap it in
preempt_disable() anyhow to placate lockdep.

Cc: Rusty Russell 
Signed-off-by: Peter Zijlstra (Intel) 
---
 kernel/module.c |   12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

--- a/kernel/module.c
+++ b/kernel/module.c
@@ -1192,11 +1192,17 @@ static inline int check_modstruct_versio
 {
const unsigned long *crc;
 
-   /* Since this should be found in kernel (which can't be removed),
-* no locking is necessary. */
+   /*
+* Since this should be found in kernel (which can't be removed),
+* no locking is necessary.
+*/
+   preempt_disable();
if (!find_symbol(VMLINUX_SYMBOL_STR(module_layout), NULL,
-, true, false))
+, true, false)) {
+   preempt_enable();
BUG();
+   }
+   preempt_enable();
return check_version(sechdrs, versindex,
 VMLINUX_SYMBOL_STR(module_layout), mod, crc,
 NULL);


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC][PATCH 2/9] module: Sanitize RCU usage and locking

[Peter Zijlstra]

Currently the RCU usage in module is an inconsistent mess of RCU and
RCU-sched, this is broken for CONFIG_PREEMPT where synchronize_rcu()
does not imply synchronize_sched().

Convert everything over to RCU-sched.

Furthermore add lockdep asserts to all sites, because its not at all
clear to me the required locking is observed, esp. on exported
functions.

Cc: "Paul E. McKenney" 
Cc: Rusty Russell 
Signed-off-by: Peter Zijlstra (Intel) 
---
 include/linux/module.h |   12 ++--
 kernel/module.c|   42 ++
 lib/bug.c  |7 +--
 3 files changed, 49 insertions(+), 12 deletions(-)

--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -415,14 +415,22 @@ struct symsearch {
bool unused;
 };
 
-/* Search for an exported symbol by name. */
+/*
+ * Search for an exported symbol by name.
+ *
+ * Must be called with module_mutex held or preemption disabled.
+ */
 const struct kernel_symbol *find_symbol(const char *name,
struct module **owner,
const unsigned long **crc,
bool gplok,
bool warn);
 
-/* Walk the exported symbol table */
+/*
+ * Walk the exported symbol table
+ *
+ * Must be called with module_mutex held or preemption disabled.
+ */
 bool each_symbol_section(bool (*fn)(const struct symsearch *arr,
struct module *owner,
void *data), void *data);
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -106,6 +106,24 @@ static LIST_HEAD(modules);
 struct list_head *kdb_modules =  /* kdb needs the list of modules */
 #endif /* CONFIG_KGDB_KDB */
 
+static inline void module_assert_mutex(void)
+{
+   lockdep_assert_held(_mutex);
+}
+
+static inline void module_assert_mutex_or_preempt(void)
+{
+#ifdef CONFIG_LOCKDEP
+   int rcu_held = rcu_read_lock_sched_held();
+   int mutex_held = 1;
+
+   if (debug_locks)
+   mutex_held = lockdep_is_held(_mutex);
+
+   WARN_ON(!rcu_held && !mutex_held);
+#endif
+}
+
 #ifdef CONFIG_MODULE_SIG
 #ifdef CONFIG_MODULE_SIG_FORCE
 static bool sig_enforce = true;
@@ -319,6 +337,8 @@ bool each_symbol_section(bool (*fn)(cons
 #endif
};
 
+   module_assert_mutex_or_preempt();
+
if (each_symbol_in_section(arr, ARRAY_SIZE(arr), NULL, fn, data))
return true;
 
@@ -458,6 +478,8 @@ static struct module *find_module_all(co
 {
struct module *mod;
 
+   module_assert_mutex();
+
list_for_each_entry(mod, , list) {
if (!even_unformed && mod->state == MODULE_STATE_UNFORMED)
continue;
@@ -1856,8 +1878,8 @@ static void free_module(struct module *m
list_del_rcu(>list);
/* Remove this module from bug list, this uses list_del_rcu */
module_bug_cleanup(mod);
-   /* Wait for RCU synchronizing before releasing mod->list and buglist. */
-   synchronize_rcu();
+   /* Wait for RCU-sched synchronizing before releasing mod->list and 
buglist. */
+   synchronize_sched();
mutex_unlock(_mutex);
 
/* This may be NULL, but that's OK */
@@ -3106,11 +3128,11 @@ static noinline int do_init_module(struc
mod->init_text_size = 0;
/*
 * We want to free module_init, but be aware that kallsyms may be
-* walking this with preempt disabled.  In all the failure paths,
-* we call synchronize_rcu/synchronize_sched, but we don't want
-* to slow down the success path, so use actual RCU here.
+* walking this with preempt disabled.  In all the failure paths, we
+* call synchronize_sched, but we don't want to slow down the success
+* path, so use actual RCU here.
 */
-   call_rcu(>rcu, do_free_init);
+   call_rcu_sched(>rcu, do_free_init);
mutex_unlock(_mutex);
wake_up_all(_wq);
 
@@ -3368,8 +3390,8 @@ static int load_module(struct load_info
/* Unlink carefully: kallsyms could be walking list. */
list_del_rcu(>list);
wake_up_all(_wq);
-   /* Wait for RCU synchronizing before releasing mod->list. */
-   synchronize_rcu();
+   /* Wait for RCU-sched synchronizing before releasing mod->list. */
+   synchronize_sched();
mutex_unlock(_mutex);
  free_module:
/* Free lock-classes; relies on the preceding sync_rcu() */
@@ -3636,6 +3658,8 @@ int module_kallsyms_on_each_symbol(int (
unsigned int i;
int ret;
 
+   module_assert_mutex();
+
list_for_each_entry(mod, , list) {
if (mod->state == MODULE_STATE_UNFORMED)
continue;
@@ -3810,6 +3834,8 @@ struct module *__module_address(unsigned
if (addr < module_addr_min || addr > module_addr_max)
return NULL;
 
+   module_assert_mutex_or_preempt();
+

Re: [PATCH v3] fs: record task name which froze superblock

[Dave Chinner]

On Sat, Feb 28, 2015 at 05:25:57PM +0300, Alexey Dobriyan wrote:
> Freezing and thawing are separate system calls, task which is supposed
> to thaw filesystem/superblock can disappear due to crash or not thaw
> due to a bug. At least record task name (we can't take task_struct
> reference) to make support engineer's life easier.
> 
> Hopefully 16 bytes per superblock isn't much.
> 
> TASK_COMM_LEN definition (which is userspace ABI, see prctl(PR_SET_NAME)) is
> moved to userspace exported header to not drag sched.h into every fs.h 
> inclusion.
> 
> Signed-off-by: Alexey Dobriyan 

Freeze/thaw can be nested at the block level. That means the
sb->s_writers.freeze_comm can point at the wrong process. i.e.

Task A  Task B
freeze_bdev
  freeze_super
freeze_comm = A
freeze_bdev
.
thaw_bdev
 


At this point, the block device will never be unthawed, but
the debug field is now pointing to the wrong task. i.e. The debug
helper has not recorded the process that is actually causing the
problem, and leads us all off on a wild goose chase down the wrong
path.

IMO, debug code is only useful if it's reliable.

> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -303,9 +303,6 @@ extern char ___assert_task_state[1 - 2*!!(
>  
>  #endif
>  
> -/* Task command name length */
> -#define TASK_COMM_LEN 16
> -
>  #include 
>  
>  /*
> --- a/include/uapi/linux/sched.h
> +++ b/include/uapi/linux/sched.h
> @@ -49,4 +49,7 @@
>   */
>  #define SCHED_FLAG_RESET_ON_FORK 0x01
>  
> +/* Task command name length */
> +#define TASK_COMM_LEN 16
> +
>  #endif /* _UAPI_LINUX_SCHED_H */

That should be a separate patch, sent to the scheduler maintainers
for review. AFAICT, it isn't part of the user API - it's not defined
in the man page which just says "can be up to 16 bytes".

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] dmaengine: s3c24xx: Fix spelling mistake in dev_err mistake

[Joe Perches]

On Sat, 2015-02-28 at 20:14 +, Colin King wrote:
> Fix spelling mistake, "aquire" -> "acquire"

trivia:

> diff --git a/drivers/dma/s3c24xx-dma.c b/drivers/dma/s3c24xx-dma.c
[]
> @@ -1266,7 +1266,7 @@ static int s3c24xx_dma_probe(struct platform_device 
> *pdev)
>   sprintf(clk_name, "dma.%d", i);
>   phy->clk = devm_clk_get(>dev, clk_name);
>   if (IS_ERR(phy->clk) && sdata->has_clocks) {
> - dev_err(>dev, "unable to aquire clock for 
> channel %d, error %lu",
> + dev_err(>dev, "unable to acquire clock 
> for channel %d, error %lu",

Be nice to add the missing terminating newline '\n' too

dev_err(>dev, "unable to acquire clock 
for channel %d, error %lu\n",

>   i, PTR_ERR(phy->clk));
>   continue;
>   }



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] rtc: add Abracon ABx80x driver

[Joe Perches]

On Sat, 2015-02-28 at 21:52 +0100, Alexandre Belloni wrote:
> > > diff --git a/drivers/rtc/rtc-abx80x.c b/drivers/rtc/rtc-abx80x.c
> > []
> > > +static int ab08xx_get_datetime(struct i2c_client *client, struct 
> > > rtc_time *tm)
[]
> > > + tm->tm_sec = bcd2bin(date[AB08XX_REG_SC] & 0x7F);
> > > + tm->tm_min = bcd2bin(date[AB08XX_REG_MN] & 0x7F);
> > > + tm->tm_hour = bcd2bin(date[AB08XX_REG_HR] & 0x3F);
> > > + tm->tm_wday = date[AB08XX_REG_WD] & 0x7;
> > > + tm->tm_mday = bcd2bin(date[AB08XX_REG_DA] & 0x3F);
> > > + tm->tm_mon = bcd2bin(date[AB08XX_REG_MO] & 0x1F) - 1;
> > > + tm->tm_year = bcd2bin(date[AB08XX_REG_YR]);
> > > + if (tm->tm_year < 70)
> > > + tm->tm_year += 100;
> > > +
> > > + err = rtc_valid_tm(tm);
> > > + if (err < 0)
> > > + dev_err(>dev, "retrieved date/time is not valid.\n");
> > 
> > Is setting the date to a known bad value really the desired thing?
> 
> I'm not sure what you mean here, isn't that what is done in almost all
> the rtc drivers?

Dunno.

> A lot of those are simply using return
> rtc_valid_tm(tm); My guess is that a userspace program must not try to
> use tm when errno is not 0.

My thought was that it might be better to
use a local struct rtc_time r like

r.tm_sec = bcd2bin(date[AB08XX_REG_SC] & 0x7F);
r.tm_min = bcd2bin(date[AB08XX_REG_MN] & 0x7F);
r.tm_hour = bcd2bin(date[AB08XX_REG_HR] & 0x3F);
r.tm_wday = date[AB08XX_REG_WD] & 0x7;
r.tm_mday = bcd2bin(date[AB08XX_REG_DA] & 0x3F);
r.tm_mon = bcd2bin(date[AB08XX_REG_MO] & 0x1F) - 1;
r.tm_year = bcd2bin(date[AB08XX_REG_YR]);
if (r.tm_year < 70)
r.tm_year += 100;

err = rtc_valid_tm();
if (!err)
*tm = r;
else
dev_err(>dev, "retrieved date/time is not valid\n");

return err;


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Generic page fault (Was: libsigsegv ....)

[Benjamin Herrenschmidt]

On Sat, 2015-02-28 at 11:56 -0800, Linus Torvalds wrote:
> On Fri, Feb 27, 2015 at 11:12 PM, Benjamin Herrenschmidt
>  wrote:
> >
> > Let me know what you think of the approach.
> 
> Hmm. I'm not happy with just how many of those arch wrapper/helper
> functions there are, and some of it looks a bit unportable.
> 
> For example, the code "knows" that "err_code" and "address" are the
> only two architecture-specific pieces of information (in addition to
> "struct pt_regs", of course.
> 
> And the fault_is_user/write() stuff seems unnecessary - we have the
> generic FAULT_FLAG_USER/WRITE flags for that, but instead of passing
> in the generic version to the generic function, we pass in the
> arch-specific ones.

I was trying to keep that fault mask local but it might indeed be a
mistake.

The reasoning is that if you look at more archs (the scary one is
sparc), there is potentially more arch "gunk" that needs to be hooked in
after find_vma()...

And a lot of that need arch specific flags coming in. For example on ppc
I check if the instruction is allowed to grow the stack before we take
the mm sem and pass that information for use by the stack growing check.

Here I could just I suppose add some arch specific fault flags but it
might get messy... 

> The same goes for "access_error()". Right now it's an arch-specific
> helper function, but it actually does some generic tests (like
> checking the vma protections), and I think it could/should be entirely
> generic if we just added the necessary FAULT_FLAG_READ/EXEC/NOTPRESENT
> information to the "flags" register. Just looking at the ppc version,
> my gut feel is that "access_error()" is just horribly error-prone
> as-is even from an architecture standpoint.

I was weary of going down the path of having access_error() be an arch
helper because it gets even wilder with other archs and the crazy
platform flags we deal with on ppc. Here. I was thinking of looking at
factoring that in a second step. You are right that most of it seems
to related to execute permission however (at least sparc, mips, powerpc
and arm).

The way to go would be to define a FAULT_FLAG_EXEC which the arch only
sets if it supports enforcing exec at fault time.

BTW. I fail to see how x86 checks PF_INSTR vs. VM_NOEXEC ... or it doesn't ?

> Yes, the "read/exec/notpresent" bits are a bit weird, but old x86
> isn't the only architecture that doesn't necessarily know the
> difference between read and exec.
> 
> So I'd like a bit more encapsulation. The generic code should never
> really need to look at the arch-specific details, although it is true
> that then the error handling cases will likely need it (in order to
> put it on the arch-specific stack info or similar).

Right, we might still have to pass error_code around, I'll have a look.

> So my *gut* feel is that the generic code should be passed
> 
>  - address and the generic flags (ie FAULT_FLAG_USER/WRITE filled in
> by the caller)
> 
>These are the only things the generic code should need to use itself
>
>  - I guess we do need to pass in "struct pt_regs", because things like
> generic tracing actually want it.

And error handling but it could be in the latter...

>  - an opaque "arch specific fault information structure pointer". Not
> used for anything but passing back to the error functions (ie very
> much *not* for helper functions for the normal case, like the current
> "access_error()" - if it's actually needed for those kinds of things,
> then I'm wrong about the model)

Well, it might be needed for stack growth check. It's also somewhat
means we have yet *another* fault information structure which is a bit
sad but I don't see a good way to fold them into one.

For errors I was thinking instead of returning error info from the
generic code and leaving the generation of oops/signal to the caller,
which means less arch gunk to carry around.

>This would (for x86) contain "error_code", but I have the feeling
> that other architectures might need/want more than one word of
> information.
> 
> But I don't know. Maybe I'm wrong. I don't hate the patch as-is, I
> just have this feeling that it coudl be more "generic", and less
> "random small arch helpers".

I don't like it that much either, it's a first draft to see what the
waters are like.

I'll play around more and see what It comes to.

Cheers,
Ben.

> 
>   Linus
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Intel-gfx] [Regression] WARNING: drivers/gpu/drm/i915/i915_gem.c:4525 i915_gem_free_object

[Chris Wilson]

On Sat, Feb 28, 2015 at 03:20:37PM +0300, Andrey Skvortsov wrote:
> Unfortunately this is not the last bug, that breaks i915/drm working
> on my laptop. Sometimes system successfully loads with couple warnings 
> mentioned in
> previous mail:
> 
> [   26.922953] WARNING: CPU: 1 PID: 767 at 
> drivers/gpu/drm/i915/i915_gem.c:4525 i915_gem_free_object+0x13f/0x288 [i915]()
> [   26.922954] WARN_ON(obj->frontbuffer_bits)

That's inocuous, but for the serious hang, you may want to try
video=SVIDEO-1:d on the kernel commandline to workaround the hang. (Check
/sys/class/drm/card/ for the actual name of the connector for TV). I
think Ville mentioned he was looking/looked at the atomic-vs-load_detect
changes that is at the heart of the issue here. (Admittedly he did say
it was worthy of a drink or two.)
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] staging: iio: hmc5843: Set iio name property in sysfs

[Marek Belisko]

Without this change file name for hmc5843 is empty in
/sys/bus/iio/devices/iio\:device*/name

With this change name is reported correctly:
cat /sys/bus/iio/devices/iio\:device*/name
hmc5843

Signed-off-by: Marek Belisko 
---
 drivers/staging/iio/magnetometer/hmc5843_core.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/iio/magnetometer/hmc5843_core.c 
b/drivers/staging/iio/magnetometer/hmc5843_core.c
index fd171d8..90cc18b 100644
--- a/drivers/staging/iio/magnetometer/hmc5843_core.c
+++ b/drivers/staging/iio/magnetometer/hmc5843_core.c
@@ -592,6 +592,7 @@ int hmc5843_common_probe(struct device *dev, struct regmap 
*regmap,
mutex_init(>lock);
 
indio_dev->dev.parent = dev;
+   indio_dev->name = dev->driver->name;
indio_dev->info = _info;
indio_dev->modes = INDIO_DIRECT_MODE;
indio_dev->channels = data->variant->channels;
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] rtc: add Abracon ABx80x driver

[Alexandre Belloni]

On 28/02/2015 at 11:32:15 -0800, Joe Perches wrote :
> On Sat, 2015-02-28 at 20:14 +0100, Alexandre Belloni wrote:
> > Add support for the i2c RTC from Abracon.
> 
> Perhaps you can run this through
> $ ./scripts/checkpatch.pl --strict --fix-inplace
> 

Right, I'll fix those

> Is there going to be a MAINTAINERS entry for this driver?
> 

If necessary, I can maintain it however, I'm not sure I'll have access
to the hardware indefinitely.

> > diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
> []
> > @@ -22,6 +22,7 @@ rtc-core-$(CONFIG_RTC_INTF_SYSFS) += rtc-sysfs.o
> >  
> >  obj-$(CONFIG_RTC_DRV_88PM860X)  += rtc-88pm860x.o
> >  obj-$(CONFIG_RTC_DRV_88PM80X)  += rtc-88pm80x.o
> > +obj-$(CONFIG_RTC_DRV_ABX80X)   += rtc-abx80x.o
> 
> alphabetic order?
> 

I renamed the driver from rtc-ab080x and forgot to move it. I will do.
I'll also rename the functions in the driver.

> >  obj-$(CONFIG_RTC_DRV_AB3100)   += rtc-ab3100.o
> >  obj-$(CONFIG_RTC_DRV_AB8500)   += rtc-ab8500.o
> >  obj-$(CONFIG_RTC_DRV_ABB5ZES3) += rtc-ab-b5ze-s3.o
> 
> []
> 
> > diff --git a/drivers/rtc/rtc-abx80x.c b/drivers/rtc/rtc-abx80x.c
> []
> > +static int ab08xx_get_datetime(struct i2c_client *client, struct rtc_time 
> > *tm)
> > +{
> > +   unsigned char date[8];
> > +   int err;
> > +
> > +   /* Now read time and date */
> > +   err = i2c_smbus_read_i2c_block_data(client, AB08XX_REG_HTH,
> > +   8, date);
> > +   if (err < 0) {
> > +   dev_err(>dev, "Unable to read date\n");
> > +   return -EIO;
> > +   }
> > +
> > +   tm->tm_sec = bcd2bin(date[AB08XX_REG_SC] & 0x7F);
> > +   tm->tm_min = bcd2bin(date[AB08XX_REG_MN] & 0x7F);
> > +   tm->tm_hour = bcd2bin(date[AB08XX_REG_HR] & 0x3F);
> > +   tm->tm_wday = date[AB08XX_REG_WD] & 0x7;
> > +   tm->tm_mday = bcd2bin(date[AB08XX_REG_DA] & 0x3F);
> > +   tm->tm_mon = bcd2bin(date[AB08XX_REG_MO] & 0x1F) - 1;
> > +   tm->tm_year = bcd2bin(date[AB08XX_REG_YR]);
> > +   if (tm->tm_year < 70)
> > +   tm->tm_year += 100;
> > +
> > +   err = rtc_valid_tm(tm);
> > +   if (err < 0)
> > +   dev_err(>dev, "retrieved date/time is not valid.\n");
> 
> Is setting the date to a known bad value really the desired thing?

I'm not sure what you mean here, isn't that what is done in almost all
the rtc drivers? A lot of those are simply using return
rtc_valid_tm(tm); My guess is that a userspace program must not try to
use tm when errno is not 0.

> 
> > +static int ab08xx_probe(struct i2c_client *client,
> > +   const struct i2c_device_id *id)
> > +{
> > +   struct rtc_device *rtc;
> > +   int data, err, part0, part1;
> > +
> > +   if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C))
> > +   return -ENODEV;
> > +
> > +
> > +   part0 = i2c_smbus_read_byte_data(client, AB08XX_REG_PART0);
> > +   part1 = i2c_smbus_read_byte_data(client, AB08XX_REG_PART1);
> > +   if ((part0 < 0) || (part1 < 0)) {
> > +   dev_err(>dev, "Unable to read part number\n");
> > +   return -EIO;
> > +   }
> > +   dev_info(>dev, "chip found %2x%2x\n", part0, part1);
> 
>   "%02x%02x" ?
> 

Indeed, I'm not sure how but I believe I saw it zero padded at some
point.


-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH][v2] pinctrl: sirf: fix typo in kernel warning on a bad interrupt

[Colin King]

From: Colin Ian King 

Fix typo, "flaged" -> "flagged"

Signed-off-by: Colin Ian King 
---
 drivers/pinctrl/sirf/pinctrl-sirf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pinctrl/sirf/pinctrl-sirf.c 
b/drivers/pinctrl/sirf/pinctrl-sirf.c
index 2a1f072..abc5c47 100644
--- a/drivers/pinctrl/sirf/pinctrl-sirf.c
+++ b/drivers/pinctrl/sirf/pinctrl-sirf.c
@@ -568,7 +568,7 @@ static void sirfsoc_gpio_handle_irq(unsigned int irq, 
struct irq_desc *desc)
status = readl(sgpio->chip.regs + SIRFSOC_GPIO_INT_STATUS(bank->id));
if (!status) {
printk(KERN_WARNING
-   "%s: gpio id %d status %#x no interrupt is flaged\n",
+   "%s: gpio id %d status %#x no interrupt is flagged\n",
__func__, bank->id, status);
handle_bad_irq(irq, desc);
return;
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/