Re: [PATCH v3] adm8211: fix checkpatch error for trailing statements on next line

2015-05-05 Thread Okash Khawaja
On Mon, May 04, 2015 at 11:44:58PM -0700, Joe Perches wrote:
 On Tue, 2015-05-05 at 07:01 +0100, Okash Khawaja wrote:
  This patch fixes the checkpatch.pl error:
 
 Please fix the space/tab use too.
 
 Your email client seems to have converted all the tabs
 to spaces.
 
 default should use the same indent as the case statements


Joe and Kalle,

I have adjusted the patch. Since indentation of default adds more to the
patch I have resent it under the subject '[PATCH] adm8211: fix
checkpatch errors for indentation and new line around switch-case'.
Thanks for the prompt feedback. I appreciate your patience.

 
  diff --git a/drivers/net/wireless/adm8211.c b/drivers/net/wireless/adm8211.c
 []
  @@ -1098,14 +1098,18 @@ static void adm8211_hw_init(struct ieee80211_hw 
  *dev)
  pci_read_config_byte(priv-pdev, PCI_CACHE_LINE_SIZE, 
  cline);
   
  switch (cline) {
  -   case  0x8: reg |= (0x1  14);
  -  break;
  -   case 0x16: reg |= (0x2  14);
  -  break;
  -   case 0x32: reg |= (0x3  14);
  -  break;
  - default: reg |= (0x0  14);
  -  break;
  +   case  0x8:
  +   reg |= (0x1  14);
  +   break;
  +   case 0x16:
  +   reg |= (0x2  14);
  +   break;
  +   case 0x32:
  +   reg |= (0x3  14);
  +   break;
  + default:
  +   reg |= (0x0  14);
  +   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: not syncing: Attempted to kill init! exitcode=0x00000004 ?

2015-05-05 Thread Shawn Guo
On Tue, Apr 07, 2015 at 12:34:30PM +0900, Masahiro Yamada wrote:
 Hello experts,
 I hope this is the correct ML to ask this question.
 
 I am struggling to port Linux-4.0-rc7 onto my SoC/board,
 based on ARM cortex-A9 (single CPU), but the kernel fails to boot
 with the error:
 not syncing: Attempted to kill init! exitcode=0x0004

Hi Masahiro,

Have you track it down to the cause?  I'm asking because I'm seeing the
same issue with v4.0 on a vendor single Cortex-A9 SoC.

Shawn

 
 
 I want to use NS16550-compatible UART, Global Timer, and GIC.
 I wrote a simple device tree source for my own board like this:
 
 --8--
 /dts-v1/;
 /include/ skeleton.dtsi
 
 / {
 compatible = socionext,ph1-ld4;
 
 memory {
 device_type = memory;
 reg = 0x8000 0x2000;
 };
 
 chosen {
 bootargs = root=/dev/ram0 console=ttyS0,115200;
 };
 
 aliases {
 serial0 = uart0;
 };
 
 cpus {
 #size-cells = 0;
 #address-cells = 1;
 
 cpu@0 {
 device_type = cpu;
 compatible = arm,cortex-a9;
 reg = 0;
 };
 };
 
 clocks {
 #address-cells = 1;
 #size-cells = 0;
 
 arm_timer_clk: arm_timer_clk {
 #clock-cells = 0;
 compatible = fixed-clock;
 clock-frequency = 5000;
 };
 };
 
 soc: soc {
 compatible = simple-bus;
 #address-cells = 1;
 #size-cells = 1;
 interrupt-parent = intc;
 ranges;
 
 
 uart0: uart@03fb {
 compatible = ns16550;
 reg = 0x03fb 0x100;
 clock-frequency = 12288000;
 interrupts = 0 81 4;
 reg-shift = 1;
 fifo-size = 16;
 };
 
 intc: interrupt-controller@60001000 {
 compatible = arm,cortex-a9-gic;
 #interrupt-cells = 3;
 #address-cells = 1;
 interrupt-controller;
 reg = 0x60001000 0x1000,
   0x6100 0x100;
 };
 
 global_timer: timer@6200 {
 compatible = arm,cortex-a9-global-timer;
 reg = 0x6200 0x20;
 interrupts = 1 11 0x104;
 interrupt-parent = intc;
 clocks = arm_timer_clk;
 };
 
 };
 };
 -8
 
 
 The Kernel configuration is based on multi_v7_defconfig.
 The diffconfig against it is like this:
 (ARCH_UNIPHIER is intended to enable my SoC)
 
 --8--
 CONFIG_ARCH_UNIPHIER=y
 CONFIG_BLK_DEV_RAM=y
 CONFIG_BLK_DEV_RAM_SIZE=16384
 -8---
 
 
 
 I passed the kernel image, the device tree, and the initramdisk from U-Boot.
 
 I guess I am almost there, but it looks like the kernel failed to run init.
 The kernel log is as follows:
 
 
 --8--
 [0.00] Booting Linux on physical CPU 0x0
 [0.00] Linux version 4.0.0-rc7-00032-g8c5ce71-dirty
 (yamada@beagle) (gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-12ubuntu1) )
 #7 SMP Tue Apr 7 12:20:19 JST 2015
 [0.00] CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=10c5387d
 [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
 instruction cache
 [0.00] Machine model: socionext,ph1-ld4
 [0.00] cma: Reserved 64 MiB at 0x9b00
 [0.00] Memory policy: Data cache writeback
 [0.00] CPU: All CPU(s) started in SVC mode.
 [0.00] PERCPU: Embedded 11 pages/cpu @dfbc9000 s12480 r8192
 d24384 u45056
 [0.00] Built 1 zonelists in Zone order, mobility grouping on.
 Total pages: 130048
 [0.00] Kernel command line: root=/dev/ram0 console=ttyS0,115200
 [0.00] PID hash table entries: 2048 (order: 1, 8192 bytes)
 [0.00] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
 [0.00] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
 [0.00] Memory: 435456K/524288K available (7830K kernel code,
 1015K rwdata, 3412K rodata, 808K init, 316K bss, 23296K reserved,
 65536K cma-reserved, 0K highmem)
 [0.00] Virtual kernel memory layout:
 [0.00] vector  : 0x - 0x1000   (   4 kB)
 [0.00] fixmap  : 0xffc0 - 0xfff0   (3072 kB)
 [0.00] vmalloc : 0xe080 - 

Re: [PATCH 2/9] ARM: tegra: fix hda2codec_2x clock name for Tegra30

2015-05-05 Thread Thierry Reding
On Fri, Apr 10, 2015 at 11:35:57PM +0200, Marcel Ziswiler wrote:
 From: Marcel Ziswiler marcel.ziswi...@toradex.com
 
 Signed-off-by: Marcel Ziswiler marcel.ziswi...@toradex.com
 ---
  drivers/clk/tegra/clk-tegra30.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

I think this isn't technically required because we're always getting the
clocks via DT phandles. The whole devclks table should be obsolete since
a couple of releases now, but might as well keep it correct until we've
determined that it is safe to remove.

Added a short commit message and applied this for v4.2.

Thanks,
Thierry


pgpC7pBuyY5L8.pgp
Description: PGP signature


[PATCH v4 3/5] clk: hi6220: Document devicetree bindings for hi6220 clock

2015-05-05 Thread Bintian Wang
Document DT files bindings for Hisilicon hi6220 clock.

Signed-off-by: Bintian Wang bintian.w...@huawei.com
Reviewed-by: Haojian Zhuang haojian.zhu...@linaro.org
---
 .../devicetree/bindings/clock/hi6220-clock.txt | 34 ++
 1 file changed, 34 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/hi6220-clock.txt

diff --git a/Documentation/devicetree/bindings/clock/hi6220-clock.txt 
b/Documentation/devicetree/bindings/clock/hi6220-clock.txt
new file mode 100644
index 000..53ddb19
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/hi6220-clock.txt
@@ -0,0 +1,34 @@
+* Hisilicon Hi6220 Clock Controller
+
+Clock control registers reside in different Hi6220 system controllers,
+please refer the following document to know more about the binding rules
+for these system controllers:
+
+Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
+
+Required Properties:
+
+- compatible: the compatible should be one of the following strings to
+   indicate the clock controller functionality.
+
+   - hisilicon,hi6220-aoctrl
+   - hisilicon,hi6220-sysctrl
+   - hisilicon,hi6220-mediactrl
+   - hisilicon,hi6220-pmctrl
+
+- reg: physical base address of the controller and length of memory mapped
+  region.
+
+- #clock-cells: should be 1.
+
+For example:
+   sys_ctrl: sys_ctrl {
+   compatible = hisilicon,hi6220-sysctrl, syscon;
+   reg = 0x0 0xf703 0x0 0x2000;
+   #clock-cells = 1;
+   };
+
+Each clock is assigned an identifier and client nodes use this identifier
+to specify the clock which they consume.
+
+All these identifier could be found in dt-bindings/clock/hi6220-clock.h.
-- 
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 4/9] usb:fsl:otg: Modify otg_event to start host drv

2015-05-05 Thread Ramneek Mehresh
Add mechanism to start host driver from inside fsl_otg_even
upon each id change interrupt

Signed-off-by: Ramneek Mehresh ramneek.mehr...@freescale.com
Reviewed-by: Fleming Andrew-AFLEMING aflem...@freescale.com
Tested-by: Fleming Andrew-AFLEMING aflem...@freescale.com
---
 drivers/usb/phy/phy-fsl-usb.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/usb/phy/phy-fsl-usb.c b/drivers/usb/phy/phy-fsl-usb.c
index 26168da..2eb54ef 100644
--- a/drivers/usb/phy/phy-fsl-usb.c
+++ b/drivers/usb/phy/phy-fsl-usb.c
@@ -677,6 +677,10 @@ static void fsl_otg_event(struct work_struct *work)
fsl_otg_start_host(fsm, 0);
otg_drv_vbus(fsm, 0);
fsl_otg_start_gadget(fsm, 1);
+   } else {
+   fsl_otg_start_gadget(fsm, 0);
+   otg_drv_vbus(fsm, 1);
+   fsl_otg_start_host(fsm, 1);
}
 }
 
-- 
1.8.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 6/9] usb:fsl:otg: Remove host drv upon otg bring-up

2015-05-05 Thread Ramneek Mehresh
Change have_hcd variable to remove/suspend host driver on
completion of otg initialization for otg auto detect

Signed-off-by: Ramneek Mehresh ramneek.mehr...@freescale.com
Reviewed-by: Li Yang-R58472 le...@freescale.com
Reviewed-by: Fleming Andrew-AFLEMING aflem...@freescale.com
Tested-by: Fleming Andrew-AFLEMING aflem...@freescale.com
---
 drivers/usb/host/ehci-fsl.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
index b2f5949..87e4a9a 100644
--- a/drivers/usb/host/ehci-fsl.c
+++ b/drivers/usb/host/ehci-fsl.c
@@ -178,6 +178,11 @@ static int usb_hcd_fsl_probe(const struct hc_driver 
*driver,
retval = -ENODEV;
goto err2;
}
+
+   ehci_fsl-have_hcd = 1;
+   } else {
+   dev_err(pdev-dev, wrong operating mode\n);
+   return -ENODEV;
}
 #endif
return retval;
-- 
1.8.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 8/9] usb:fsl:otg: Resolve OTG crash issue with another host

2015-05-05 Thread Ramneek Mehresh
Resolves kernel crash issue when a USB flash drive is inserted
into USB1 port with USB2 port configured as otg. Removing
else block so that the controller coming up in non-otg mode
doesn't return -ENODEV. Returning ENODEV results in platform
framework unbinding platform-drv from controller resulting in
kernel crash later in hub driver

Signed-off-by: Ramneek Mehresh ramneek.mehr...@freescale.com
---
 drivers/usb/host/ehci-fsl.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
index 87e4a9a..26d1bc4 100644
--- a/drivers/usb/host/ehci-fsl.c
+++ b/drivers/usb/host/ehci-fsl.c
@@ -180,9 +180,6 @@ static int usb_hcd_fsl_probe(const struct hc_driver *driver,
}
 
ehci_fsl-have_hcd = 1;
-   } else {
-   dev_err(pdev-dev, wrong operating mode\n);
-   return -ENODEV;
}
 #endif
return retval;
-- 
1.8.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 5/9] usb:fsl:otg: Combine host/gadget start/resume for ID change

2015-05-05 Thread Ramneek Mehresh
Make call to fsl_otg_event for each id change even

Signed-off-by: Ramneek Mehresh ramneek.mehr...@freescale.com
Reviewed-by: Fleming Andrew-AFLEMING aflem...@freescale.com
Tested-by: Fleming Andrew-AFLEMING aflem...@freescale.com
---
 drivers/usb/phy/phy-fsl-usb.c | 15 +++
 1 file changed, 3 insertions(+), 12 deletions(-)

diff --git a/drivers/usb/phy/phy-fsl-usb.c b/drivers/usb/phy/phy-fsl-usb.c
index 2eb54ef..ce40d5c 100644
--- a/drivers/usb/phy/phy-fsl-usb.c
+++ b/drivers/usb/phy/phy-fsl-usb.c
@@ -733,6 +733,7 @@ irqreturn_t fsl_otg_isr(int irq, void *dev_id)
 {
struct otg_fsm *fsm = ((struct fsl_otg *)dev_id)-fsm;
struct usb_otg *otg = ((struct fsl_otg *)dev_id)-phy.otg;
+   struct fsl_otg *otg_dev = dev_id;
u32 otg_int_src, otg_sc;
 
otg_sc = fsl_readl(usb_dr_regs-otgsc);
@@ -762,18 +763,8 @@ irqreturn_t fsl_otg_isr(int irq, void *dev_id)
otg-gadget-is_a_peripheral = !fsm-id;
VDBG(ID int (ID is %d)\n, fsm-id);
 
-   if (fsm-id) {  /* switch to gadget */
-   schedule_delayed_work(
-   ((struct fsl_otg *)dev_id)-otg_event,
-   100);
-   } else {/* switch to host */
-   cancel_delayed_work(
-   ((struct fsl_otg *)dev_id)-
-   otg_event);
-   fsl_otg_start_gadget(fsm, 0);
-   otg_drv_vbus(fsm, 1);
-   fsl_otg_start_host(fsm, 1);
-   }
+   schedule_delayed_work(otg_dev-otg_event, 100);
+
return IRQ_HANDLED;
}
}
-- 
1.8.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 9/9] usb:fsl:otg: Make fsl otg driver as tristate

2015-05-05 Thread Ramneek Mehresh
Provide option to load fsl otg driver as loadable
module

Signed-off-by: Ramneek Mehresh ramneek.mehr...@freescale.com
---
 drivers/usb/phy/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index 2175678..4927905 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -19,7 +19,7 @@ config AB8500_USB
  in host mode, low speed.
 
 config FSL_USB2_OTG
-   bool Freescale USB OTG Transceiver Driver
+   tristate Freescale USB OTG Transceiver Driver
depends on USB_EHCI_FSL  USB_FSL_USB2  USB_OTG_FSM  PM
select USB_OTG
select USB_PHY
-- 
1.8.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/


Re: [PATCH 3.14 73/92] dm crypt: fix deadlock when async crypto algorithm returns -EBUSY

2015-05-05 Thread Mike Snitzer
On Tue, May 05 2015 at  2:42am -0400,
Milan Broz mb...@redhat.com wrote:

 On 05/05/2015 05:22 AM, Mike Snitzer wrote:
  On Mon, May 04 2015 at  5:32pm -0400,
  Rabin Vincent ra...@rab.in wrote:
  
  On Sat, May 02, 2015 at 09:03:28PM +0200, Greg Kroah-Hartman wrote:
  3.14-stable review patch.  If anyone has any objections, please let me 
  know.
 
  --
 
  From: Ben Collins be...@servergy.com
 
  commit 0618764cb25f6fa9fb31152995de42a8a0496475 upstream.
 
  The commit in question was recently merged to mainline and is now being
  sent to various stable kernels.  But I think the patch is wrong and the
  real problem lies in the Freescale CAAM driver which is described as
  having being tested with.
 ...
 
  dm-crypt uses CRYPTO_TFM_REQ_MAY_BACKLOG.  This means the the crypto
  driver should internally backlog requests which arrive when the queue is
  full and process them later.  Until the crypto hw's queue becomes full,
  the driver returns -EINPROGRESS.  When the crypto hw's queue if full,
  the driver returns -EBUSY, and if CRYPTO_TFM_REQ_MAY_BACKLOG is set, is
  expected to backlog the request and process it when the hardware has
  queue space.  At the point when the driver takes the request from the
  backlog and starts processing it, it calls the completion function with
  a status of -EINPROGRESS.  The completion function is called (for a
  second time, in the case of backlogged requests) with a status/err of 0
  when a request is done.
 
 
 Mike, I thought there was a discussion with crypto API maintainer before
 merging this patch, I think there were some comments that the patch seems
 to be not correct...

I unfortunately didn't cc Herbert on the original v2 patch (but I did
later bounce the mail to him IIRC).  Regardless, no I didn't see any
feedback and I really should've been more active in engaging him.

 This API (EBUSY/EINPROGESS codes) use was there since dmcrypt switched
 to async crypto API.
 
 There should tests for it (some years ago we tested the async path by forcing
 to use cryptd, this was able to clearly simulate the BUSY path as well),
 but not sure if it is still possible so easily.
 
  Any chance you'd be willing to provide in-code comments in the
  appropriate places in dm-crypt.c (after having reverted this patch in
  question)?
  
  I'd be happy to take the combination of the revert and documentation in
  a single patch and get it to Linus for 4.0-rc3.
 
 Please, do not mix revert patches with additions (even if it is just comment),
 someone could be even more confused what's going on here.

I was only saying to mix comments and revert if the patch in question
didn't get into stable@ at all.

But safer to just do a pure revert.  I get it queued up to send to Linus.

 If nobody volunteers, I'll try to add some comments later to dmcrypt code,
 but that is definitely not for stable.

Yeap, 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/


[PATCH v8 01/23] IB/Verbs: Implement new callback query_protocol()

2015-05-05 Thread Michael Wang
Add new callback query_protocol() and implement for each HW.

Mapping List:
node-type   link-layer  transport   protocol
nes RNICETH IWARP   IWARP
amso1100RNICETH IWARP   IWARP
cxgb3   RNICETH IWARP   IWARP
cxgb4   RNICETH IWARP   IWARP
usnic   USNIC_UDP   ETH USNIC_UDP   USNIC_UDP
ocrdma  IB_CA   ETH IB  IBOE
mlx4IB_CA   IB/ETH  IB  IB/IBOE
mlx5IB_CA   IB  IB  IB
ehcaIB_CA   IB  IB  IB
ipath   IB_CA   IB  IB  IB
mthca   IB_CA   IB  IB  IB
qib IB_CA   IB  IB  IB

Signed-off-by: Michael Wang yun.w...@profitbricks.com
---
 drivers/infiniband/core/device.c |  1 +
 drivers/infiniband/hw/amso1100/c2_provider.c |  7 +++
 drivers/infiniband/hw/cxgb3/iwch_provider.c  |  7 +++
 drivers/infiniband/hw/cxgb4/provider.c   |  7 +++
 drivers/infiniband/hw/ehca/ehca_hca.c|  6 ++
 drivers/infiniband/hw/ehca/ehca_iverbs.h |  3 +++
 drivers/infiniband/hw/ehca/ehca_main.c   |  1 +
 drivers/infiniband/hw/ipath/ipath_verbs.c|  7 +++
 drivers/infiniband/hw/mlx4/main.c| 10 ++
 drivers/infiniband/hw/mlx5/main.c|  7 +++
 drivers/infiniband/hw/mthca/mthca_provider.c |  7 +++
 drivers/infiniband/hw/nes/nes_verbs.c|  6 ++
 drivers/infiniband/hw/ocrdma/ocrdma_main.c   |  1 +
 drivers/infiniband/hw/ocrdma/ocrdma_verbs.c  |  6 ++
 drivers/infiniband/hw/ocrdma/ocrdma_verbs.h  |  3 +++
 drivers/infiniband/hw/qib/qib_verbs.c|  7 +++
 drivers/infiniband/hw/usnic/usnic_ib_main.c  |  1 +
 drivers/infiniband/hw/usnic/usnic_ib_verbs.c |  6 ++
 drivers/infiniband/hw/usnic/usnic_ib_verbs.h |  2 ++
 include/rdma/ib_verbs.h  |  9 +
 20 files changed, 104 insertions(+)

diff --git a/drivers/infiniband/core/device.c b/drivers/infiniband/core/device.c
index 18c1ece..b360350 100644
--- a/drivers/infiniband/core/device.c
+++ b/drivers/infiniband/core/device.c
@@ -76,6 +76,7 @@ static int ib_device_check_mandatory(struct ib_device *device)
} mandatory_table[] = {
IB_MANDATORY_FUNC(query_device),
IB_MANDATORY_FUNC(query_port),
+   IB_MANDATORY_FUNC(query_protocol),
IB_MANDATORY_FUNC(query_pkey),
IB_MANDATORY_FUNC(query_gid),
IB_MANDATORY_FUNC(alloc_pd),
diff --git a/drivers/infiniband/hw/amso1100/c2_provider.c 
b/drivers/infiniband/hw/amso1100/c2_provider.c
index bdf3507..6fe329a 100644
--- a/drivers/infiniband/hw/amso1100/c2_provider.c
+++ b/drivers/infiniband/hw/amso1100/c2_provider.c
@@ -99,6 +99,12 @@ static int c2_query_port(struct ib_device *ibdev,
return 0;
 }
 
+static enum rdma_protocol_type
+c2_query_protocol(struct ib_device *device, u8 port_num)
+{
+   return RDMA_PROTOCOL_IWARP;
+}
+
 static int c2_query_pkey(struct ib_device *ibdev,
 u8 port, u16 index, u16 * pkey)
 {
@@ -801,6 +807,7 @@ int c2_register_device(struct c2_dev *dev)
dev-ibdev.dma_device = dev-pcidev-dev;
dev-ibdev.query_device = c2_query_device;
dev-ibdev.query_port = c2_query_port;
+   dev-ibdev.query_protocol = c2_query_protocol;
dev-ibdev.query_pkey = c2_query_pkey;
dev-ibdev.query_gid = c2_query_gid;
dev-ibdev.alloc_ucontext = c2_alloc_ucontext;
diff --git a/drivers/infiniband/hw/cxgb3/iwch_provider.c 
b/drivers/infiniband/hw/cxgb3/iwch_provider.c
index 811b24a..298d1ca 100644
--- a/drivers/infiniband/hw/cxgb3/iwch_provider.c
+++ b/drivers/infiniband/hw/cxgb3/iwch_provider.c
@@ -1232,6 +1232,12 @@ static int iwch_query_port(struct ib_device *ibdev,
return 0;
 }
 
+static enum rdma_protocol_type
+iwch_query_protocol(struct ib_device *device, u8 port_num)
+{
+   return RDMA_PROTOCOL_IWARP;
+}
+
 static ssize_t show_rev(struct device *dev, struct device_attribute *attr,
char *buf)
 {
@@ -1385,6 +1391,7 @@ int iwch_register_device(struct iwch_dev *dev)
dev-ibdev.dma_device = (dev-rdev.rnic_info.pdev-dev);
dev-ibdev.query_device = iwch_query_device;
dev-ibdev.query_port = iwch_query_port;
+   dev-ibdev.query_protocol = iwch_query_protocol;
dev-ibdev.query_pkey = iwch_query_pkey;
dev-ibdev.query_gid = iwch_query_gid;
dev-ibdev.alloc_ucontext = iwch_alloc_ucontext;
diff --git a/drivers/infiniband/hw/cxgb4/provider.c 
b/drivers/infiniband/hw/cxgb4/provider.c
index 66bd6a2..f52ee63 100644
--- a/drivers/infiniband/hw/cxgb4/provider.c
+++ 

[PATCH 1/1] fcoe: use continue instead of goto+label

2015-05-05 Thread Jiri Slaby
There is a label pointing to the start of a while loop and a goto
nested only in the loop. The goto jumps to the label in some cases.
Replace the goto and the label by simple continue.

Signed-off-by: Jiri Slaby jsl...@suse.cz
Cc: Robert Love robert.w.l...@intel.com
Cc: fcoe-de...@open-fcoe.org
---
 drivers/scsi/fcoe/fcoe.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/scsi/fcoe/fcoe.c b/drivers/scsi/fcoe/fcoe.c
index ec193a8357d7..179d0ff5562f 100644
--- a/drivers/scsi/fcoe/fcoe.c
+++ b/drivers/scsi/fcoe/fcoe.c
@@ -1873,7 +1873,6 @@ static int fcoe_percpu_receive_thread(void *arg)
 
set_user_nice(current, MIN_NICE);
 
-retry:
while (!kthread_should_stop()) {
 
spin_lock_bh(p-fcoe_rx_list.lock);
@@ -1883,7 +1882,7 @@ retry:
set_current_state(TASK_INTERRUPTIBLE);
spin_unlock_bh(p-fcoe_rx_list.lock);
schedule();
-   goto retry;
+   continue;
}
 
spin_unlock_bh(p-fcoe_rx_list.lock);
-- 
2.3.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 3.2 042/221] ALSA: hdspm - Constrain periods to 2 on older cards

2015-05-05 Thread Ben Hutchings
On Tue, 2015-05-05 at 14:46 +0200, Adrian Knoth wrote:
 On 05/05/15 03:16, Ben Hutchings wrote:
 
  3.2.69-rc1 review patch.  If anyone has any objections, please let me know.
 
 I do! :)
 
  
  From: Adrian Knoth a...@drcomp.erfurt.thur.de
  
  commit f0153c3d948c1764f6c920a0675d86fc1d75813e upstream.
  
  RME RayDAT and AIO use a fixed buffer size of 16384 samples. With period
  sizes of 32-4096, this translates to 4-512 periods.
  
  The older RME cards have a variable buffer size but require exactly two
  periods.
  
  This patch enforces nperiods=2 on those cards.
  
  Signed-off-by: Adrian Knoth a...@drcomp.erfurt.thur.de
  Signed-off-by: Takashi Iwai ti...@suse.de
  Signed-off-by: Ben Hutchings b...@decadent.org.uk
  ---
   sound/pci/rme9652/hdspm.c | 6 ++
   1 file changed, 6 insertions(+)
  
  --- a/sound/pci/rme9652/hdspm.c
  +++ b/sound/pci/rme9652/hdspm.c
  @@ -6040,6 +6040,12 @@ static int snd_hdspm_capture_open(struct
  snd_pcm_hw_constraint_minmax(runtime,
   SNDRV_PCM_HW_PARAM_PERIOD_SIZE,
   64, 8192);
  +   snd_pcm_hw_constraint_minmax(runtime,
  +SNDRV_PCM_HW_PARAM_PERIODS,
  +2, 2);
  +   snd_pcm_hw_constraint_minmax(runtime,
  +SNDRV_PCM_HW_PARAM_PERIODS,
  +2, 2);
  break;
  }
 
 This is not correct, those lines need to go to two different functions
 (snd_hdspm_playback_open and snd_hdspm_capture_open)
 
 Here is how the patch should look like:

Thanks, I've now fixed it.

[...]
 PS: This exact same problem happened to GregKH for one of his stable
 branches. Not sure what's the root cause and if it's worth
 investigating.

It's a bug in patch: https://bugs.debian.org/717782

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


signature.asc
Description: This is a digitally signed message part


[PATCH v8 02/23] IB/Verbs: Implement raw management helpers

2015-05-05 Thread Michael Wang
Add raw helpers:
rdma_protocol_ib
rdma_protocol_iboe
rdma_protocol_iwarp
rdma_ib_or_iboe (transition, clean up later)
To help us detect which technology the port supported.

Signed-off-by: Michael Wang yun.w...@profitbricks.com
---
 include/rdma/ib_verbs.h | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
index 080f204..e6dd984 100644
--- a/include/rdma/ib_verbs.h
+++ b/include/rdma/ib_verbs.h
@@ -1752,6 +1752,28 @@ int ib_query_port(struct ib_device *device,
 enum rdma_link_layer rdma_port_get_link_layer(struct ib_device *device,
   u8 port_num);
 
+static inline bool rdma_protocol_ib(struct ib_device *device, u8 port_num)
+{
+   return device-query_protocol(device, port_num) == RDMA_PROTOCOL_IB;
+}
+
+static inline bool rdma_protocol_iboe(struct ib_device *device, u8 port_num)
+{
+   return device-query_protocol(device, port_num) == RDMA_PROTOCOL_IBOE;
+}
+
+static inline bool rdma_protocol_iwarp(struct ib_device *device, u8 port_num)
+{
+   return device-query_protocol(device, port_num) == RDMA_PROTOCOL_IWARP;
+}
+
+static inline bool rdma_ib_or_iboe(struct ib_device *device, u8 port_num)
+{
+   enum rdma_protocol_type pt = device-query_protocol(device, port_num);
+
+   return (pt == RDMA_PROTOCOL_IB || pt == RDMA_PROTOCOL_IBOE);
+}
+
 int ib_query_gid(struct ib_device *device,
 u8 port_num, int index, union ib_gid *gid);
 
-- 
2.1.0

--
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 v8 00/23] IB/Verbs: IB Management Helpers

2015-05-05 Thread Michael Wang
Since v7:
  * Thanks to Doug, Ira, Devesh for the testing :-)
  * Thanks for the comments from or, Doug, Ira, Jason :-)
Please remind me if anything missed :-P
  * Use rdma_cap_XX() instead of cap_XX() for readability
  * Remove CC list in git log for maintainability
  * Use bool as return value
  * Updated github repository to v8

There are plenty of lengthy code to check the transport type of IB device,
or the link layer type of it's port, but actually we are just speculating
whether a particular management/feature is supported by the device/port.

Thus instead of inferring, we should have our own mechanism for IB management
capability/protocol/feature checking, several proposals below.

This patch set will introduce query_protocol() to check management requirement
instead of inferring from transport and link layer respectively, along with
the new enum on protocol type.

Mapping List:
node-type   link-layer  transport   protocol
nes RNICETH IWARP   IWARP
amso1100RNICETH IWARP   IWARP
cxgb3   RNICETH IWARP   IWARP
cxgb4   RNICETH IWARP   IWARP
usnic   USNIC_UDP   ETH USNIC_UDP   USNIC_UDP
ocrdma  IB_CA   ETH IB  IBOE
mlx4IB_CA   IB/ETH  IB  IB/IBOE
mlx5IB_CA   IB  IB  IB
ehcaIB_CA   IB  IB  IB
ipath   IB_CA   IB  IB  IB
mthca   IB_CA   IB  IB  IB
qib IB_CA   IB  IB  IB

For example:
if (transport == IB)  (link-layer == ETH)
will now become:
if (query_protocol() == IBOE)

Thus we will be able to get rid of the respective transport and link-layer
checking, and it will help us to add new protocol/Technology (like OPA) more
easier, also with the introduced management helpers, IB management logical
will be more clear and easier for extending.

Highlights:
The long CC list in each patches was complained consider about the
maintainability, it was suggested folks to provide their reviewed-by or
Acked-by instead, so for those who used to be on the CC list, please
provide your signature voluntarily :-)

The 'mgmt-helpers' branch of 'g...@github.com:ywang-pb/infiniband-wy.git'
contain this series based on the latest 'infiniband/for-next'

Patch 1#~14# included all the logical reform, 15#~23# introduced the
management helpers.

Doug suggested the bitmask mechanism:
https://www.mail-archive.com/linux-rdma@vger.kernel.org/msg23765.html
which could be the plan for future reforming, we prefer that to be another
series which focus on semantic and performance.

This patch-set is somewhat 'bloated' now and it may be a good timing for
staging, I'd like to suggest we focus on improving existed helpers and push
all the further reforms into next series ;-)

Proposals:
Sean:
https://www.mail-archive.com/linux-rdma@vger.kernel.org/msg23339.html
Doug:
https://www.mail-archive.com/linux-rdma@vger.kernel.org/msg23418.html
https://www.mail-archive.com/linux-rdma@vger.kernel.org/msg23765.html
Jason:
https://www.mail-archive.com/linux-rdma@vger.kernel.org/msg23425.html

Michael Wang (23):
  IB/Verbs: Implement new callback query_protocol()
  IB/Verbs: Implement raw management helpers
  IB/Verbs: Reform IB-core mad/agent/user_mad
  IB/Verbs: Reform IB-core cm
  IB/Verbs: Reform IB-core sa_query
  IB/Verbs: Reform IB-core multicast
  IB/Verbs: Reform IB-ulp ipoib
  IB/Verbs: Reform IB-ulp xprtrdma
  IB/Verbs: Reform IB-core verbs
  IB/Verbs: Reform cm related part in IB-core cma/ucm
  IB/Verbs: Reform route related part in IB-core cma
  IB/Verbs: Reform mcast related part in IB-core cma
  IB/Verbs: Reform cma_acquire_dev()
  IB/Verbs: Reform rest part in IB-core cma
  IB/Verbs: Use management helper rdma_cap_ib_mad()
  IB/Verbs: Use management helper rdma_cap_ib_smi()
  IB/Verbs: Use management helper rdma_cap_ib_cm()
  IB/Verbs: Use management helper rdma_cap_iw_cm()
  IB/Verbs: Use management helper rdma_cap_ib_sa()
  IB/Verbs: Use management helper rdma_cap_ib_mcast()
  IB/Verbs: Use management helper rdma_cap_read_multi_sge()
  IB/Verbs: Use management helper rdma_cap_af_ib()
  IB/Verbs: Use management helper rdma_cap_eth_ah()

 drivers/infiniband/core/agent.c  |   2 +-
 drivers/infiniband/core/cm.c |  20 ++-
 drivers/infiniband/core/cma.c| 257 +++
 drivers/infiniband/core/device.c |   1 +
 drivers/infiniband/core/mad.c|  43 +++--
 drivers/infiniband/core/multicast.c  |  12 +-
 

Re: [PATCH v3 3/7] mmc: mediatek: Add PM support for MMC driver

2015-05-05 Thread Ulf Hansson
On 28 April 2015 at 11:48, Chaotian Jing chaotian.j...@mediatek.com wrote:
 Add PM support for Mediatek MMC driver

 Signed-off-by: Chaotian Jing chaotian.j...@mediatek.com
 ---
  drivers/mmc/host/mtk-sd.c | 58 
 +++
  1 file changed, 53 insertions(+), 5 deletions(-)

 diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
 index 30e688d..79177d9 100644
 --- a/drivers/mmc/host/mtk-sd.c
 +++ b/drivers/mmc/host/mtk-sd.c
 @@ -22,6 +22,7 @@
  #include linux/of_gpio.h
  #include linux/pinctrl/consumer.h
  #include linux/platform_device.h
 +#include linux/pm_runtime.h
  #include linux/regulator/consumer.h
  #include linux/spinlock.h

 @@ -215,6 +216,7 @@
  #define MSDC_ASYNC_FLAG (0x1  1)
  #define MSDC_MMAP_FLAG (0x1  2)

 +#define MTK_MMC_AUTOSUSPEND_DELAY  500

Most other mmc host drivers use 50ms, any reason to why this driver
wants a different value?

  #define CMD_TIMEOUT (HZ/10 * 5)/* 100ms x5 */
  #define DAT_TIMEOUT (HZ* 5)/* 1000ms x5 */

 @@ -706,6 +708,9 @@ static void msdc_request_done(struct msdc_host *host, 
 struct mmc_request *mrq)
 if (mrq-data)
 msdc_unprepare_data(host, mrq);
 mmc_request_done(host-mmc, mrq);
 +
 +   pm_runtime_mark_last_busy(host-dev);
 +   pm_runtime_put_autosuspend(host-dev);
  }

  /* returns true if command is fully handled; returns false otherwise */
 @@ -862,6 +867,8 @@ static void msdc_ops_request(struct mmc_host *mmc, struct 
 mmc_request *mrq)
 WARN_ON(host-mrq);
 spin_unlock_irqrestore(host-lock, flags);

 +   pm_runtime_get_sync(host-dev);
 +
 if (mrq-data)
 msdc_prepare_data(host, mrq);

 @@ -999,7 +1006,6 @@ static int msdc_ops_switch_volt(struct mmc_host *mmc, 
 struct mmc_ios *ios)
 int ret = 0;

 if (!IS_ERR(mmc-supply.vqmmc)) {
 -

White space.

 if (ios-signal_voltage == MMC_SIGNAL_VOLTAGE_330) {
 min_uv = 330;
 max_uv = 330;
 @@ -1018,7 +1024,6 @@ static int msdc_ops_switch_volt(struct mmc_host *mmc, 
 struct mmc_ios *ios)
 ret, min_uv, max_uv);
 }
 }
 -

White space.

 return ret;
  }

 @@ -1176,8 +1181,10 @@ static void msdc_ops_set_ios(struct mmc_host *mmc, 
 struct mmc_ios *ios)
 int ret;
 u32 ddr = 0;

 +   pm_runtime_get_sync(host-dev);
 +
 if (ios-timing == MMC_TIMING_UHS_DDR50 ||
 -   ios-timing == MMC_TIMING_MMC_DDR52)
 +   ios-timing == MMC_TIMING_MMC_DDR52)

White space.

 ddr = 1;

 msdc_set_buswidth(host, ios-bus_width);
 @@ -1191,7 +1198,7 @@ static void msdc_ops_set_ios(struct mmc_host *mmc, 
 struct mmc_ios *ios)
 ios-vdd);
 if (ret) {
 dev_err(host-dev, Failed to set vmmc 
 power!\n);
 -   return;
 +   goto end;
 }
 }
 break;
 @@ -1227,6 +1234,10 @@ static void msdc_ops_set_ios(struct mmc_host *mmc, 
 struct mmc_ios *ios)

 if (host-mclk != ios-clock || host-ddr != ddr)
 msdc_set_mclk(host, ddr, ios-clock);
 +
 +end:
 +   pm_runtime_mark_last_busy(host-dev);
 +   pm_runtime_put_autosuspend(host-dev);
  }

  static struct mmc_host_ops mt_msdc_ops = {
 @@ -1350,12 +1361,19 @@ static int msdc_drv_probe(struct platform_device 
 *pdev)
 if (ret)
 goto release;

 +   pm_runtime_set_active(host-dev);
 +   pm_runtime_set_autosuspend_delay(host-dev, 
 MTK_MMC_AUTOSUSPEND_DELAY);
 +   pm_runtime_use_autosuspend(host-dev);
 +   pm_runtime_enable(host-dev);
 ret = mmc_add_host(mmc);
 +
 if (ret)
 -   goto release;
 +   goto end;

 return 0;

 +end:
 +   pm_runtime_disable(host-dev);
  release:
 platform_set_drvdata(pdev, NULL);
 msdc_deinit_hw(host);
 @@ -1368,6 +1386,7 @@ release_mem:
 dma_free_coherent(pdev-dev,
 MAX_BD_NUM * sizeof(struct mt_bdma_desc),
 host-dma.bd, host-dma.bd_addr);
 +

White space.

  host_free:
 mmc_free_host(mmc);

 @@ -1382,10 +1401,14 @@ static int msdc_drv_remove(struct platform_device 
 *pdev)
 mmc = platform_get_drvdata(pdev);
 host = mmc_priv(mmc);

 +   pm_runtime_get_sync(host-dev);
 +
 platform_set_drvdata(pdev, NULL);
 mmc_remove_host(host-mmc);
 msdc_deinit_hw(host);

 +   pm_runtime_disable(host-dev);
 +   pm_runtime_put_noidle(host-dev);
 dma_free_coherent(pdev-dev,
 sizeof(struct mt_gpdma_desc),
 host-dma.gpd, host-dma.gpd_addr);
 @@ -1397,6 +1420,30 @@ static int 

Re: [PATCH V7 3/6] perf, x86: handle multiple records in PEBS buffer

2015-05-05 Thread Peter Zijlstra
On Mon, Apr 20, 2015 at 04:07:47AM -0400, Kan Liang wrote:
 From: Yan, Zheng zheng.z@intel.com

snip

 Here lists some possible ways you may get a lot of collision.

This is the first time the world 'collisions' is used; either define
what you mean by it or avoid using it.

   - when you count the same thing multiple times. But it is not a useful
 configuration.
   - you can be unfortunate if you measure with a userspace only PEBS
 event along with either a kernel or unrestricted PEBS event. Imagine
 the event triggering and setting the overflow flag right before
 entering the kernel. Then all kernel side events will end up with
 multiple bits set.
 
 Here are some numbers about collisions.
 Four frequently occurring events
 (cycles:p,instructions:p,branches:p,mem-stores:p) are tested
 
 Test events which are sampled together   collision rate
 cycles:p,instructions:p  0.25%
 cycles:p,instructions:p,branches:p   0.30%
 cycles:p,instructions:p,branches:p,mem-stores:p  0.35%
 
 cycles:p,cycles:p98.52%

It would be good if you can illustrate this with the new PREF_RECORD and
the perf tool itself.

 Signed-off-by: Yan, Zheng zheng.z@intel.com
 Signed-off-by: Kan Liang kan.li...@intel.com
 ---

 --- a/arch/x86/kernel/cpu/perf_event_intel_ds.c
 +++ b/arch/x86/kernel/cpu/perf_event_intel_ds.c

 @@ -958,19 +961,97 @@ static void setup_pebs_sample_data(struct perf_event 
 *event,
   data-br_stack = cpuc-lbr_stack;
  }
  
 +static void perf_log_lost(struct perf_event *event)
 +{
 + struct perf_output_handle handle;
 + struct perf_sample_data sample;
 + int ret;
 +
 + struct {
 + struct perf_event_headerheader;
 + u64 id;
 + u64 lost;
 + } lost_event = {
 + .header = {
 + .type = PERF_RECORD_LOST,
 + .misc = 0,
 + .size = sizeof(lost_event),
 + },
 + .id = event-id,
 + .lost   = 1,
 + };
 +
 + perf_event_header__init_id(lost_event.header, sample, event);
 +
 + ret = perf_output_begin(handle, event,
 + lost_event.header.size);
 + if (ret)
 + return;
 +
 + perf_output_put(handle, lost_event);
 + perf_event__output_id_sample(event, handle, sample);
 + perf_output_end(handle);
 +}

RECORDs are generic, and should live in the core code.

Also, you should introduce this RECORD in a separate patch.

Ideally, you'd also update the tools side to parse this and modify
perf-record to show the number of dropped events as a percentage, going
warn/error when 1%/5% or so?
--
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 00/20] Tegra210 Clock Support

2015-05-05 Thread Thierry Reding
On Mon, May 04, 2015 at 12:37:20PM -0400, Rhyland Klein wrote:
 This patch series updates the tegra common clock driver and adds
 support for the Tegra210 clocks. The clocks in Tegra210 changed
 significantly in some ways from earlier generations, so to support
 them, we need to extend our base framework a bit and add some new
 features.
 
 Some patches here also address issues found while adding features
 and other cleanup type work.
 
 v4:
   - Fixed minor checkpatch errors and other typos
   - Rebased ontop of linux-next 20150504

Are you sure about this? It still doesn't apply cleanly to next-20150504
for me.

Thierry

 
 v3:
   - Added a fix from Andrew Bresticker that was found while testing
 this code.
 
 Andrew Bresticker (1):
   clk: tegra: pll: Fix issues with rates for VCO PLLs
 
 Bill Huang (7):
   clk: tegra: pll-params: change misc_reg count from 3 - 6
   clk: tegra: pll: Add logic for SS
   clk: tegra: pll: Add code to handle if resets are supported by PLL
   clk: tegra: pll: Adjust vco_min if SDM present
   clk: tegra: pll: Add dyn_ramp callback
   clk: tegra: pll: Add Set_default logic
   clk: tegra: Add Super Gen5 Logic
 
 Rhyland Klein (12):
   clk: tegra: Modify tegra_audio_clk_init to accept more plls
   clk: tegra: periph: add new periph clks and muxes for Tegra210
   clk: tegra: pll: add tegra_pll_wait_for_lock to clk header
   clk: tegra: pll: simplify clk_enable_path
   clk: tegra: pll: update warning msg
   clk: tegra: pll: Don't unconditionally set LOCK flags
   clk: tegra: pll: Add logic for handling SDM data
   clk: tegra: pll: Add logic for out-of-table rates for T210
   clk: tegra: pll: Add specialized logic for T210
   clk: tegra: pll: Add support for PLLMB for T210
   clk: tegra: pll: Fix _pll_ramp_calc_pll logic and
 _calc_dynamic_ramp_rate
   clk: tegra210: add support for Tegra210 clocks
 
  .../bindings/clock/nvidia,tegra210-car.txt |   56 +
  drivers/clk/tegra/Makefile |2 +
  drivers/clk/tegra/clk-id.h |   64 +-
  drivers/clk/tegra/clk-pll.c|  697 -
  drivers/clk/tegra/clk-tegra-audio.c|   25 +-
  drivers/clk/tegra/clk-tegra-periph.c   |  257 +-
  drivers/clk/tegra/clk-tegra-super-gen5.c   |  150 ++
  drivers/clk/tegra/clk-tegra114.c   |   30 +-
  drivers/clk/tegra/clk-tegra124.c   |   31 +-
  drivers/clk/tegra/clk-tegra20.c|   18 +-
  drivers/clk/tegra/clk-tegra210.c   | 2761 
 
  drivers/clk/tegra/clk-tegra30.c|   31 +-
  drivers/clk/tegra/clk.h|   90 +-
  include/dt-bindings/clock/tegra210-car.h   |  401 +++
  14 files changed, 4468 insertions(+), 145 deletions(-)
  create mode 100644 
 Documentation/devicetree/bindings/clock/nvidia,tegra210-car.txt
  create mode 100644 drivers/clk/tegra/clk-tegra-super-gen5.c
  create mode 100644 drivers/clk/tegra/clk-tegra210.c
  create mode 100644 include/dt-bindings/clock/tegra210-car.h
 
 -- 
 1.7.9.5
 


pgpFFlY77G69g.pgp
Description: PGP signature


Re: [PATCH v2 7/7] ACPI / processor: Introduce invalid_phys_cpuid()

2015-05-05 Thread Hanjun Guo

On 2015年05月05日 19:25, Sudeep Holla wrote:



On 05/05/15 03:46, Hanjun Guo wrote:

Introduce invalid_phys_cpuid() to identify cpu with invalid
physical ID, then used it as replacement of the direct comparisons
with PHYS_CPUID_INVALID.

Signed-off-by: Hanjun Guo hanjun@linaro.org
---
  drivers/acpi/acpi_processor.c | 4 ++--
  drivers/acpi/processor_core.c | 4 ++--
  include/linux/acpi.h  | 5 +
  3 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/acpi/acpi_processor.c
b/drivers/acpi/acpi_processor.c
index 62c846b..92a5f73 100644
--- a/drivers/acpi/acpi_processor.c


[...]


diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 913b49f..cc82ff3 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -163,6 +163,11 @@ static inline bool invalid_logical_cpuid(u32 cpuid)
  return (int)cpuid  0;
  }

+static inline bool invalid_phys_cpuid(phys_cpuid_t phys_id)
+{
+return (int)phys_id  0;


Should this be phys_id == PHYS_CPUID_INVALID ? else I don't see why we
need to even define PHYS_CPUID_INVALID


I'm OK with this. For now, CPU phys_id will be valid value or
PHYS_CPUID_INVALID in all cases for ACPI processor driver, but
I want ask Rafael's opinion on this, is it OK to you too, Rafael?

Thanks
Hanjun
--
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 v2] staging: comedi: daqboard2000: Use preferred comment style

2015-05-05 Thread Ian Abbott

On 03/05/15 21:49, Arno Tiemersma wrote:

Use the preferred block comment style for the copyright and driver
description header comments.

Signed-off-by: Arno Tiemersma arno.tiemer...@gmail.com
---
  drivers/staging/comedi/drivers/daqboard2000.c | 196 +-
  1 file changed, 98 insertions(+), 98 deletions(-)



Reviewed-by: Ian Abbott abbo...@mev.co.uk

--
-=( Ian Abbott @ MEV Ltd.E-mail: abbo...@mev.co.uk )=-
-=(  Web: http://www.mev.co.uk/  )=-
--
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/


running hrtimer_start on an already active hrtimer?

2015-05-05 Thread Jiri Bohac
Hi,


I came across a strange bug (in a very old kernel) that triggers
the
BUG_ON(timer-state != HRTIMER_STATE_CALLBACK);
in __run_hrtimer().

The code runs hrtimer_start() on an already started hrtimer. 
Looking at the description of hrtimer_start() it looks
like something that is allowed:
/**
 * hrtimer_start - (re)start an hrtimer on the current CPU
...
 * Returns:
 *  0 on success
 *  1 when the timer was active

Is this really supposed to work?

I think it's not immune to this race condition:

CPU0CPU1
__run_hrtimer()
   __remove_hrtimer(...HRTIMER_STATE_CALLBACK)
  //clears HRTIMER_STATE_ENQUEUED
   ...
   raw_spin_unlock(cpu_base-lock);
   restart = fn(timer);
hrtimer_start()
   __hrtimer_start_range_ns()
  //remove_hrtimer() does 
nothing because
  //  
HRTIMER_STATE_ENQUEUED is not set
  enqueue_hrtimer()
   raw_spin_lock(cpu_base-lock);
   ...
   BUG_ON(timer-state != HRTIMER_STATE_CALLBACK);
   // state has HRTIMER_STATE_ENQUEUED set
   


Should __hrtimer_start_range_ns() do something like
hrtimer_cancel - i.e. explicitly check for ...
HRTIMER_STATE_CALLBACK?


Thanks,

-- 
Jiri Bohac jbo...@suse.cz
SUSE Labs, SUSE CZ

--
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 0/5] arm64,hi6220: Enable Hisilicon Hi6220 SoC

2015-05-05 Thread Haojian Zhuang
On 5 May 2015 at 20:06, Bintian Wang bintian.w...@huawei.com wrote:
 Hi6220 is one mobile solution of Hisilicon, this patchset contains
 initial support for Hi6220 SoC and HiKey development board, which
 supports octal ARM Cortex A53 cores. Initial support is minimal and
 includes just the arch configuration, clock driver, device tree
 configuration.

 PSCI is enabled in device tree and there is no problem to boot all the
 octal cores, and the CPU hotplug is also working now, you can download
 and compile the latest firmware based on the following link to run this
 patch set:
 https://github.com/96boards/documentation/wiki/UEFI

 Changes v4:
 * Rebase to kernel 4.1-rc1
 * Delete arm,cortex-a15-gic from the gic node in dts


Acked-by: Haojian Zhuang haojian.zhu...@linaro.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: [PATCH RFC] Coccinelle: Check for return not matching function signature

2015-05-05 Thread SF Markus Elfring
 How do you think about to import the result list into a database table?
 
 working on that re-cycling your parameter count example
 top 10:
 488 ssize_t != int
 195 int != unsigned int
 183 long != int

…

Would you like to provide a static source code analysis
directly in such a report format?
Will a drill-down into corresponding implementation details
become more interesting for the detection of further open issues?

Regards,
Markus
--
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] kernfs: do not account ino_ida allocations to memcg

2015-05-05 Thread Tejun Heo
On Tue, May 05, 2015 at 12:45:43PM +0300, Vladimir Davydov wrote:
 root-ino_ida is used for kernfs inode number allocations. Since IDA has
 a layered structure, different IDs can reside on the same layer, which
 is currently accounted to some memory cgroup. The problem is that each
 kmem cache of a memory cgroup has its own directory on sysfs (under
 /sys/fs/kernel/cache-name/cgroup). If the inode number of such a
 directory or any file in it gets allocated from a layer accounted to the
 cgroup which the cache is created for, the cgroup will get pinned for
 good, because one has to free all kmem allocations accounted to a cgroup
 in order to release it and destroy all its kmem caches. That said we
 must not account layers of ino_ida to any memory cgroup.
 
 Since per net init operations may create new sysfs entries directly
 (e.g. lo device) or indirectly (nf_conntrack creates a new kmem cache
 per each namespace, which, in turn, creates new sysfs entries), an easy
 way to reproduce this issue is by creating network namespace(s) from
 inside a kmem-active memory cgroup.
 
 Signed-off-by: Vladimir Davydov vdavy...@parallels.com

Man, that's nasty.  For the kernfs part,

Acked-by: Tejun Heo t...@kernel.org

Can you please repost this patch w/ Greg KH cc'd?

Thanks.

-- 
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: [PATCH v2 3/7] ACPI / processor: Introduce invalid_logical_cpuid()

2015-05-05 Thread Rafael J. Wysocki
On Tuesday, May 05, 2015 10:46:34 AM Hanjun Guo wrote:
 In ACPI processor drivers, we use direct comparisons of cpu logical
 id with -1 which are error prone in case logical cpuid is accidentally
 assinged an error code and prevents us from returning an error-encoding
 cpuid directly in some cases.
 
 So introduce invalid_logical_cpuid() to identify cpu with invalid
 logical cpu num, then it will be used to replace the direct comparisons
 with -1.
 
 Signed-off-by: Hanjun Guo hanjun@linaro.org
 ---
  drivers/acpi/acpi_processor.c | 4 ++--
  drivers/acpi/processor_pdc.c  | 5 +
  include/linux/acpi.h  | 5 +
  3 files changed, 8 insertions(+), 6 deletions(-)
 
 diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
 index 95492d0..62c846b 100644
 --- a/drivers/acpi/acpi_processor.c
 +++ b/drivers/acpi/acpi_processor.c
 @@ -274,7 +274,7 @@ static int acpi_processor_get_info(struct acpi_device 
 *device)
* Handle UP system running SMP kernel, with no CPU
* entry in MADT
*/
 - if ((pr-id == -1)  (num_online_cpus() == 1))
 + if (invalid_logical_cpuid(pr-id)  (num_online_cpus() == 1))
   pr-id = 0;
   }
  
 @@ -283,7 +283,7 @@ static int acpi_processor_get_info(struct acpi_device 
 *device)
*  less than the max # of CPUs. They should be ignored _iff
*  they are physically not present.
*/
 - if (pr-id == -1) {
 + if (invalid_logical_cpuid(pr-id)) {
   int ret = acpi_processor_hotadd_init(pr);
   if (ret)
   return ret;
 diff --git a/drivers/acpi/processor_pdc.c b/drivers/acpi/processor_pdc.c
 index e5dd808..6dd98d0 100644
 --- a/drivers/acpi/processor_pdc.c
 +++ b/drivers/acpi/processor_pdc.c
 @@ -52,10 +52,7 @@ static bool __init 
 processor_physically_present(acpi_handle handle)
   type = (acpi_type == ACPI_TYPE_DEVICE) ? 1 : 0;
   cpuid = acpi_get_cpuid(handle, type, acpi_id);
  
 - if (cpuid == -1)
 - return false;
 -
 - return true;
 + return invalid_logical_cpuid(cpuid) ? false : true;

What about

return !invalid_logical_cpuid(cpuid);


  }
  
  static void acpi_set_pdc_bits(u32 *buf)
 diff --git a/include/linux/acpi.h b/include/linux/acpi.h
 index e4da5e3..913b49f 100644
 --- a/include/linux/acpi.h
 +++ b/include/linux/acpi.h
 @@ -158,6 +158,11 @@ typedef u32 phys_cpuid_t;
  #define PHYS_CPUID_INVALID (phys_cpuid_t)(-1)
  #endif
  
 +static inline bool invalid_logical_cpuid(u32 cpuid)
 +{
 + return (int)cpuid  0;
 +}
 +
  #ifdef CONFIG_ACPI_HOTPLUG_CPU
  /* Arch dependent functions for cpu hotplug support */
  int acpi_map_cpu(acpi_handle handle, phys_cpuid_t physid, int *pcpu);
 

-- 
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/


[PATCH 1/7] drivers: CCI: fix used_mask init in validate_group()

2015-05-05 Thread Suzuki K. Poulose
From: Mark Salter msal...@redhat.com

Currently in validate_group(), there is a static initializer
for fake_pmu.used_mask which is based on CPU_BITS_NONE but
the used_mask array size is based on CCI_PMU_MAX_HW_EVENTS.
CCI_PMU_MAX_HW_EVENTS is not based on NR_CPUS, so CPU_BITS_NONE
is not correct and will cause a build failure if NR_CPUS
is set high enough to make CPU_BITS_NONE larger than used_mask.
This patch changes the used_mask initialization to be runtime
based on the actual size of the array.

Signed-off-by: Mark Salter msal...@redhat.com
---
 drivers/bus/arm-cci.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/bus/arm-cci.c b/drivers/bus/arm-cci.c
index b854125..941b831 100644
--- a/drivers/bus/arm-cci.c
+++ b/drivers/bus/arm-cci.c
@@ -660,7 +660,7 @@ validate_group(struct perf_event *event)
 * Initialise the fake PMU. We only need to populate the
 * used_mask for the purposes of validation.
 */
-   .used_mask = CPU_BITS_NONE,
+   .used_mask =  { 0 },
};
 
if (!validate_event(event-pmu, fake_pmu, leader))
-- 
1.7.9.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 breaks suspend

2015-05-05 Thread Rafael J. Wysocki
On Tuesday, May 05, 2015 11:38:50 AM Marian Marinov wrote:
 On 05/05/2015 02:37 AM, Rafael J. Wysocki wrote:
  On Saturday, May 02, 2015 11:27:32 PM Marian Marinov wrote:
  Hi guys,
  I have Lenovo T520 with one SSD and one SATA drive.
 
  I tried to upgrade to Linux 4.0 and found that after suspend and resume I 
  can't access the second (SATA) drive.
  Both drives have bios encryption enabled.
 
  I did a bisect and found that the following patch causes the issue:
  commit 5d5132059a1f652de9dc2d62a8ff15561e648d11
  Author: Rafael J. Wysocki rafael.j.wyso...@intel.com
  Date:   Sat Feb 22 00:48:31 2014 +0100
 
  ACPI / ATA: Add hotplug contexts to ACPI companions of SATA devices
 
  Modify the SATA subsystem to add hotplug contexts to ACPI companions
  of SATA devices and ports instead of registering special ACPI dock
  operations using register_hotplug_dock_device().
 
  That change will allow the entire code handling those special ACPI
  dock operations to be dropped in the next commit.
 
  Signed-off-by: Rafael J. Wysocki rafael.j.wyso...@intel.com
  Reviewed-by: Aaron Lu aaron...@intel.com
  Acked-by: Tejun Heo t...@kernel.org
 
  Unfortunately I do not understand this part of the code and have no idea 
  what I can do.
  Any pointers would be very appreciated.
  Well, not right from the top of my head, but this looks really suspicious 
  to me.
 
  Can you please file a bug entry for this at bugzilla.kernel.org (in the 
  ACPI/BIOS
  category), assign it to me and CC Aaron?
 BUG created: https://bugzilla.kernel.org/show_bug.cgi?id=97731
 
 Added you and Aaron to the CC list.
 
 What additional info can I provide you? Would you like any debug info from 
 the kernel it self?
 Dmesg output?

Let's track this one in the BZ from now on if that's not a problem.


-- 
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/


[PATCH 0/7] ARM CCI-500 PMU driver support

2015-05-05 Thread Suzuki K. Poulose
From: Suzuki K. Poulose suzuki.poul...@arm.com

This series adds the support for CCI-500 PMU,  by
reusing and rearranging the CCI-400 PMU driver code.

CCI-500 (the new Cache Coherent Interconnect IP) has
a PMU with 8 independent event counters and supports
profiling events related to master/slave interfaces
along with the global events(cci internal events).

The series also adds aliases for events for all the
supported CCI PMUs(CCI_400{r0,r1}, CCI_500).

Patches 1/7 is a fix posted by Mark Salter, which has
been posted to a...@kernel.org already. I have included
it in this series, as this series applies on top of it.

Patches 2-5 - Creates an abstraction of a CCI PMU and
makes the CCI-400 driver code to make use of the abstraction.
Patch 6 - Adds the CCI-500 PMU driver support
Patch 7 - Adds the aliases for CCI PMU events (specific to chipsets).

With the series, one can use named events for the CCI pmus.

e.g, CCI-400

 # perf list | grep CCI
  CCI_400/cycles/[Kernel PMU event]
  CCI_400/mi_retry_speculative_fetch,source=?/   [Kernel PMU event]

e.g, CCI-500

 # perf list |grep CCI
  CCI_500/cci_rq_stall_address_hazard/   [Kernel PMU event]
  CCI_500/cci_snoop_access_filter_bank_0_1/  [Kernel PMU event]

Testing was performed on a fast model, with perf fuzzer and functional
tests for the CCI-500 PMU.

Mark Salter (1):
  drivers: CCI: fix used_mask init in validate_group()

Suzuki K. Poulose (6):
  arm-cci: Cleanup PMU driver code
  arm-cci: Abstract out the PMU counter details
  arm-cci: Abstract handling for CCI events
  arm-cci: Sanitise CCI400 PMU driver specific code
  arm-cci: Add CCI-500 PMU support
  arm-cci: Add aliases for PMU events

 Documentation/devicetree/bindings/arm/cci.txt |4 +-
 drivers/bus/Kconfig   |   17 +
 drivers/bus/arm-cci.c |  905 -
 3 files changed, 756 insertions(+), 170 deletions(-)

-- 
1.7.9.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 3.2 000/221] 3.2.69-rc1 review

2015-05-05 Thread Ben Hutchings
On Mon, 2015-05-04 at 21:48 -0700, Guenter Roeck wrote:
 On 05/04/2015 06:16 PM, Ben Hutchings wrote:
  This is the start of the stable review cycle for the 3.2.69 release.
  There are 221 patches in this series, which will be posted as responses
  to this one.  If anyone has any issues with these being applied, please
  let me know.
 
  Responses should be made by Fri May 08 23:00:00 UTC 2015.
  Anything received after that time might be too late.
 
 
 Build results:
   total: 101 pass: 97 fail: 4
 Failed builds:
   arm:allmodconfig
   mips:allmodconfig
   xtensa:defconfig
   xtensa:allmodconfig
 
 Qemu test results:
   total: 20 pass: 20 fail: 0
 
 Results are as expected.
 Details are available at http://server.roeck-us.net:8010/builders.

Thanks for testing.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


signature.asc
Description: This is a digitally signed message part


Re: [PATCH 5/9] ARM: tegra: fix hda2codec_2x clock name in Tegra124 device tree

2015-05-05 Thread Thierry Reding
On Fri, Apr 10, 2015 at 11:36:00PM +0200, Marcel Ziswiler wrote:
 From: Marcel Ziswiler marcel.ziswi...@toradex.com
 
 Signed-off-by: Marcel Ziswiler marcel.ziswi...@toradex.com
 ---
  arch/arm/boot/dts/tegra124.dtsi | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

I have this exact commit locally in my tree, so I've just taken the
commit message from that and applied this for v4.2.

Thanks,
Thierry


pgp6sK2FQmS9C.pgp
Description: PGP signature


Re: [PATCH 7/9] ARM: tegra: enable HDA in defconfig

2015-05-05 Thread Thierry Reding
On Fri, Apr 10, 2015 at 11:36:02PM +0200, Marcel Ziswiler wrote:
 From: Marcel Ziswiler marcel.ziswi...@toradex.com
 
 Signed-off-by: Marcel Ziswiler marcel.ziswi...@toradex.com
 ---
  arch/arm/configs/tegra_defconfig | 8 
  1 file changed, 8 insertions(+)

I've squashed this into a single commit with the patch that enables
watchdog support.

Thanks,
Thierry


pgpsdEH42ynSj.pgp
Description: PGP signature


Re: [PATCH v4 04/10] eeprom: Add a simple EEPROM framework for eeprom consumers

2015-05-05 Thread Srinivas Kandagatla

Hi Stephen,

Sorry I took so long to reply.


On 09/04/15 15:45, Stephen Boyd wrote:

On 04/07, Srinivas Kandagatla wrote:

On 07/04/15 19:45, Stephen Boyd wrote:

On 03/30, Srinivas Kandagatla wrote:

Do you have an overview of how to use these APIs? Maybe some
Documentation/ is in order? I'm mostly interested in how the
blocks array is supposed to work and how this hooks up to drivers
that are using DT.


Only doc ATM is function level kernel doc in c file.
May be I can explain you for now and I will try to add some
documentation with some usage examples in next version.


Thanks.



eeprom block array is just another way intended to get hold of
eeprom content for non-DT providers/consumers, but DT
consumers/providers can also use it. As of today SOC/mach level code
could use it as well.

In eeprom_cell_get() case the lookup of provider is done based on
provider name, this provider name is generally supplied by all the
providers (both DT/non DT).

for example in qfprom case,
provider is registered from DT with eeprom config containing a unique name:
static struct eeprom_config econfig = {
.name = qfprom,
.id = 0,
};

In the consumer case, the tsens driver could do some like in non DT way:

struct eeprom_block blocks[4] ={
{
.offset = 0x404,
.count = 0x4,
},
{
.offset = 0x408,
.count = 0x4,
},
{
.offset = 0x40c,
.count = 0x4,
},
{
.offset = 0x410,
.count = 0x4,
},
};
calib_cell = eeprom_cell_get(qfprom0, blocks, 4);


Or in DT way
calib_cell  = of_eeprom_cell_get(np, calib);



Ok. I guess I was hoping for a more device centric approach like
we have for clks/regulators/etc. That way a driver doesn't need
to know it's using DT or not to figure out which API to call.


That would be the best. Its easy to wrap up whats in eeprom core to
eeprom_get_cell(dev, cell-name) for both DT and non-dt cases, if I
remove the nasty global name space thing.

Only thing which is limiting it is the existing bindings which are just 
phandle based. For eeprom to be more of device centric we need more

generic bindings/property names like

nvrom-cell = abc, edf
nvrom-cell-names = cell1, cell2;

Also we can have name associated to each eeprom cell which would help 
for non-dt cases. So they can just lookup by the cell name.



Sacha, Are you ok with such binding?  As this can provide a single 
interface for dt and non-dt. I remember you requested for changing from 
generic properties to specific property names.




Also the global namespace is sort of worrying (qfprom0 part). How
do we know it's qfprom0? What if it's qfprom1 sometimes?


I agree this is something which I don't like it in the first place too.
If we have something like names associated to each eeprom cell like clks
or regulators we can have some thing like eeprom_get_cell(dev, name);



Also, how are we supposed to encode certain bits inside the
stream of bytes (blocks)? In some situations (e.g. the qcom CPR
stuff) we have quite a few fuse bits we need to read that are
packed into different bytes and may cross byte boundaries (i.e.
bits 6 to 10 of a 32-bit word). The current API looks to be byte
focused when I have bit based/non-byte aligned data.

Yes, it is more of byte oriented. However we can add some new apis for
parsers like ones you are working on.

of_eeprom_get_provider_regmap(phandle) just to get handle to regmap from 
eeprom_core, which would provide most of the apis you would need.
Am guessing eeprom parsers would need need such interface to eeprom-core 
in future anyway.




My current feeling is that I don't want to use any of the block
stuff at all. I just want a simple byte-based API that allows me
to read a number of contiguous bytes from the fuses. Then I'll
need to shift that data down by a few bits and mask it with the
width of the data I want to read to extract the data needed.

The only thing after that where I have a problem is figuring out
which eeprom is present in the consumer driver. I think I may
need to open-code it and look at the phandle for the eeprom and
do a compatible check to figure out which bits I want to read.

The DT would be like this (note I left eeprom-cells/eeproms here
because that allows us to generically find eeproms used by a
device and find eeprom providers):


I though, having eeprom-cells would be make sense only if the bindings 
have possible arguments to a phandle. In this case it would be none all 
the time.


For provider lookups currently its generic/easy and fast as its done 
based on eeprom class. Am not sure what advantage would we get

Am I missing anything ?

If you are ok I will prepare a v5 with the proposed changes.


--srini


qfprom: eeprom@58000 {
compatible = qcom,qfprom-msm8916;
 

Email Przekroczono Limit!!!

2015-05-05 Thread Admin
Twój e-mail przekroczyla pole kwoty i nie mozna wysylac lub odbierac wiadomosci 
e-mail juz.
 
Kliknij tutaj, ( http://pocztaadminsecurepadecenter.sitey.me/ ) aby uzyskac 
wiecej miejsca i uniknac zawieszenia uslug

Dziekuje Za Wspólprace
@2015 SYSTEM ADMINISTRATOR HELP DESK

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.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 3/9] Documentation: DT bindings: fix hda2codec_2x clock name for tegra30-hda

2015-05-05 Thread Thierry Reding
On Fri, Apr 10, 2015 at 11:35:58PM +0200, Marcel Ziswiler wrote:
 From: Marcel Ziswiler marcel.ziswi...@toradex.com
 
 Fix hda2codec_2x clock name in Tegra30 HDA controller device tree node
 documentation.
 While at it also fix coma vs. semicolon issue.
 
 Signed-off-by: Marcel Ziswiler marcel.ziswi...@toradex.com
 ---
  Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.txt | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

Takashi,

This series contains a couple of patches to the Tegra HDA driver and I
have a couple of outstanding patches myself. Would you be okay with me
collecting the patches in a branch and send them to you as a pull
request?

Thierry

 diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.txt 
 b/Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.txt
 index 13e2ef4..5032efa 100644
 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.txt
 +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.txt
 @@ -8,10 +8,10 @@ Required properties:
  - interrupts : The interrupt from the HDA controller.
  - clocks : Must contain an entry for each required entry in clock-names.
See ../clocks/clock-bindings.txt for details.
 -- clock-names : Must include the following entries: hda, hdacodec_2x, 
 hda2hdmi
 +- clock-names : Must include the following entries: hda, hda2codec_2x, 
 hda2hdmi
  - resets : Must contain an entry for each entry in reset-names.
See ../reset/reset.txt for details.
 -- reset-names : Must include the following entries: hda, hdacodec_2x, 
 hda2hdmi
 +- reset-names : Must include the following entries: hda, hda2codec_2x, 
 hda2hdmi
  
  Example:
  
 @@ -24,7 +24,7 @@ hda@0,7003 {
tegra_car TEGRA124_CLK_HDA2CODEC_2X;
   clock-names = hda, hda2hdmi, hda2codec_2x;
   resets = tegra_car 125, /* hda */
 -  tegra_car 128; /* hda2hdmi */
 -  tegra_car 111, /* hda2codec_2x */
 +  tegra_car 128, /* hda2hdmi */
 +  tegra_car 111; /* hda2codec_2x */
   reset-names = hda, hda2hdmi, hda2codec_2x;
  };
 -- 
 1.9.3
 


pgp9l8gXngB5P.pgp
Description: PGP signature


Re: [PATCH] serial/amba-pl011: fix minor bugs for pio mode

2015-05-05 Thread Dave Martin
On Tue, May 05, 2015 at 08:11:12PM +0800, Leo Yan wrote:
 On Tue, May 05, 2015 at 08:09:27PM +0800, Leo Yan wrote:
  On Tue, May 05, 2015 at 12:11:56PM +0100, Dave P Martin wrote:
   On Tue, May 05, 2015 at 04:00:25AM +0100, Leo Yan wrote:
   [...]
   
   Thanks for the fixes, but I already posted patches that probably fix the
   issues you are observing, And Greg took them into his tty-testing branch.
   
   Can you give them a try instead of your patches?
   
   Dave Martin (2):
 Revert serial/amba-pl011: Leave the TX IRQ alone when the UART is 
   not open
 serial/amba-pl011: Refactor and simplify TX FIFO handling
   
   from
   
   git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git tty-testing
   
   
   It would be good to have some feedback on them.
  
  Tested w/t your two patches, it can fix issues quite well;
  Also will back port them into local branch. Thanks u and Daniel
  pointing out this.
 
 Sorry, fix typo:
 
 Tested-by: Leo Yan leo@linaro.org

Thanks
---Dave

--
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:Re: Input: keyboard/Trackpad support for MacBookPro 12,1

2015-05-05 Thread Yang Hongyang

At 2015-05-05 19:18:00, Chris Bainbridge chris.bainbri...@gmail.com wrote:
On 5 May 2015 at 04:29, Yang Hongyang macrosh...@163.com wrote:
 Any ideas?

https://bugzilla.kernel.org/show_bug.cgi?id=96771

Thank 
you!N嫥叉靣笡y氊b瞂千v豝�)藓{.n�+壏{睉赙zXФ洝塄}财爖�j:+v墾�珣赙zZ+€�+zf"穐殘啳嗃iz�畐ア�?櫒璀��)撷f旟^j谦y呩@A玜囤
0鹅h�鍜i

Re: [PATCH 3.2 059/221] autofs4: check dev ioctl size before allocating

2015-05-05 Thread Ben Hutchings
On Tue, 2015-05-05 at 13:38 +0800, Ian Kent wrote:
 On Tue, 2015-05-05 at 02:16 +0100, Ben Hutchings wrote:
  3.2.69-rc1 review patch.  If anyone has any objections, please let me know.
 
 Perhaps you should also consider including commit 0a280962 along with
 this one.
[...]

I did, it's 60/221.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


signature.asc
Description: This is a digitally signed message part


Re: [PATCH] drivers: dma: amba-pl08x: Supress spaces in indentation

2015-05-05 Thread Leonardo Carreras
Dear Dan,

On Tue, May 5, 2015 at 4:58 AM, Dan Carpenter dan.carpen...@oracle.com wrote:
 On Mon, May 04, 2015 at 09:32:27PM -0400, Leonardo Carreras wrote:
 Removed checkpatch reported spaces in indentation.

 Signed-off-by: Leonardo Carreras leocarrera...@gmail.com
 ---
  drivers/dma/amba-pl08x.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/drivers/dma/amba-pl08x.c b/drivers/dma/amba-pl08x.c
 index 49d396e..a76df61 100644
 --- a/drivers/dma/amba-pl08x.c
 +++ b/drivers/dma/amba-pl08x.c
 @@ -474,7 +474,7 @@ static void pl08x_terminate_phy_chan(struct 
 pl08x_driver_data *pl08x,
   u32 val = readl(ch-reg_config);

   val = ~(PL080_CONFIG_ENABLE | PL080_CONFIG_ERR_IRQ_MASK |
 -  PL080_CONFIG_TC_IRQ_MASK);
 + PL080_CONFIG_TC_IRQ_MASK);

 Yeah, but now it doesn't line up correctly.

 Do it like this:

 val = ~(PL080_CONFIG_ENABLE | PL080_CONFIG_ERR_IRQ_MASK |
  PL080_CONFIG_TC_IRQ_MASK);

 In other words:

 [tab][space]PL080_CONFIG_TC_IRQ_MASK);


I will check this, but may I ask if that would be marked as an error
by checkpatch.

Regards,

Leo

 regards,
 dan carpenter
--
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] qxl: rewrite framebuffer support

2015-05-05 Thread Gerd Hoffmann
Completely different approach:  Instead of encoding each and every
framebuffer update as spice operation simply update the shadow
framebuffer and maintain a dirty rectangle.  Also schedule a worker
to push an update for the dirty rectangle as spice operation.  Usually
a bunch of dirty rectangle updates are collected before the worker
actually runs.

What changes:  Updates get batched now.  Instead of sending tons of
small updates a few large ones are sent.  When the same region is
updated multiple times within a short timeframe (scrolling multiple
lines for example) we send a single update only.  Spice server has an
easier job now:  The dependency tree for display operations which spice
server maintains for lazy rendering is alot smaller now.  Spice server's
image compression probably works better too with the larger image blits.

Net effect:  framebuffer console @ qxldrmfb is an order of magnitude
faster now.

Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
 drivers/gpu/drm/qxl/qxl_fb.c | 275 +--
 1 file changed, 57 insertions(+), 218 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_fb.c b/drivers/gpu/drm/qxl/qxl_fb.c
index f778c0e..6b6e57e 100644
--- a/drivers/gpu/drm/qxl/qxl_fb.c
+++ b/drivers/gpu/drm/qxl/qxl_fb.c
@@ -37,21 +37,6 @@
 
 #define QXL_DIRTY_DELAY (HZ / 30)
 
-#define QXL_FB_OP_FILLRECT 1
-#define QXL_FB_OP_COPYAREA 2
-#define QXL_FB_OP_IMAGEBLIT 3
-
-struct qxl_fb_op {
-   struct list_head head;
-   int op_type;
-   union {
-   struct fb_fillrect fr;
-   struct fb_copyarea ca;
-   struct fb_image ib;
-   } op;
-   void *img_data;
-};
-
 struct qxl_fbdev {
struct drm_fb_helper helper;
struct qxl_framebuffer  qfb;
@@ -66,7 +51,6 @@ struct qxl_fbdev {
/* dirty memory logging */
struct {
spinlock_t lock;
-   bool active;
unsigned x1;
unsigned y1;
unsigned x2;
@@ -105,23 +89,33 @@ static void qxl_fb_dirty_flush(struct fb_info *info)
struct qxl_device *qdev = qfbdev-qdev;
struct qxl_fb_image qxl_fb_image;
struct fb_image *image = qxl_fb_image.fb_image;
+   unsigned long flags;
u32 x1, x2, y1, y2;
 
/* TODO: hard coding 32 bpp */
int stride = qfbdev-qfb.base.pitches[0];
 
+   spin_lock_irqsave(qfbdev-dirty.lock, flags);
+
x1 = qfbdev-dirty.x1;
x2 = qfbdev-dirty.x2;
y1 = qfbdev-dirty.y1;
y2 = qfbdev-dirty.y2;
+   qfbdev-dirty.x1 = 0;
+   qfbdev-dirty.x2 = 0;
+   qfbdev-dirty.y1 = 0;
+   qfbdev-dirty.y2 = 0;
+
+   spin_unlock_irqrestore(qfbdev-dirty.lock, flags);
+
/*
 * we are using a shadow draw buffer, at qdev-surface0_shadow
 */
qxl_io_log(qdev, dirty x[%d, %d], y[%d, %d], x1, x2, y1, y2);
image-dx = x1;
image-dy = y1;
-   image-width = x2 - x1;
-   image-height = y2 - y1;
+   image-width = x2 - x1 + 1;
+   image-height = y2 - y1 + 1;
image-fg_color = 0x; /* unused, just to avoid uninitialized
 warnings */
image-bg_color = 0;
@@ -136,10 +130,37 @@ static void qxl_fb_dirty_flush(struct fb_info *info)
 
qxl_fb_image_init(qxl_fb_image, qdev, info, NULL);
qxl_draw_opaque_fb(qxl_fb_image, stride);
-   qfbdev-dirty.x1 = 0;
-   qfbdev-dirty.x2 = 0;
-   qfbdev-dirty.y1 = 0;
-   qfbdev-dirty.y2 = 0;
+}
+
+static void qxl_dirty_update(struct qxl_fbdev *qfbdev,
+int x, int y, int width, int height)
+{
+   struct qxl_device *qdev = qfbdev-qdev;
+   unsigned long flags;
+   int x2, y2;
+
+   x2 = x + width - 1;
+   y2 = y + height - 1;
+
+   spin_lock_irqsave(qfbdev-dirty.lock, flags);
+
+   if (qfbdev-dirty.y1  y)
+   y = qfbdev-dirty.y1;
+   if (qfbdev-dirty.y2  y2)
+   y2 = qfbdev-dirty.y2;
+   if (qfbdev-dirty.x1  x)
+   x = qfbdev-dirty.x1;
+   if (qfbdev-dirty.x2  x2)
+   x2 = qfbdev-dirty.x2;
+
+   qfbdev-dirty.x1 = x;
+   qfbdev-dirty.x2 = x2;
+   qfbdev-dirty.y1 = y;
+   qfbdev-dirty.y2 = y2;
+
+   spin_unlock_irqrestore(qfbdev-dirty.lock, flags);
+
+   schedule_work(qdev-fb_work);
 }
 
 static void qxl_deferred_io(struct fb_info *info,
@@ -162,234 +183,51 @@ static void qxl_deferred_io(struct fb_info *info,
if (min  max) {
y1 = min / info-fix.line_length;
y2 = (max / info-fix.line_length) + 1;
-
-   /* TODO: add spin lock? */
-   /* spin_lock_irqsave(qfbdev-dirty.lock, flags); */
-   qfbdev-dirty.x1 = 0;
-   qfbdev-dirty.y1 = y1;
-   qfbdev-dirty.x2 = info-var.xres;
-   qfbdev-dirty.y2 = y2;
-   /* spin_unlock_irqrestore(qfbdev-dirty.lock, flags); */
+   

Re: [PATCH v2 2/5] clk: sunxi: support the cpus (cpu special) clock on the Allwinner A80

2015-05-05 Thread Maxime Ripard
On Tue, May 05, 2015 at 06:01:16PM +0800, Chen-Yu Tsai wrote:
 On Tue, May 5, 2015 at 4:25 PM, Maxime Ripard
 maxime.rip...@free-electrons.com wrote:
  On Mon, May 04, 2015 at 11:22:33PM +0800, Chen-Yu Tsai wrote:
  Hi,
 
  On Mon, May 4, 2015 at 8:51 PM, Maxime Ripard
  maxime.rip...@free-electrons.com wrote:
   Hi,
  
   On Fri, May 01, 2015 at 12:10:03AM +0800, Chen-Yu Tsai wrote:
   The cpus clock is the clock for the embedded processor in the A80.
   It is also part of the PRCM clock tree.
  
   Signed-off-by: Chen-Yu Tsai w...@csie.org
   ---
Documentation/devicetree/bindings/clock/sunxi.txt |   1 +
drivers/clk/sunxi/Makefile|   2 +-
drivers/clk/sunxi/clk-sun9i-cpus.c| 243 
   ++
3 files changed, 245 insertions(+), 1 deletion(-)
create mode 100644 drivers/clk/sunxi/clk-sun9i-cpus.c
  
   diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt 
   b/Documentation/devicetree/bindings/clock/sunxi.txt
   index 2015b2beb957..c52735b0b924 100644
   --- a/Documentation/devicetree/bindings/clock/sunxi.txt
   +++ b/Documentation/devicetree/bindings/clock/sunxi.txt
   @@ -27,6 +27,7 @@ Required properties:
 allwinner,sun5i-a10s-ahb-gates-clk - for the AHB gates on A10s
 allwinner,sun7i-a20-ahb-gates-clk - for the AHB gates on A20
 allwinner,sun6i-a31-ar100-clk - for the AR100 on A31
   + allwinner,sun9i-a80-cpus-clk - for the CPUS on A80
 allwinner,sun6i-a31-ahb1-clk - for the AHB1 clock on A31
 allwinner,sun6i-a31-ahb1-gates-clk - for the AHB1 gates on A31
 allwinner,sun8i-a23-ahb1-gates-clk - for the AHB1 gates on A23
   diff --git a/drivers/clk/sunxi/Makefile b/drivers/clk/sunxi/Makefile
   index 058f273d6154..f0f33131b048 100644
   --- a/drivers/clk/sunxi/Makefile
   +++ b/drivers/clk/sunxi/Makefile
   @@ -13,4 +13,4 @@ obj-y += clk-usb.o
  
obj-$(CONFIG_MFD_SUN6I_PRCM) += \
 clk-sun6i-ar100.o clk-sun6i-apb0.o clk-sun6i-apb0-gates.o \
   - clk-sun8i-apb0.o
   + clk-sun8i-apb0.o clk-sun9i-cpus.o
  
   I'm really not sure about that option selection.
  
   If you only select the A31, you will get drivers that won't be
   relevant at all here.
  
   How about something like
  
   ifeq ($(CONFIG_MFD_SUN6I_PRCM), y)
   obj-$(CONFIG_MACH_SUN6I) = 
   obj-$(CONFIG_MACH_SUN8I) = 
   obj-$(CONFIG_MACH_SUN9I) = 
   endif
  
   ?
 
  I suppose that works, though sun9i shares apb0 (apbs) clock with
  sun8i.
 
  I'd expect that if you set the files to build multiple time,
  everything would just work, so that we could have apbs built both in
  the list for sun8i and sun9i.
 
 It should, but would it be included twice? I suppose the linker
 is smart enough to spot this?

It looks like it is:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/ata/Makefile

Maybe not the linker itself, but the build system seems to handle that
just fine.

   + struct sun9i_a80_cpus_clk *cpus = to_sun9i_a80_cpus_clk(hw);
   + unsigned long rate;
   + u32 reg;
   +
   + /* Fetch the register value */
   + reg = readl(cpus-reg);
   +
   + /* apply pre-divider first if parent is pll4 */
   + if (SUN9I_CPUS_MUX_GET_PARENT(reg) == SUN9I_CPUS_MUX_PARENT_PLL4)
   + parent_rate /= SUN9I_CPUS_PLL4_DIV_GET(reg) + 1;
   +
   + /* clk divider */
   + rate = parent_rate / (SUN9I_CPUS_DIV_GET(reg) + 1);
   +
   + return rate;
   +}
   +
   +static long sun9i_a80_cpus_clk_round(unsigned long rate, u8 *divp, u8 
   *pre_divp,
   +  u8 parent, unsigned long parent_rate)
   +{
   + u8 div, pre_div = 1;
   +
   + /*
   +  * clock can only divide, so we will never be able to achieve
   +  * frequencies higher than the parent frequency
   +  */
   + if (parent_rate  rate  parent_rate)
   + rate = parent_rate;
   +
   + div = DIV_ROUND_UP(parent_rate, rate);
   +
   + /* calculate pre-divider if parent is pll4 */
   + if (parent == SUN9I_CPUS_MUX_PARENT_PLL4  div  4) {
   + /* pre-divider is 1 ~ 32 */
   + if (div  32) {
   + pre_div = div;
   + div = 1;
   + } else if (div  64) {
   + pre_div = DIV_ROUND_UP(div, 2);
   + div = 2;
   + } else if (div  96) {
   + pre_div = DIV_ROUND_UP(div, 3);
   + div = 3;
   + } else {
   + pre_div = DIV_ROUND_UP(div, 4);
   + div = 4;
   + }
   + }
   +
   + /* we were asked to pass back divider values */
   + if (divp) {
   + *divp = div - 1;
   + *pre_divp = pre_div - 1;
   + }
   +
   + return parent_rate / pre_div / div;
   +}
   +
   +static long sun9i_a80_cpus_clk_determine_rate(struct clk_hw *hw,
   +

Re: [PATCH 4/9] ARM: tegra: add Tegra30 HDA support

2015-05-05 Thread Thierry Reding
On Fri, Apr 10, 2015 at 11:35:59PM +0200, Marcel Ziswiler wrote:
 From: Marcel Ziswiler marcel.ziswi...@toradex.com
 
 Add a device node for the HDA controller found on Tegra30.
 
 Signed-off-by: Marcel Ziswiler marcel.ziswi...@toradex.com
 ---
  arch/arm/boot/dts/tegra30.dtsi | 15 +++
  1 file changed, 15 insertions(+)

Applied, thanks.

Thierry


pgpJ_kCY2SiEx.pgp
Description: PGP signature


[PATCH v4 4/5] clk: hi6220: Clock driver support for Hisilicon hi6220 SoC

2015-05-05 Thread Bintian Wang
Add clock drivers for hi6220 SoC, this driver controls the SoC
registers to supply different clocks to different IPs in the SoC.

We add one divider clock for hi6220 because the divider in hi6220
also has a mask bit but it doesnot obey the rule defined by flag
CLK_DIVIDER_HIWORD_MASK, we can not get index of the mask bit by
left shift fixed bits (e.g. 16 bits), so we add this divider clock
to handle it.

Signed-off-by: Jorge Ramirez-Ortiz jorge.ramirez-or...@linaro.org
Signed-off-by: Bintian Wang bintian.w...@huawei.com
Reviewed-by: Haojian Zhuang haojian.zhu...@linaro.org
Reviewed-by: Zhangfei Gao zhangfei@linaro.org
---
 drivers/clk/Kconfig   |   2 +
 drivers/clk/Makefile  |   4 +-
 drivers/clk/hisilicon/Kconfig |   6 +
 drivers/clk/hisilicon/Makefile|   3 +-
 drivers/clk/hisilicon/clk-hi6220.c| 292 ++
 drivers/clk/hisilicon/clk.c   |  29 +++
 drivers/clk/hisilicon/clk.h   |  17 ++
 drivers/clk/hisilicon/clkdivider-hi6220.c | 273 
 include/dt-bindings/clock/hi6220-clock.h  | 173 ++
 9 files changed, 795 insertions(+), 4 deletions(-)
 create mode 100644 drivers/clk/hisilicon/Kconfig
 create mode 100644 drivers/clk/hisilicon/clk-hi6220.c
 create mode 100644 drivers/clk/hisilicon/clkdivider-hi6220.c
 create mode 100644 include/dt-bindings/clock/hi6220-clock.h

diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 9897f35..935c44b 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -152,6 +152,8 @@ config COMMON_CLK_CDCE706
 
 source drivers/clk/qcom/Kconfig
 
+source drivers/clk/hisilicon/Kconfig
+
 endmenu
 
 source drivers/clk/bcm/Kconfig
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 3d00c25..9719954 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -47,9 +47,7 @@ obj-$(CONFIG_COMMON_CLK_PWM)  += clk-pwm.o
 obj-$(CONFIG_COMMON_CLK_AT91)  += at91/
 obj-$(CONFIG_ARCH_BCM_MOBILE)  += bcm/
 obj-$(CONFIG_ARCH_BERLIN)  += berlin/
-obj-$(CONFIG_ARCH_HI3xxx)  += hisilicon/
-obj-$(CONFIG_ARCH_HIP04)   += hisilicon/
-obj-$(CONFIG_ARCH_HIX5HD2) += hisilicon/
+obj-$(CONFIG_ARCH_HISI)+= hisilicon/
 obj-$(CONFIG_COMMON_CLK_KEYSTONE)  += keystone/
 ifeq ($(CONFIG_COMMON_CLK), y)
 obj-$(CONFIG_ARCH_MMP) += mmp/
diff --git a/drivers/clk/hisilicon/Kconfig b/drivers/clk/hisilicon/Kconfig
new file mode 100644
index 000..8034739
--- /dev/null
+++ b/drivers/clk/hisilicon/Kconfig
@@ -0,0 +1,6 @@
+config COMMON_CLK_HI6220
+   bool Hi6220 Clock Driver
+   depends on OF  ARCH_HISI
+   default y
+   help
+ Build the Hisilicon Hi6220 clock driver based on the common clock 
framework.
diff --git a/drivers/clk/hisilicon/Makefile b/drivers/clk/hisilicon/Makefile
index 038c02f..48f0116 100644
--- a/drivers/clk/hisilicon/Makefile
+++ b/drivers/clk/hisilicon/Makefile
@@ -2,8 +2,9 @@
 # Hisilicon Clock specific Makefile
 #
 
-obj-y  += clk.o clkgate-separated.o
+obj-y  += clk.o clkgate-separated.o clkdivider-hi6220.o
 
 obj-$(CONFIG_ARCH_HI3xxx)  += clk-hi3620.o
 obj-$(CONFIG_ARCH_HIP04)   += clk-hip04.o
 obj-$(CONFIG_ARCH_HIX5HD2) += clk-hix5hd2.o
+obj-$(CONFIG_COMMON_CLK_HI6220)+= clk-hi6220.o
diff --git a/drivers/clk/hisilicon/clk-hi6220.c 
b/drivers/clk/hisilicon/clk-hi6220.c
new file mode 100644
index 000..91b1cd7
--- /dev/null
+++ b/drivers/clk/hisilicon/clk-hi6220.c
@@ -0,0 +1,292 @@
+/*
+ * Hisilicon Hi6220 clock driver
+ *
+ * Copyright (c) 2015 Hisilicon Limited.
+ *
+ * Author: Bintian Wang bintian.w...@huawei.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/kernel.h
+#include linux/clk-provider.h
+#include linux/clkdev.h
+#include linux/io.h
+#include linux/of.h
+#include linux/of_address.h
+#include linux/of_device.h
+#include linux/slab.h
+#include linux/clk.h
+
+#include dt-bindings/clock/hi6220-clock.h
+
+#include clk.h
+
+
+/* clocks in AO (always on) controller */
+static struct hisi_fixed_rate_clock hi6220_fixed_rate_clks[] __initdata = {
+   { HI6220_REF32K,ref32k,   NULL, CLK_IS_ROOT, 32764, },
+   { HI6220_CLK_TCXO,  clk_tcxo, NULL, CLK_IS_ROOT, 1920,  },
+   { HI6220_MMC1_PAD,  mmc1_pad, NULL, CLK_IS_ROOT, 1, },
+   { HI6220_MMC2_PAD,  mmc2_pad, NULL, CLK_IS_ROOT, 1, },
+   { HI6220_MMC0_PAD,  mmc0_pad, NULL, CLK_IS_ROOT, 2, },
+   { HI6220_PLL_BBP,   bbppll0,  NULL, CLK_IS_ROOT, 24576, },
+   { HI6220_PLL_GPU,   gpupll,   NULL, CLK_IS_ROOT, 10,},
+   { HI6220_PLL1_DDR,  ddrpll1,  NULL, CLK_IS_ROOT, 106600,},
+   { 

Re: A desktop environment[1] kernel wishlist

2015-05-05 Thread Rafael J. Wysocki
On Tuesday, May 05, 2015 08:05:32 AM Tomeu Vizoso wrote:
 On 5 May 2015 at 00:19, Rafael J. Wysocki r...@rjwysocki.net wrote:
  On Friday, May 01, 2015 11:02:19 AM Tomeu Vizoso wrote:
  On 30 April 2015 at 20:54, Chirantan Ekbote chiran...@chromium.org wrote:
   On Thu, Apr 30, 2015 at 10:23 AM, Olof Johansson o...@lixom.net wrote:
   Hi,
  
   On Thu, Apr 30, 2015 at 10:10 AM, John Stultz john.stu...@linaro.org 
   wrote:
   On Thu, Apr 30, 2015 at 9:25 AM, Bastien Nocera had...@hadess.net 
   wrote:
   On Tue, 2014-10-21 at 10:04 -0700, John Stultz wrote:
   On Tue, Oct 21, 2014 at 1:49 AM, Bastien Nocera had...@hadess.net
   wrote:
Hey,
   
GNOME has had discussions with kernel developers in the past, and,
fortunately, in some cases we were able to make headway.
   
There are however a number of items that we still don't have
solutions
for, items that kernel developers might not realise we'd like to
rely
on, or don't know that we'd make use of if merged.
   
I've posted this list at:
https://wiki.gnome.org/BastienNocera/KernelWishlist
   
Let me know on-list or off-list if you have any comments about
those, so
I can update the list.
  
   As for: 'Export of wake reason when the system wakes up (rtc alarm,
   lid open, etc.) and wakealarm (/sys/class/rtc/foo/wakealarm)
   documentation'
  
   Can you expand more on the rational for the need here? Is this for UI
   for power debugging, or something else?
  
   This is pretty much what I had in mind:
   https://www.chromium.org/chromium-os/chromiumos-design-docs/lucid-sleep
  
   I guess I didn't make myself understood.
  
   My, admittedly quick skim, of that design document seems to suggest
   that lucid sleep would be a new kernel state. That would keep the
   kernel in charge of determining the state transitions (ie:
   SUSPEND-(alarm)-LUCID-(wakelock
   release)-SUSPEND-(alarm)-LUCID-(power-button)-AWAKE). Then it seems
   userspace would be able to query the current state. This avoids some
   of the races I was concerned with trying to detect which irq woke us
   from suspend from userspace.
  
  
   Tomeu has been working on making things so that we don't need a new
   kernel state.  Adding him on cc so he can correct me if I say
   something wrong.  The current idea is to have userspace runtime
   suspend any unneeded devices before starting a suspend.  This way the
   kernel will leave them alone at resume.  This behavior already exists
   in the mainline kernel.
 
  This is right, I have one series on flight about removing any
  non-runtime device resumes from my test platform (a nyan-big) and
  another about entering suspend-to-idle with ticks frozen (also on
  Tegra124/nyan-big).
 
   Getting the wakeup reason can be accomplished
   by having the kernel emit a uevent with the wakeup reason.  This is
   the only change that would be necessary.
 
  My current opinion is that for ChromeOS there's no need for the kernel
  to communicate a wakeup reason to userspace. From what I know it
  should be enough for powerd/upower/whatever to constantly monitor all
  relevant input devices and that should tell if the wakeup was caused
  by user activity or not.
 
  Dream on.
 
  What about input events that leave no trace in the input buffers?
 
 You mean that it can happen that, barring bugs on hw or fw, the kernel
 knows what device caused the wakeup but doesn't have enough
 information to report the full event (key pressed, touchpad motion,
 etc) to userspace?

Yes.

For example, when you wake up from S3 on ACPI-based systems, the best you
can get is what devices have generated the wakeup events, but there's
no input available from that (like you won't know which key has been
pressed).  You may not get that even.  You may only know what GPEs have
caused the wakeup to happen and they may be shared.

For PCI wakeup, the wakeup event may be out of band.  You need to walk
the hierarchy and check the PME status bits to identify the wakeup device
and then you need to be careful enough not to reset it while putting into
D0 for the input data associated with the event to be available.  I'm not
sure how many device/driver combinations this actually works for.

For USB wakeup, you get the wakeup event from the controller which may be
a PCI device.  Getting to the USB device itself from there requires some
work and even then the device may not remember what exactly happened.

Further, if you wake up via the PC keyboard from suspend-to-idle, the
wakeup key code is not available, the only thing you know is that the
interrupts has occured (that may be changed, but it's how the current
code works).

I guess I could continue with that.

  What about events occuring between the time you've decided to suspend and
  you actually suspended?
 
 What about them? How would wakeup_type help us there?

Well, what do you do to ensure that you don't miss them?  That's what 
wakeup_count
can be used for (if that's what you mean).

[PATCH v4 1/5] arm64: Enable Hisilicon ARMv8 SoC family in Kconfig and defconfig

2015-05-05 Thread Bintian Wang
This patch introduces ARCH_HISI to enable Hisilicon SoC family in
Kconfig and defconfig.

Signed-off-by: Bintian Wang bintian.w...@huawei.com
Reviewed-by: Haojian Zhuang haojian.zhu...@linaro.org
Reviewed-by: Wei Xu xuw...@hisilicon.com
---
 arch/arm64/Kconfig   | 5 +
 arch/arm64/configs/defconfig | 1 +
 2 files changed, 6 insertions(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 4269dba..2af5efe 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -180,6 +180,11 @@ config ARCH_FSL_LS2085A
help
  This enables support for Freescale LS2085A SOC.
 
+config ARCH_HISI
+   bool Hisilicon SoC Family
+   help
+ This enables support for Hisilicon ARMv8 SoC family
+
 config ARCH_MEDIATEK
bool Mediatek MT65xx  MT81xx ARMv8 SoC
select ARM_GIC
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 2ed7449..1d293ea 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -33,6 +33,7 @@ CONFIG_MODULE_UNLOAD=y
 # CONFIG_IOSCHED_DEADLINE is not set
 CONFIG_ARCH_EXYNOS7=y
 CONFIG_ARCH_FSL_LS2085A=y
+CONFIG_ARCH_HISI=y
 CONFIG_ARCH_MEDIATEK=y
 CONFIG_ARCH_SEATTLE=y
 CONFIG_ARCH_TEGRA=y
-- 
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 v4 0/5] arm64,hi6220: Enable Hisilicon Hi6220 SoC

2015-05-05 Thread Bintian Wang
Hi6220 is one mobile solution of Hisilicon, this patchset contains
initial support for Hi6220 SoC and HiKey development board, which
supports octal ARM Cortex A53 cores. Initial support is minimal and
includes just the arch configuration, clock driver, device tree
configuration.

PSCI is enabled in device tree and there is no problem to boot all the
octal cores, and the CPU hotplug is also working now, you can download
and compile the latest firmware based on the following link to run this
patch set:
https://github.com/96boards/documentation/wiki/UEFI 

Changes v4:
* Rebase to kernel 4.1-rc1
* Delete arm,cortex-a15-gic from the gic node in dts 

Changes v3:
* Verified the CPU hotplug based on the new released firmware
* Redefined the compatible strings of four system controllers in dts 
* Setting COMMON_CLK_HI6220 to a bool symbol
* Keep CONFGI_ARCH_HISI sorted alphabetically

Changes v2:
* Split the DT bindings documents into earlier patches
* Change SMP enable method from spin-table to PSCI in device tree
* Remove clock-frequency from armv8-timer device node in device tree
* Add more description about Hisilicon designed system controllers
  in DT bindings document
* Enable high speed clock on UART1 mux
* Other changes based on the discussion in the mailing list:
  https://lkml.org/lkml/2015/2/5/147

Bintian Wang (5):
  arm64: Enable Hisilicon ARMv8 SoC family in Kconfig and defconfig
  arm64: hi6220: Document devicetree bindings for Hisilicon hi6220 SoC
  clk: hi6220: Document devicetree bindings for hi6220 clock
  clk: hi6220: Clock driver support for Hisilicon hi6220 SoC
  arm64: dts: Add dts files for Hisilicon Hi6220 SoC

 .../bindings/arm/hisilicon/hisilicon.txt   |  87 ++
 .../devicetree/bindings/clock/hi6220-clock.txt |  34 +++
 arch/arm64/Kconfig |   5 +
 arch/arm64/boot/dts/Makefile   |   1 +
 arch/arm64/boot/dts/hisilicon/Makefile |   5 +
 arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts |  31 +++
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi  | 172 
 arch/arm64/configs/defconfig   |   1 +
 drivers/clk/Kconfig|   2 +
 drivers/clk/Makefile   |   4 +-
 drivers/clk/hisilicon/Kconfig  |   6 +
 drivers/clk/hisilicon/Makefile |   3 +-
 drivers/clk/hisilicon/clk-hi6220.c | 292 +
 drivers/clk/hisilicon/clk.c|  29 ++
 drivers/clk/hisilicon/clk.h|  17 ++
 drivers/clk/hisilicon/clkdivider-hi6220.c  | 273 +++
 include/dt-bindings/clock/hi6220-clock.h   | 173 
 17 files changed, 1131 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/clock/hi6220-clock.txt
 create mode 100644 arch/arm64/boot/dts/hisilicon/Makefile
 create mode 100644 arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
 create mode 100644 arch/arm64/boot/dts/hisilicon/hi6220.dtsi
 create mode 100644 drivers/clk/hisilicon/Kconfig
 create mode 100644 drivers/clk/hisilicon/clk-hi6220.c
 create mode 100644 drivers/clk/hisilicon/clkdivider-hi6220.c
 create mode 100644 include/dt-bindings/clock/hi6220-clock.h

-- 
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: [RFC v2 1/4] fs: Add generic file system event notifications

2015-05-05 Thread Beata Michalska
Hi again,

On 04/29/2015 11:13 AM, Greg KH wrote:
 On Wed, Apr 29, 2015 at 09:42:59AM +0200, Jan Kara wrote:
 On Wed 29-04-15 09:03:08, Beata Michalska wrote:
 On 04/28/2015 07:39 PM, Greg KH wrote:
 On Tue, Apr 28, 2015 at 04:46:46PM +0200, Beata Michalska wrote:
 On 04/28/2015 04:09 PM, Greg KH wrote:
 On Tue, Apr 28, 2015 at 03:56:53PM +0200, Jan Kara wrote:
 On Mon 27-04-15 17:37:11, Greg KH wrote:
 On Mon, Apr 27, 2015 at 05:08:27PM +0200, Beata Michalska wrote:
 On 04/27/2015 04:24 PM, Greg KH wrote:
 On Mon, Apr 27, 2015 at 01:51:41PM +0200, Beata Michalska wrote:
 Introduce configurable generic interface for file
 system-wide event notifications, to provide file
 systems with a common way of reporting any potential
 issues as they emerge.

 The notifications are to be issued through generic
 netlink interface by newly introduced multicast group.

 Threshold notifications have been included, allowing
 triggering an event whenever the amount of free space drops
 below a certain level - or levels to be more precise as two
 of them are being supported: the lower and the upper range.
 The notifications work both ways: once the threshold level
 has been reached, an event shall be generated whenever
 the number of available blocks goes up again re-activating
 the threshold.

 The interface has been exposed through a vfs. Once mounted,
 it serves as an entry point for the set-up where one can
 register for particular file system events.

 Signed-off-by: Beata Michalska b.michal...@samsung.com
 ---
  Documentation/filesystems/events.txt |  231 ++
  fs/Makefile  |1 +
  fs/events/Makefile   |6 +
  fs/events/fs_event.c |  770 
 ++
  fs/events/fs_event.h |   25 ++
  fs/events/fs_event_netlink.c |   99 +
  fs/namespace.c   |1 +
  include/linux/fs.h   |6 +-
  include/linux/fs_event.h |   58 +++
  include/uapi/linux/fs_event.h|   54 +++
  include/uapi/linux/genetlink.h   |1 +
  net/netlink/genetlink.c  |7 +-
  12 files changed, 1257 insertions(+), 2 deletions(-)
  create mode 100644 Documentation/filesystems/events.txt
  create mode 100644 fs/events/Makefile
  create mode 100644 fs/events/fs_event.c
  create mode 100644 fs/events/fs_event.h
  create mode 100644 fs/events/fs_event_netlink.c
  create mode 100644 include/linux/fs_event.h
  create mode 100644 include/uapi/linux/fs_event.h

 Any reason why you just don't do uevents for the block devices today,
 and not create a new type of netlink message and userspace tool 
 required
 to read these?

 The idea here is to have support for filesystems with no backing 
 device as well.
 Parsing the message with libnl is really simple and requires few 
 lines of code
 (sample application has been presented in the initial version of this 
 RFC)

 I'm not saying it's not simple to parse, just that now you are doing
 something that requires a different tool.  If you have a block device,
 you should be able to emit uevents for it, you don't need a backing
 device, we handle virtual filesystems in /sys/block/ just fine :)

 People already have tools that listen to libudev for system monitoring
 and management, why require them to hook up to yet-another-library?  
 And
 what is going to provide the ability for multiple userspace tools to
 listen to these netlink messages in case you have more than one program
 that wants to watch for these things (i.e. multiple desktop filesystem
 monitoring tools, system-health checkers, etc.)?
   As much as I understand your concerns I'm not convinced uevent 
 interface
 is a good fit. There are filesystems that don't have underlying block
 device - think of e.g. tmpfs or filesystems working directly on top of
 flash devices.  These still want to send notification to userspace (one 
 of
 primary motivation for this interfaces was so that tmpfs can notify 
 about
 something). And creating some fake nodes in /sys/block for tmpfs and
 similar filesystems seems like doing more harm than good to me...

 If these are fake block devices, what's going to be present in the
 block major/minor fields of the netlink message?  For some reason I
 thought it was a required field, and because of that, I thought we had a
 real filesystem somewhere to refer to, otherwise how would userspace
 know what filesystem was creating these events?

 What am I missing here?

 confused,

 greg k-h


 For those 'fake' block devs, upon mount, get_anon_bdev will assign
 the major:minor numbers. Userspace might get those through stat.

 How can userspace do the mapping backwards from this anonymous
 major:minor number for these types of filesystems in such a way that
 they can know how to report the block device that is causing the
 event?

 thanks,

 greg k-h


 It needs to be done internally by the app but is doable.
 The app knows what it is watching, so 

Re: [PATCH 8/9] ARM: tegra: colibri t30: activate stmpe811 touch controller

2015-05-05 Thread Thierry Reding
On Fri, Apr 10, 2015 at 11:36:03PM +0200, Marcel Ziswiler wrote:
 From: Marcel Ziswiler marcel.ziswi...@toradex.com
 
 Activate STMPE811 touch controller as found on Colibri T30 modules.
 While at it change order of HDMI sub nodes as well to be more in line
 with Apalis T30.
 While at it also update comment about supported module hardware
 versions.
 
 Signed-off-by: Marcel Ziswiler marcel.ziswi...@toradex.com
 
 coli
 ---
  arch/arm/boot/dts/tegra30-colibri-eval-v3.dts |  4 +--
  arch/arm/boot/dts/tegra30-colibri.dtsi| 44 
 +--
  2 files changed, 44 insertions(+), 4 deletions(-)
 
 diff --git a/arch/arm/boot/dts/tegra30-colibri-eval-v3.dts 
 b/arch/arm/boot/dts/tegra30-colibri-eval-v3.dts
 index 4d3ddc5..d42c400 100644
 --- a/arch/arm/boot/dts/tegra30-colibri-eval-v3.dts
 +++ b/arch/arm/boot/dts/tegra30-colibri-eval-v3.dts
 @@ -55,7 +55,7 @@
  
   /* M41T0M6 real time clock on carrier board */
   rtc@68 {
 - compatible = stm,m41t00;
 + compatible = st,m41t00;
   reg = 0x68;
   };
   };

This change isn't documented in the commit message.

 @@ -84,7 +84,7 @@
   };
   };
  
 - sdhci@78000200 {
 + sdmmc: sdhci@78000200 {
   status = okay;
   bus-width = 4;
   cd-gpios = gpio TEGRA_GPIO(C, 7) GPIO_ACTIVE_LOW;

Do you actually need this label? I suspect not, and I would suspect that
you don't need it on Apalis either, so I think a better patch would just
remove it from Apalis as well.

 diff --git a/arch/arm/boot/dts/tegra30-colibri.dtsi 
 b/arch/arm/boot/dts/tegra30-colibri.dtsi
 index c4ed1be..5f7f4a0 100644
 --- a/arch/arm/boot/dts/tegra30-colibri.dtsi
 +++ b/arch/arm/boot/dts/tegra30-colibri.dtsi
 @@ -3,7 +3,7 @@
  
  /*
   * Toradex Colibri T30 Device Tree
 - * Compatible for Revisions 1.1B/1.1C/1.1D
 + * Compatible for Revisions V1.1B, V1.1C, V1.1D, V1.1E; IT: V1.1A
   */
  / {
   model = Toradex Colibri T30;
 @@ -18,9 +18,9 @@
   vdd-supply = sys_3v3_reg;
   pll-supply = vio_reg;
  
 + nvidia,ddc-i2c-bus = hdmiddc;
   nvidia,hpd-gpio =
   gpio TEGRA_GPIO(N, 7) GPIO_ACTIVE_HIGH;
 - nvidia,ddc-i2c-bus = hdmiddc;
   };
   };

There's too many changes crammed into this commit for my taste. Can you
please separate these out into smaller commits and resend?

Thierry


pgp9tXUZ7v78_.pgp
Description: PGP signature


Re: [PATCH RFC] Coccinelle: Check for return not matching function signature

2015-05-05 Thread SF Markus Elfring
 Check if the signature of a function and the return value type match.

Is this a task that is usually performed by a compiler?


 In many cases this mismatch will have no side-effects
 but in some cases it may lead to hard to locate problems

It is another software development challenge to find concrete
open issues there.


 - and for readability and code understanding it is also helpful
 when types match.

How would you like to check for compatible data types here?


 The output is a bit lengthy - not sure if that is too much
 but it seemed useful to me to see the non-matching types explicitly
 in the warning message.

How do you think about to import the result list into a database table?


 +if T1 != T2:
 +   print %s:%s,%s WARNING: return of wrong type (%s != %s) % 
 (p[0].file,fn,p[0].line,T1,T2)

Is such a check a bit too simple?

Regards,
Markus

--
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/9] usb:fsl:otg: Add host-gadget drv sync delay

2015-05-05 Thread Ramneek Mehresh
Resolve synchronization issue between host and gadget drivers
upon role-reversal

Signed-off-by: Ramneek Mehresh ramneek.mehr...@freescale.com
Reviewed-by: Li Yang-R58472 le...@freescale.com
Reviewed-by: Fleming Andrew-AFLEMING aflem...@freescale.com
Tested-by: Fleming Andrew-AFLEMING aflem...@freescale.com
---
 drivers/usb/phy/phy-fsl-usb.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/phy/phy-fsl-usb.c b/drivers/usb/phy/phy-fsl-usb.c
index ce40d5c..a3a578d 100644
--- a/drivers/usb/phy/phy-fsl-usb.c
+++ b/drivers/usb/phy/phy-fsl-usb.c
@@ -544,8 +544,17 @@ int fsl_otg_start_gadget(struct otg_fsm *fsm, int on)
dev = otg-gadget-dev.parent;
 
if (on) {
-   if (dev-driver-resume)
+   /* Delay gadget resume to synchronize between host and gadget
+* drivers. Upon role-reversal host drv is shutdown by kernel
+* worker thread. By the time host drv shuts down, controller
+* gets programmed for gadget role. Shutting host drv after
+* this results in controller getting reset, and it stops
+* responding to otg events
+*/
+   if (dev-driver-resume) {
+   msleep(1000);
dev-driver-resume(dev);
+   }
} else {
if (dev-driver-suspend)
dev-driver-suspend(dev, otg_suspend_state);
-- 
1.8.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 2/9][v3]usb:fsl:otg: Add support to add/remove usb host driver

2015-05-05 Thread Ramneek Mehresh
Add workqueue to add/remove host driver (outside interrupt context)
upon each id change

Signed-off-by: Ramneek Mehresh ramneek.mehr...@freescale.com
---
Changes for v3:
- use overrides for ehci_fsl_overrides
- remove struct ehci_hcd from ehci_fsl
- move ehci_fsl to ehci-fsl.h
 
 drivers/usb/host/ehci-fsl.c | 132 
 drivers/usb/host/ehci-fsl.h |  20 +++
 drivers/usb/host/ehci-hcd.c |  10 
 drivers/usb/host/ehci.h |   6 ++
 4 files changed, 108 insertions(+), 60 deletions(-)

diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
index ab4eee3..b2f5949 100644
--- a/drivers/usb/host/ehci-fsl.c
+++ b/drivers/usb/host/ehci-fsl.c
@@ -33,6 +33,33 @@
 
 #include ehci-fsl.h
 
+#if defined(CONFIG_FSL_USB2_OTG) || defined(CONFIG_FSL_USB2_OTG_MODULE)
+static struct ehci_fsl *hcd_to_ehci_fsl(struct usb_hcd *hcd)
+{
+   return (struct ehci_fsl *)hcd_to_ehci(hcd)-priv;
+}
+
+static void do_change_hcd(struct work_struct *work)
+{
+   struct ehci_fsl *ehci_fsl = container_of(work, struct ehci_fsl,
+   change_hcd_work);
+   struct usb_hcd *hcd = ehci_fsl-hcd;
+   void __iomem *non_ehci = hcd-regs;
+   int retval;
+
+   if (ehci_fsl-hcd_add  !ehci_fsl-have_hcd) {
+   writel(USBMODE_CM_HOST, non_ehci + FSL_SOC_USB_USBMODE);
+   /* host, gadget and otg share same int line */
+   retval = usb_add_hcd(hcd, hcd-irq, IRQF_SHARED);
+   if (retval == 0)
+   ehci_fsl-have_hcd = 1;
+   } else if (!ehci_fsl-hcd_add  ehci_fsl-have_hcd) {
+   usb_remove_hcd(hcd);
+   ehci_fsl-have_hcd = 0;
+   }
+}
+#endif
+
 /* configure so an HC device and id are always provided */
 /* always called with process context; sleeping is OK */
 
@@ -126,11 +153,16 @@ static int usb_hcd_fsl_probe(const struct hc_driver 
*driver,
goto err2;
device_wakeup_enable(hcd-self.controller);
 
-#ifdef CONFIG_USB_OTG
+#if defined(CONFIG_FSL_USB2_OTG) || defined(CONFIG_FSL_USB2_OTG_MODULE)
if (pdata-operating_mode == FSL_USB2_DR_OTG) {
struct ehci_hcd *ehci = hcd_to_ehci(hcd);
+   struct ehci_fsl *ehci_fsl = hcd_to_ehci_fsl(hcd);
 
+   ehci_fsl-hcd = hcd;
hcd-usb_phy = usb_get_phy(USB_PHY_TYPE_USB2);
+
+   INIT_WORK(ehci_fsl-change_hcd_work, do_change_hcd);
+
dev_dbg(pdev-dev, hcd=0x%p  ehci=0x%p, phy=0x%p\n,
hcd, ehci, hcd-usb_phy);
 
@@ -376,15 +408,6 @@ static int ehci_fsl_setup(struct usb_hcd *hcd)
return retval;
 }
 
-struct ehci_fsl {
-   struct ehci_hcd ehci;
-
-#ifdef CONFIG_PM
-   /* Saved USB PHY settings, need to restore after deep sleep. */
-   u32 usb_ctrl;
-#endif
-};
-
 #ifdef CONFIG_PM
 
 #ifdef CONFIG_PPC_MPC512x
@@ -532,24 +555,32 @@ static inline int ehci_fsl_mpc512x_drv_resume(struct 
device *dev)
 }
 #endif /* CONFIG_PPC_MPC512x */
 
-static struct ehci_fsl *hcd_to_ehci_fsl(struct usb_hcd *hcd)
-{
-   struct ehci_hcd *ehci = hcd_to_ehci(hcd);
-
-   return container_of(ehci, struct ehci_fsl, ehci);
-}
-
 static int ehci_fsl_drv_suspend(struct device *dev)
 {
struct usb_hcd *hcd = dev_get_drvdata(dev);
-   struct ehci_fsl *ehci_fsl = hcd_to_ehci_fsl(hcd);
void __iomem *non_ehci = hcd-regs;
+#if defined(CONFIG_FSL_USB2_OTG) || defined(CONFIG_FSL_USB2_OTG_MODULE)
+   struct ehci_fsl *ehci_fsl = hcd_to_ehci_fsl(hcd);
+   struct usb_bus host = hcd-self;
+#endif
 
if (of_device_is_compatible(dev-parent-of_node,
fsl,mpc5121-usb2-dr)) {
return ehci_fsl_mpc512x_drv_suspend(dev);
}
 
+#if defined(CONFIG_FSL_USB2_OTG) || defined(CONFIG_FSL_USB2_OTG_MODULE)
+   if (host.is_otg) {
+   /*struct ehci_hcd *ehci = hcd_to_ehci(hcd);*/
+
+   /* remove hcd */
+   ehci_fsl-hcd_add = 0;
+   schedule_work(ehci_fsl-change_hcd_work);
+   host.is_otg = 0;
+   return 0;
+   }
+#endif
+
ehci_prepare_ports_for_controller_suspend(hcd_to_ehci(hcd),
device_may_wakeup(dev));
if (!fsl_deep_sleep())
@@ -562,15 +593,29 @@ static int ehci_fsl_drv_suspend(struct device *dev)
 static int ehci_fsl_drv_resume(struct device *dev)
 {
struct usb_hcd *hcd = dev_get_drvdata(dev);
-   struct ehci_fsl *ehci_fsl = hcd_to_ehci_fsl(hcd);
struct ehci_hcd *ehci = hcd_to_ehci(hcd);
void __iomem *non_ehci = hcd-regs;
+#if defined(CONFIG_FSL_USB2_OTG) || defined(CONFIG_FSL_USB2_OTG_MODULE)
+   struct ehci_fsl *ehci_fsl = hcd_to_ehci_fsl(hcd);
+   struct usb_bus host = hcd-self;
+#endif
 
if (of_device_is_compatible(dev-parent-of_node,
fsl,mpc5121-usb2-dr)) {
return 

Re: [PATCH v1 1/1] iio: ltr501: Add light channel support

2015-05-05 Thread Daniel Baluta
On Sat, May 2, 2015 at 1:39 AM, Kuppuswamy Sathyanarayanan
sathyanarayanan.kuppusw...@linux.intel.com wrote:
 Added support to calculate lux value from visible
 and IR spectrum adc count values. Also added IIO_LIGHT
 channel to enable user read the lux value directly
 from device using illuminance input ABI.

 Signed-off-by: Kuppuswamy Sathyanarayanan 
 sathyanarayanan.kuppusw...@linux.intel.com

Reviewed-by: Daniel Baluta daniel.bal...@intel.com

 ---
  drivers/iio/light/ltr501.c | 71 
 +-
  1 file changed, 64 insertions(+), 7 deletions(-)

 diff --git a/drivers/iio/light/ltr501.c b/drivers/iio/light/ltr501.c
 index ca4bf47..242cf20 100644
 --- a/drivers/iio/light/ltr501.c
 +++ b/drivers/iio/light/ltr501.c
 @@ -66,6 +66,9 @@

  #define LTR501_REGMAP_NAME ltr501_regmap

 +#define LTR501_LUX_CONV(vis_coeff, vis_data, ir_coeff, ir_data) \
 +   ((vis_coeff * vis_data) - (ir_coeff * ir_data))
 +
  static const int int_time_mapping[] = {10, 5, 20, 40};

  static const struct reg_field reg_field_it =
 @@ -298,6 +301,29 @@ static int ltr501_ps_read_samp_period(struct ltr501_data 
 *data, int *val)
 return IIO_VAL_INT;
  }

 +/* IR and visible spectrum coeff's are given in data sheet */
 +static unsigned long ltr501_calculate_lux(u16 vis_data, u16 ir_data)
 +{
 +   unsigned long ratio, lux;
 +
 +   if (vis_data == 0)
 +   return 0;
 +
 +   /* multiply numerator by 100 to avoid handling ratio  1 */
 +   ratio = DIV_ROUND_UP(ir_data * 100, ir_data + vis_data);
 +
 +   if (ratio  45)
 +   lux = LTR501_LUX_CONV(1774, vis_data, -1105, ir_data);
 +   else if (ratio = 45  ratio  64)
 +   lux = LTR501_LUX_CONV(3772, vis_data, 1336, ir_data);
 +   else if (ratio = 64  ratio  85)
 +   lux = LTR501_LUX_CONV(1690, vis_data, 169, ir_data);
 +   else
 +   lux = 0;
 +
 +   return lux / 1000;
 +}
 +
  static int ltr501_drdy(struct ltr501_data *data, u8 drdy_mask)
  {
 int tries = 100;
 @@ -548,11 +574,24 @@ static const struct iio_event_spec 
 ltr501_pxs_event_spec[] = {
 .num_event_specs = _evsize,\
  }

 +#define LTR501_LIGHT_CHANNEL(_idx) { \
 +   .type = IIO_LIGHT, \
 +   .info_mask_separate = BIT(IIO_CHAN_INFO_PROCESSED), \
 +   .scan_index = 0, \
 +   .scan_type = { \
 +   .sign = 'u', \
 +   .realbits = 16, \
 +   .storagebits = 16, \
 +   .endianness = IIO_CPU, \
 +   }, \
 +}
 +
  static const struct iio_chan_spec ltr501_channels[] = {
 -   LTR501_INTENSITY_CHANNEL(0, LTR501_ALS_DATA0, IIO_MOD_LIGHT_BOTH, 0,
 +   LTR501_LIGHT_CHANNEL(0),
 +   LTR501_INTENSITY_CHANNEL(1, LTR501_ALS_DATA0, IIO_MOD_LIGHT_BOTH, 0,
  ltr501_als_event_spec,
  ARRAY_SIZE(ltr501_als_event_spec)),
 -   LTR501_INTENSITY_CHANNEL(1, LTR501_ALS_DATA1, IIO_MOD_LIGHT_IR,
 +   LTR501_INTENSITY_CHANNEL(2, LTR501_ALS_DATA1, IIO_MOD_LIGHT_IR,
  BIT(IIO_CHAN_INFO_SCALE) |
  BIT(IIO_CHAN_INFO_INT_TIME) |
  BIT(IIO_CHAN_INFO_SAMP_FREQ),
 @@ -562,7 +601,7 @@ static const struct iio_chan_spec ltr501_channels[] = {
 .address = LTR501_PS_DATA,
 .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
 BIT(IIO_CHAN_INFO_SCALE),
 -   .scan_index = 2,
 +   .scan_index = 3,
 .scan_type = {
 .sign = 'u',
 .realbits = 11,
 @@ -572,19 +611,20 @@ static const struct iio_chan_spec ltr501_channels[] = {
 .event_spec = ltr501_pxs_event_spec,
 .num_event_specs = ARRAY_SIZE(ltr501_pxs_event_spec),
 },
 -   IIO_CHAN_SOFT_TIMESTAMP(3),
 +   IIO_CHAN_SOFT_TIMESTAMP(4),
  };

  static const struct iio_chan_spec ltr301_channels[] = {
 -   LTR501_INTENSITY_CHANNEL(0, LTR501_ALS_DATA0, IIO_MOD_LIGHT_BOTH, 0,
 +   LTR501_LIGHT_CHANNEL(0),
 +   LTR501_INTENSITY_CHANNEL(1, LTR501_ALS_DATA0, IIO_MOD_LIGHT_BOTH, 0,
  ltr501_als_event_spec,
  ARRAY_SIZE(ltr501_als_event_spec)),
 -   LTR501_INTENSITY_CHANNEL(1, LTR501_ALS_DATA1, IIO_MOD_LIGHT_IR,
 +   LTR501_INTENSITY_CHANNEL(2, LTR501_ALS_DATA1, IIO_MOD_LIGHT_IR,
  BIT(IIO_CHAN_INFO_SCALE) |
  BIT(IIO_CHAN_INFO_INT_TIME) |
  BIT(IIO_CHAN_INFO_SAMP_FREQ),
  NULL, 0),
 -   IIO_CHAN_SOFT_TIMESTAMP(2),
 +   IIO_CHAN_SOFT_TIMESTAMP(3),
  };

  static int ltr501_read_raw(struct iio_dev *indio_dev,
 @@ -596,6 +636,23 @@ static int ltr501_read_raw(struct iio_dev *indio_dev,
 int ret, i;

 switch 

Re: [PATCH V7 3/6] perf, x86: handle multiple records in PEBS buffer

2015-05-05 Thread Peter Zijlstra
On Mon, Apr 20, 2015 at 04:07:47AM -0400, Kan Liang wrote:
 +static inline void *
 +get_next_pebs_record_by_bit(void *base, void *top, int bit)
 +{
 + struct cpu_hw_events *cpuc = this_cpu_ptr(cpu_hw_events);
 + void *at;
 + u64 pebs_status;
 +
 + if (base == NULL)
 + return NULL;
 +
 + for (at = base; at  top; at += x86_pmu.pebs_record_size) {
 + struct pebs_record_nhm *p = at;
 +
 + if (test_bit(bit, (unsigned long *)p-status)) {

Just wondering, is that BT better than: p-state  (1  bit) ?

 +
 + if (p-status == (1  bit))
 + return at;
 +
 + /* clear non-PEBS bit and re-check */
 + pebs_status = p-status  cpuc-pebs_enabled;
 + pebs_status = (1ULL  MAX_PEBS_EVENTS) - 1;
 + if (pebs_status == (1  bit))
 + return at;
 + }
 + }
 + return NULL;
 +}
 +
  static void __intel_pmu_pebs_event(struct perf_event *event,
 +struct pt_regs *iregs,
 +void *base, void *top,
 +int bit, int count)
  {
   struct perf_sample_data data;
   struct pt_regs regs;
 + int i;
 + void *at = get_next_pebs_record_by_bit(base, top, bit);
  
 + if (!intel_pmu_save_and_restart(event) 
 + !(event-hw.flags  PERF_X86_EVENT_AUTO_RELOAD))
   return;
  
 + if (count  1) {
 + for (i = 0; i  count - 1; i++) {
 + setup_pebs_sample_data(event, iregs, at, data, regs);
 + perf_event_output(event, data, regs);
 + at += x86_pmu.pebs_record_size;
 + at = get_next_pebs_record_by_bit(at, top, bit);
 + }
 + }
 +
 + setup_pebs_sample_data(event, iregs, at, data, regs);
  
 + /* all records are processed, handle event overflow now */

All but the last. There explicitly is one left to be able to call the
overflow handler is there not?

 + if (perf_event_overflow(event, data, regs)) {
   x86_pmu_stop(event, 0);
 + return;
 + }
 +
  }
  
  static void intel_pmu_drain_pebs_core(struct pt_regs *iregs)
 @@ -1000,72 +1081,86 @@ static void intel_pmu_drain_pebs_core(struct pt_regs 
 *iregs)
   if (!event-attr.precise_ip)
   return;
  
 + n = (top - at) / x86_pmu.pebs_record_size;
   if (n = 0)
   return;
  
 + __intel_pmu_pebs_event(event, iregs, at,
 +top, 0, n);
  }
  
  static void intel_pmu_drain_pebs_nhm(struct pt_regs *iregs)
  {
   struct cpu_hw_events *cpuc = this_cpu_ptr(cpu_hw_events);
   struct debug_store *ds = cpuc-ds;
 + struct perf_event *event;
 + void *base, *at, *top;
   int bit;
 + int counts[MAX_PEBS_EVENTS] = {};
  
   if (!x86_pmu.pebs_active)
   return;
  
 + base = (struct pebs_record_nhm *)(unsigned long)ds-pebs_buffer_base;
   top = (struct pebs_record_nhm *)(unsigned long)ds-pebs_index;
  
   ds-pebs_index = ds-pebs_buffer_base;
  
 + if (unlikely(base = top))
   return;
  
 + for (at = base; at  top; at += x86_pmu.pebs_record_size) {
   struct pebs_record_nhm *p = at;
  
   for_each_set_bit(bit, (unsigned long *)p-status,
x86_pmu.max_pebs_events) {
   event = cpuc-events[bit];
   WARN_ON_ONCE(!event);
  
 + if (event-attr.precise_ip)
 + break;
 + }

Would it make sense to delay looking for the event until you've found
there is a single bit set -- and already know which bit that is?

  
 + if (bit = x86_pmu.max_pebs_events)
 + continue;
 + if (!test_bit(bit, cpuc-active_mask))
 + continue;
 + /*
 +  * The PEBS hardware does not deal well with the situation
 +  * when events happen near to each other and multiple bits
 +  * are set. But it should happen rarely.
 +  *
 +  * If these events include one PEBS and multiple non-PEBS
 +  * events, it doesn't impact PEBS record. The record will
 +  * be handled normally. (slow path)
 +  *
 +  * If these events include two or more PEBS events, the
 +  * records for the events can be collapsed into a single
 +  * one, and it's not possible to reconstruct all events
 +  * that caused the PEBS record. It's called collision.
 +  * If collision happened, the record will be dropped.
 +  *
 +  */
 + if (p-status != (1  bit)) {
 + u64 pebs_status;
 +
 + /* slow path */
 + pebs_status 

Re: [PATCH v2 3/7] ACPI / processor: Introduce invalid_logical_cpuid()

2015-05-05 Thread Hanjun Guo

On 2015年05月05日 20:04, Rafael J. Wysocki wrote:

On Tuesday, May 05, 2015 12:15:13 PM Sudeep Holla wrote:


On 05/05/15 03:46, Hanjun Guo wrote:

In ACPI processor drivers, we use direct comparisons of cpu logical
id with -1 which are error prone in case logical cpuid is accidentally
assinged an error code and prevents us from returning an error-encoding
cpuid directly in some cases.

So introduce invalid_logical_cpuid() to identify cpu with invalid
logical cpu num, then it will be used to replace the direct comparisons
with -1.



Ah, OK I see that this fixes the issue I raised in PATCH 1/7, so I think
you need to reorder this and 1/7 patch IMO.


Well, comparing an unsigned int with -1 is not technically invalid (although it
involves an implicit type conversion), but yes, Hanjun, please reorder the
patches.


Sure, I will.

Thanks
Hanjun
--
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/msm: fix unbalanced DRM framebuffer init/destroy

2015-05-05 Thread Stephane Viau
When msm_framebuffer_init() fails before calling drm_framebuffer_init(),
drm_framebuffer_cleanup() [called in msm_framebuffer_destroy()]
is still being called even though drm_framebuffer_init() was not
called for that buffer. Thus a NULL pointer derefencing:

[  247.529691] Unable to handle kernel NULL pointer dereference at virtual 
address 027c
...
[  247.563996] PC is at __mutex_lock_slowpath+0x94/0x3a8
...
[  247.823025] [c07c3c78] (__mutex_lock_slowpath) from [c07c3fac] 
(mutex_lock+0x20/0x3c)
[  247.831186] [c07c3fac] (mutex_lock) from [c0347cf0] 
(drm_framebuffer_cleanup+0x18/0x38)
[  247.839520] [c0347cf0] (drm_framebuffer_cleanup) from [c036d138] 
(msm_framebuffer_destroy+0x48/0x100)
[  247.849066] [c036d138] (msm_framebuffer_destroy) from [c036d580] 
(msm_framebuffer_init+0x1e8/0x228)
[  247.858439] [c036d580] (msm_framebuffer_init) from [c036d630] 
(msm_framebuffer_create+0x70/0x134)
[  247.867642] [c036d630] (msm_framebuffer_create) from [c03493ec] 
(internal_framebuffer_create+0x67c/0x7b4)
[  247.877537] [c03493ec] (internal_framebuffer_create) from [c034ce34] 
(drm_mode_addfb2+0x20/0x98)
[  247.886650] [c034ce34] (drm_mode_addfb2) from [c034071c] 
(drm_ioctl+0x240/0x420)
[  247.894378] [c034071c] (drm_ioctl) from [c011df7c] 
(do_vfs_ioctl+0x4e4/0x5a4)
...

Signed-off-by: Stephane Viau sv...@codeaurora.org
---
 drivers/gpu/drm/msm/msm_fb.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_fb.c b/drivers/gpu/drm/msm/msm_fb.c
index 6b573e6..c0f09d3 100644
--- a/drivers/gpu/drm/msm/msm_fb.c
+++ b/drivers/gpu/drm/msm/msm_fb.c
@@ -239,8 +239,7 @@ struct drm_framebuffer *msm_framebuffer_init(struct 
drm_device *dev,
return fb;
 
 fail:
-   if (fb)
-   msm_framebuffer_destroy(fb);
+   kfree(msm_fb);
 
return ERR_PTR(ret);
 }
-- 
Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a 
Linux Foundation Collaborative Project

--
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] drivers: dma: amba-pl08x: Supress spaces in indentation

2015-05-05 Thread Dan Carpenter
On Tue, May 05, 2015 at 07:31:40AM -0400, Leonardo Carreras wrote:

 I will check this, but may I ask if that would be marked as an error
 by checkpatch.

No, it won't.  It is the correct way.

regards,
dan carpenter

--
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] timer: Avoid waking up an idle-core by migrate running timer

2015-05-05 Thread Thomas Gleixner
On Sat, 25 Apr 2015, Eric Dumazet wrote:
 On Thu, 2015-04-23 at 14:45 +0200, Thomas Gleixner wrote:
 
  You definitely have a point from the high throughput networking
  perspective.
  
  Though in a power optimizing scenario with minimal network traffic
  this might be the wrong decision. We have to gather data from the
  power maniacs whether this matters or not. The FULL_NO_HZ camp might
  be pretty unhappy about the above.
 
 Sure, I understand.
 
 
 To make this clear, here the profile on a moderately loaded TCP server,
 pushing ~20Gbits of data. Most of TCP output is ACK clock driven (thus
 from softirq context).
 
 (using regular sendmsg() system calls, that why the
 get_nohz_timer_target() is 'only' second in the profile, but add the
 find_next_bit() to it and this is very close being at first position)
 
 
 
PerfTop:4712 irqs/sec  kernel:96.7%  exact:  0.0% [4000Hz cycles],  
 (all, 72 CPUs)
 -
 10.16%  [kernel]  [k] copy_user_enhanced_fast_string
  5.66%  [kernel]  [k] get_nohz_timer_target 
  5.59%  [kernel]  [k] _raw_spin_lock
  2.53%  [kernel]  [k] __netif_receive_skb_core  
  2.27%  [kernel]  [k] find_next_bit 
  1.90%  [kernel]  [k] tcp_ack   
 
 Maybe a reasonable heuristic would be to
 change /proc/sys/kernel/timer_migration default to 0 on hosts with more
 than 32 cpus.
 
 profile with timer_migration = 0
 
PerfTop:3656 irqs/sec  kernel:94.3%  exact:  0.0% [4000Hz cycles],  
 (all, 72 CPUs)
 -
 13.95%  [kernel]  [k] copy_user_enhanced_fast_string
  4.65%  [kernel]  [k] _raw_spin_lock
  2.57%  [kernel]  [k] __netif_receive_skb_core  
  2.33%  [kernel]  [k] tcp_ack   

Is that with the static key patch applied?

Thanks,

tglx
--
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: question about RCU dynticks_nesting

2015-05-05 Thread Peter Zijlstra
On Tue, May 05, 2015 at 05:34:46AM -0700, Paul E. McKenney wrote:
 On Tue, May 05, 2015 at 12:53:46PM +0200, Peter Zijlstra wrote:
  On Mon, May 04, 2015 at 12:39:23PM -0700, Paul E. McKenney wrote:
   But in non-preemptible RCU, we have PREEMPT=n, so there is no preempt
   counter in production kernels.  Even if there was, we have to sample this
   on other CPUs, so the overhead of preempt_disable() and preempt_enable()
   would be where kernel entry/exit is, so I expect that this would be a
   net loss in overall performance.
  
  We unconditionally have the preempt_count, its just not used much for
  PREEMPT_COUNT=n kernels.
 
 We have the field, you mean?  I might be missing something, but it still
 appears to me thta preempt_disable() does nothing for PREEMPT=n kernels.
 So what am I missing?

There's another layer of accessors that can in fact manipulate the
preempt_count even for !PREEMPT_COUNT kernels. They are currently used
by things like pagefault_disable().
--
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] gma500:Remove functions that are now deprecated and move to the newer functions in drm_dp_helper.c

2015-05-05 Thread Patrik Jakobsson
On Tue, May 5, 2015 at 12:29 AM, Nicholas Krause xerofo...@gmail.com wrote:
 This removes the deprecated functions,i2c_dp_aux_add_bus and
 i2c_dp_aux_prepare_bus and the only call in the function,
 cdv_intel_dp_i2c_init to i2c_dp_aux_add_bus respectfully.
 The call and use of these functions is now replaced alongside
 the removal of setting other values in the function,cdv_intel_dp_i2c_init
 to use the helper function, drm_dp_aux_register that can handle all this
 work internally.

You need to fill in the drm_dp_aux structure and implement a proper transfer
function. This patch would only break things. But the cdv dp output is already
broken on my system so it needs fixing first.

-Patrik

 Signed-off-by: Nicholas Krause xerofo...@gmail.com
 ---
  drivers/gpu/drm/gma500/cdv_intel_dp.c | 42 
 ++-
  1 file changed, 2 insertions(+), 40 deletions(-)

 diff --git a/drivers/gpu/drm/gma500/cdv_intel_dp.c 
 b/drivers/gpu/drm/gma500/cdv_intel_dp.c
 index 0fafb8e..c8c20fc 100644
 --- a/drivers/gpu/drm/gma500/cdv_intel_dp.c
 +++ b/drivers/gpu/drm/gma500/cdv_intel_dp.c
 @@ -200,38 +200,6 @@ static const struct i2c_algorithm i2c_dp_aux_algo = {
 .functionality  = i2c_algo_dp_aux_functionality,
  };

 -static void
 -i2c_dp_aux_reset_bus(struct i2c_adapter *adapter)
 -{
 -   (void) i2c_algo_dp_aux_address(adapter, 0, false);
 -   (void) i2c_algo_dp_aux_stop(adapter, false);
 -}
 -
 -static int
 -i2c_dp_aux_prepare_bus(struct i2c_adapter *adapter)
 -{
 -   adapter-algo = i2c_dp_aux_algo;
 -   adapter-retries = 3;
 -   i2c_dp_aux_reset_bus(adapter);
 -   return 0;
 -}
 -
 -/*
 - * FIXME: This is the old dp aux helper, gma500 is the last driver that 
 needs to
 - * be ported over to the new helper code in drm_dp_helper.c like i915 or 
 radeon.
 - */
 -static int __deprecated
 -i2c_dp_aux_add_bus(struct i2c_adapter *adapter)
 -{
 -   int error;
 -
 -   error = i2c_dp_aux_prepare_bus(adapter);
 -   if (error)
 -   return error;
 -   error = i2c_add_adapter(adapter);
 -   return error;
 -}
 -
  #define _wait_for(COND, MS, W) ({ \
  unsigned long timeout__ = jiffies + msecs_to_jiffies(MS);   \
  int ret__ = 0;  \
 @@ -275,6 +243,7 @@ struct cdv_intel_dp {
 int backlight_on_delay;
 int backlight_off_delay;
 struct drm_display_mode *panel_fixed_mode;  /* for eDP */
 +   struct drm_dp_aux aux;
 bool panel_on;
  };

 @@ -855,18 +824,11 @@ cdv_intel_dp_i2c_init(struct gma_connector *connector,
 intel_dp-algo.running = false;
 intel_dp-algo.address = 0;
 intel_dp-algo.aux_ch = cdv_intel_dp_i2c_aux_ch;
 -
 memset(intel_dp-adapter, '\0', sizeof (intel_dp-adapter));
 -   intel_dp-adapter.owner = THIS_MODULE;
 -   intel_dp-adapter.class = I2C_CLASS_DDC;
 -   strncpy (intel_dp-adapter.name, name, sizeof(intel_dp-adapter.name) 
 - 1);
 -   intel_dp-adapter.name[sizeof(intel_dp-adapter.name) - 1] = '\0';
 -   intel_dp-adapter.algo_data = intel_dp-algo;
 -   intel_dp-adapter.dev.parent = connector-base.kdev;

 if (is_edp(encoder))
 cdv_intel_edp_panel_vdd_on(encoder);
 -   ret = i2c_dp_aux_add_bus(intel_dp-adapter);
 +   ret = drm_dp_aux_register(intel_dp-aux);
 if (is_edp(encoder))
 cdv_intel_edp_panel_vdd_off(encoder);

 --
 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 V7 3/6] perf, x86: handle multiple records in PEBS buffer

2015-05-05 Thread Peter Zijlstra
On Tue, May 05, 2015 at 03:07:23PM +0200, Peter Zijlstra wrote:
 On Mon, Apr 20, 2015 at 04:07:47AM -0400, Kan Liang wrote:
  From: Yan, Zheng zheng.z@intel.com
  +static void perf_log_lost(struct perf_event *event)
  +{
  +   struct perf_output_handle handle;
  +   struct perf_sample_data sample;
  +   int ret;
  +
  +   struct {
  +   struct perf_event_headerheader;
  +   u64 id;
  +   u64 lost;
  +   } lost_event = {
  +   .header = {
  +   .type = PERF_RECORD_LOST,
  +   .misc = 0,
  +   .size = sizeof(lost_event),
  +   },
  +   .id = event-id,
  +   .lost   = 1,
  +   };
  +
  +   perf_event_header__init_id(lost_event.header, sample, event);
  +
  +   ret = perf_output_begin(handle, event,
  +   lost_event.header.size);
  +   if (ret)
  +   return;
  +
  +   perf_output_put(handle, lost_event);
  +   perf_event__output_id_sample(event, handle, sample);
  +   perf_output_end(handle);
  +}
 
 RECORDs are generic, and should live in the core code.
 
 Also, you should introduce this RECORD in a separate patch.

On that, this is lacking a RECORD definition in
include/uapi/linux/perf_event.h:perf_event_type
--
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] x86/quark: Add Quark embedded SRAM support

2015-05-05 Thread Bryan O'Donoghue

On 04/05/15 08:00, Thomas Gleixner wrote:

On Mon, 4 May 2015, Bryan O'Donoghue wrote:

+++ b/arch/x86/include/asm/esram.h


This should be in platform/quark/


+++ b/arch/x86/platform/intel-quark/esram.c


No problem.


+#define phys_to_esram(x)   ((x)  PAGE_SHIFT)


There is a single usage size for this lousy documented magic.


Hmm - OK I'll add a comment like stuff the address field of the eSRAM 
page register or similar.



+struct esram_page {
+   u32 id;
+   struct list_head list;
+   phys_addr_t addr;


Please tab align the struct member names as you did below.


OK


+};
+
+/**
+ * struct esram_dev
+ *
+ * Structre to represent module state/data/etc.
+ */
+struct esram_dev {
+   struct dentry   *dbg;


So dbgfs is a hard requirement for this to work?


No it's not. I had an awful hard time making a kernel without dbgfs but, 
I'll add an #ifdef for the field



+ */
+static int esram_dbgfs_state_show(struct seq_file *s, void *unused)
+{
+   struct esram_dev *edev = esram_dev;
+   u32 data;
+   u32 reg = (u32)s-private;


You really like to waste lines. What's wrong with:

u32 data, reg = .


Hmm, I had feedback when doing the IMR code *not* to do that, so kept 
that pattern for eSRAM. More than happy to rationalize the line-count here.



+/**
+ * esram_dump_fault - dump eSRAM registers and BUG().
+ *
+ * @return:


Sigh. Please generate kernel docs from your file to catch all those
function comment failures.


Hmm - OK - I've missed a trick here clearly - I'll check.


+
+   /* Show the page state. */
+   iosf_mbi_read(QRK_MBI_UNIT_MM, QRK_MBI_MMESRAM_READ, ep-id, pgd);
+   pr_err(fault @ page %d state 0x%08x\n, ep-id, pgd);
+
+   /* Get state. */
+   iosf_mbi_read(QRK_MBI_UNIT_MM, QRK_MBI_MM_READ, ESRAMCTRL_REG, pgc);
+   iosf_mbi_read(QRK_MBI_UNIT_MM, QRK_MBI_MM_READ, ESRAMPGBLOCK_REG, pgb);
+   pr_err(page-control=0x%08x, page-block=0x%08x\n, pgc, pgb);
+
+   BUG();


So we force BUG() here. Why?


A nice way to generate a backtrace which was useful to the BSP version 
of this code since BSP version supported deallocation of eSRAM pages and 
had a /sysfs interface to add/remove mappings.


With the version I'm proposing here, we could just as easily not BUG() 
at all.




+/**
+ * esram_page_enable - Enable an eSRAM page spinning for page to become ready.
+ *
+ * @param ep: struct esram_page carries data to program to register.
+ * @return zero on success  0 on error.
+ */
+static int esram_page_enable(struct esram_page *ep)
+{
+   int ret = 0;
+
+   /* Enable a busy page = EINVAL, return IOSF error as necessary. */


Why is EINVAL a good return code if the page is busy?


You're right ENOMEM is more logical.




+   ret = esram_page_busy(ep);
+   if (ret)
+   return ret  0 ? ret : -EINVAL;
+
+   /* Enable page overlay - with automatic flush on S3 entry. */
+   ret = iosf_mbi_write(QRK_MBI_UNIT_MM, QRK_MBI_MMESRAM_WRITE, ep-id,
+ESRAMPGCTRL_FLUSH_PAGE_EN | ESRAMPGCTRL_EN |
+phys_to_esram(ep-addr));
+   if (ret)
+   return ret;
+
+   /* Busy bit true is good, ret  0 means IOSF read error. */
+   ret = esram_page_busy(ep);
+   if (ret)
+   ret = 0;
+
+   return ret;


Why not just return 0 unconitionally?


That should be if (ret  0) we need to transmit iosf bus errors upwards.




+   if (pte == NULL || !(pte_write(*pte))) {
+   pr_err(invalid address for overlay %pa\n, ep-addr);
+   return -ENOMEM;
+   }


Also what makes sure that the mapping is not going away under you?

Nothing, but the whole thing is not required at all. Because you map a
kernel buffer from init(), so these half baken sanity checks are
really useless.


The BSP code was checking for memory as ro or rw and flipping the bit in 
the page to make it r/w so the memcpy() could continue.


You're right though since the data comes from a kzalloc() there's no 
point in validating it further.





+
+   /* eSRAM does not autopopulate so save the contents. */
+   memcpy(edev-cbuf, vaddr, PAGE_SIZE);
+   ret = esram_page_enable(ep);
+   if (ret) {
+   esram_dump_fault(ep);
+   goto err;


return ret perhaps?


+   }
+
+   /* Overlay complete, repopulate the eSRAM page with original data. */
+   memcpy((void *)vaddr, esram_dev.cbuf,  PAGE_SIZE);


So the caller must ensure that the DRAM content cannot change between
the two memcpys, right? Otherwise you end up with inconsistent data.

 At init() time I can see how that works, on resume() rather not.

Yes absolutely true. eSRAM is not self populating - ideally you'd want 
memory transactions to be stopped until the eSRAM had populated itself.


During init this is safe. The resume callback is done via syscore_ops so 
the resume path should be called with 

Re: [PATCH v2 3/7] ACPI / processor: Introduce invalid_logical_cpuid()

2015-05-05 Thread Rafael J. Wysocki
On Tuesday, May 05, 2015 12:15:13 PM Sudeep Holla wrote:
 
 On 05/05/15 03:46, Hanjun Guo wrote:
  In ACPI processor drivers, we use direct comparisons of cpu logical
  id with -1 which are error prone in case logical cpuid is accidentally
  assinged an error code and prevents us from returning an error-encoding
  cpuid directly in some cases.
 
  So introduce invalid_logical_cpuid() to identify cpu with invalid
  logical cpu num, then it will be used to replace the direct comparisons
  with -1.
 
 
 Ah, OK I see that this fixes the issue I raised in PATCH 1/7, so I think
 you need to reorder this and 1/7 patch IMO.

Well, comparing an unsigned int with -1 is not technically invalid (although it
involves an implicit type conversion), but yes, Hanjun, please reorder the
patches.


-- 
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 4/4] sched: cpufreq_cfs: pelt-based cpu frequency scaling

2015-05-05 Thread Juri Lelli
Hi Peter,

thanks a lot for the fast reply! :)

On 05/05/15 10:00, Peter Zijlstra wrote:
 On Mon, May 04, 2015 at 03:10:41PM -0700, Michael Turquette wrote:
 This policy is implemented using the cpufreq governor interface for two
 main reasons:

 1) re-using the cpufreq machine drivers without using the governor
 interface is hard.

 2) using the cpufreq interface allows us to switch between the
 scheduler-driven policy and legacy cpufreq governors such as ondemand at
 run-time. This is very useful for comparative testing and tuning.
 
 Urgh,. so I don't really like that. It adds a lot of noise to the
 system. You do the irq work thing to kick the cpufreq threads which do
 their little thing -- and their wakeup will influence the cfs
 accounting, which in turn will start the whole thing anew.
 

Right, we introduce some overhead, but in the end it should be less or
at least similar to what we already have today with ondemand, for
example. The idea here is that we should trigger this kthread wrapper
only when it is really needed, and maybe reduce the things it needs to
do. The irq work thing is one way we could do it from wherever we want
to.

Regarding cfs accounting, the bad trick is that we run these kthreads
with fifo. One reason is that we expect them to run quickly and we
usually want them to run as soon as they are woken up (possibly
preempting the task for which they are adapting the frequency). Of
course we'll have the same accounting problem within RT, but maybe we
could associate some special flag to them and treat them differently.
Or else we could just realize that we need this kind of small wrapper
tasks, of which we should know the behaviour of, and live with that.

Anyway, I'm currently experimenting in driving this thing a bit
differently from what we have in this patchset. I'm trying to reduce
the need to trigger the whole machinery to the least. Do you think is
still valuable to give it a look?

 I would really prefer you did a whole new system with directly invoked
 drivers that avoid the silly dance. Your 'new' ARM systems should be
 well capable of that.
 

Right, this thing is maybe not the cleanest solution we could come up
with, and how 'new' ARM systems will work may help us designing a better
one, but I'm not sure of what we can really do about today systems,
though. We of course need to support them (and for few years I guess)
and we would also like to have an event-driven solution to drive OPP
selection from the scheduler at the same time.

From what I can tell, this non-cpufreq new system will probably have
to re-implement what current drivers are doing, and it will still have
to sleep during freq changes (at least for ARM). This will require some
asynch way of doing the freq changes, which is what the kthread solution
is already doing.

Best,

- Juri

 You can still do 2 if you create a cpufreq off switch. You can then
 either enable the sched one or the legacy cpufreq -- or both if you want
 a trainwreck ;-)
 
 As to the drivers, they're mostly fairly small and self contained, it
 should not be too hard to hack them up to work without cpufreq.
 

--
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: question about RCU dynticks_nesting

2015-05-05 Thread Paul E. McKenney
On Tue, May 05, 2015 at 12:51:02PM +0200, Peter Zijlstra wrote:
 On Tue, May 05, 2015 at 12:48:34PM +0200, Peter Zijlstra wrote:
  On Mon, May 04, 2015 at 03:00:44PM -0400, Rik van Riel wrote:
   In case of the non-preemptible RCU, we could easily also
   increase current-rcu_read_lock_nesting at the same time
   we increase the preempt counter, and use that as the
   indicator to test whether the cpu is in an extended
   rcu quiescent state. That way there would be no extra
   overhead at syscall entry or exit at all. The trick
   would be getting the preempt count and the rcu read
   lock nesting count in the same cache line for each task.
  
  Can't do that. Remember, on x86 we have per-cpu preempt count, and your
  rcu_read_lock_nesting is per task.
 
 Hmm, I suppose you could do the rcu_read_lock_nesting thing in a per-cpu
 counter too and transfer that into the task_struct on context switch.
 
 If you manage to put both sides of that in the same cache things should
 not add significant overhead.
 
 You'd have to move the rcu_read_lock_nesting into the thread_info, which
 would be painful as you'd have to go touch all archs etc..

Last I tried doing that, things got really messy at context-switch time.
Perhaps I simply didn't do the save/restore in the right place?

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 1/2] gpio / ACPI: Add support for retrieving GpioInt resources from a device

2015-05-05 Thread Mika Westerberg
On Tue, May 05, 2015 at 01:47:36AM +0200, Rafael J. Wysocki wrote:
 On Tuesday, April 28, 2015 06:05:06 PM Mika Westerberg wrote:
  ACPI specification knows two types of GPIOs: GpioIo and GpioInt. The latter
  is used to describe that a given device interrupt line is connected to a
  specific GPIO pin. Typical ACPI _CRS entry for such device looks like
  below:
  
  Name (_CRS, ResourceTemplate ()
  {
  I2cSerialBus (0x004A, ControllerInitiated, 0x00061A80,
AddressingMode7Bit, \\_SB.PCI0.I2C6,
0x00, ResourceConsumer)
  GpioIo (Exclusive, PullDefault, 0x, 0x,
  IoRestrictionOutputOnly, \\_SB.GPO0,
  0x00, ResourceConsumer)
  {
  0x004B
  }
  GpioInt (Level, ActiveLow, Shared, PullDefault, 0x,
   \\_SB.GPO0, 0x00, ResourceConsumer)
  {
  0x004C
  }
  })
  
  Currently drivers need to request a GPIO corresponding to the right GpioInt
  and then translate that to Linux IRQ number. This adds unnecessary lines of
  boiler-plate code.
  
  We can ease this a bit by introducing acpi_dev_gpio_irq_get() analogous to
  of_irq_get(). This function translates given GpioInt resource under the
  device in question to the suitable Linux IRQ number.
  
  Signed-off-by: Mika Westerberg mika.westerb...@linux.intel.com
 
 Acked-by: Rafael J. Wysocki rafael.j.wyso...@intel.com

Thanks Rafael.

I'm going to change the other patch a bit to address conserns from
Wolfram so that we will use irq == 0 to indicate an invalid interrupt
instead of -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/


[BUG ?] MIPS: KVM: condition with no effect

2015-05-05 Thread Nicholas Mc Guire

Hi !

 Not sure if this is a bug or maybe a placeholder for
 something... so patch - but maybe someone that knows this code can
 give it a look.

arch/mips/kvm/emulate.c:emulation_result kvm_mips_complete_mmio_load()
snip
2414 case 2:
2415 if (vcpu-mmio_needed == 2)
2416 *gpr = *(int16_t *) run-mmio.data;
2417 else
2418 *gpr = *(int16_t *) run-mmio.data;
2419 
2420 break;
snip

 either the if/else is not needed or one of the branches is wrong
 or it is a place-holder for somethign that did not get
 done - in which case a few lines explaining this would be 
 nice (e.g. like in arch/sh/kernel/traps_64.c line 59)

 line numbers refer to 4.1-rc2 

thx!
hofrat
--
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: question about RCU dynticks_nesting

2015-05-05 Thread Paul E. McKenney
On Tue, May 05, 2015 at 12:53:46PM +0200, Peter Zijlstra wrote:
 On Mon, May 04, 2015 at 12:39:23PM -0700, Paul E. McKenney wrote:
  But in non-preemptible RCU, we have PREEMPT=n, so there is no preempt
  counter in production kernels.  Even if there was, we have to sample this
  on other CPUs, so the overhead of preempt_disable() and preempt_enable()
  would be where kernel entry/exit is, so I expect that this would be a
  net loss in overall performance.
 
 We unconditionally have the preempt_count, its just not used much for
 PREEMPT_COUNT=n kernels.

We have the field, you mean?  I might be missing something, but it still
appears to me thta preempt_disable() does nothing for PREEMPT=n kernels.
So what am I missing?

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 v2 3/4] PM / Hibernate: fix SANITIZE_FREED_PAGES

2015-05-05 Thread Anisse Astier
On Tue, May 5, 2015 at 12:29 AM, Rafael J. Wysocki r...@rjwysocki.net wrote:
 I haven't seen it, for one, and I'm wondering why the clearing cannot be 
 done
 at the swsusp_free() time?

Because the validity of the free pages bitmap is short-lived since
device resume code might do some allocations.


 In any case, please CC hibernation-related patches and discussions thereof to
 linux...@vger.kernel.org.

Thanks, I had to forget something when sending this series :-/ ; I'm
preparing v3 that will be sent to linux-pm too.

Regards,

Anisse
--
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 2/7] mmc: mediatek: Add Mediatek MMC driver

2015-05-05 Thread Ulf Hansson
On 28 April 2015 at 11:48, Chaotian Jing chaotian.j...@mediatek.com wrote:
 Add Mediatek MMC driver code
 Support eMMC/SD/SDIO

 Signed-off-by: Chaotian Jing chaotian.j...@mediatek.com
 ---
  drivers/mmc/host/Kconfig  |8 +
  drivers/mmc/host/Makefile |1 +
  drivers/mmc/host/mtk-sd.c | 1416 
 +
  3 files changed, 1425 insertions(+)
  create mode 100644 drivers/mmc/host/mtk-sd.c

[...]

 +static void msdc_init_hw(struct msdc_host *host)
 +{
 +   u32 val;
 +   /* Configure to MMC/SD mode */
 +   sdr_set_field(host-base + MSDC_CFG, MSDC_CFG_MODE, MSDC_SDMMC);
 +
 +   /* Reset */
 +   msdc_reset_hw(host);
 +
 +   /* Disable card detection */
 +   sdr_clr_bits(host-base + MSDC_PS, MSDC_PS_CDEN);
 +
 +   /* Disable and clear all interrupts */
 +   writel(0, host-base + MSDC_INTEN);
 +   val = readl(host-base + MSDC_INT);
 +   writel(val, host-base + MSDC_INT);
 +
 +   writel(0, host-base + MSDC_PAD_TUNE);
 +   writel(0, host-base + MSDC_IOCON);
 +   sdr_set_field(host-base + MSDC_IOCON, MSDC_IOCON_DDLSEL, 1);
 +   writel(0x403c004f, host-base + MSDC_PATCH_BIT);
 +   sdr_set_field(host-base + MSDC_PATCH_BIT, MSDC_CKGEN_MSDC_DLY_SEL, 
 1);
 +   writel(0x0089, host-base + MSDC_PATCH_BIT1);
 +   /* Configure to enable SDIO mode.
 +  it's must otherwise sdio cmd5 failed */
 +   sdr_set_bits(host-base + SDC_CFG, SDC_CFG_SDIO);
 +
 +   /* disable detect SDIO device interrupt function */
 +   sdr_clr_bits(host-base + SDC_CFG, SDC_CFG_SDIOIDE);
 +
 +   /* Configure to default data timeout */
 +   sdr_set_field(host-base + SDC_CFG, SDC_CFG_DTOC, 3);
 +   msdc_set_buswidth(host, MMC_BUS_WIDTH_1);
 +
 +   dev_dbg(host-dev, init hardware done!);
 +}
 +
 +static void msdc_deinit_hw(struct msdc_host *host)
 +{
 +   u32 val;
 +   /* Disable and clear all interrupts */
 +   writel(0, host-base + MSDC_INTEN);
 +
 +   val = readl(host-base + MSDC_INT);
 +   writel(val, host-base + MSDC_INT);
 +
 +   msdc_gate_clock(host);
 +
 +   if (!IS_ERR(host-h_clk))
 +   clk_disable_unprepare(host-h_clk);

To make it clear when clocks are managed, I would move all that stuff
outside this function.

That would also follow how msdc_init_hw() is coded.

[...]

 +static void msdc_ops_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
 +{
 +   struct msdc_host *host = mmc_priv(mmc);
 +   int ret;
 +   u32 ddr = 0;
 +
 +   if (ios-timing == MMC_TIMING_UHS_DDR50 ||
 +   ios-timing == MMC_TIMING_MMC_DDR52)
 +   ddr = 1;
 +
 +   msdc_set_buswidth(host, ios-bus_width);
 +
 +   /* Suspend/Resume will do power off/on */
 +   switch (ios-power_mode) {
 +   case MMC_POWER_UP:
 +   msdc_init_hw(host);

I think you need to move the call to msdc_init_hw() into -probe().

See more comments in the -probe() function.

 +   if (!IS_ERR(mmc-supply.vmmc)) {
 +   ret = mmc_regulator_set_ocr(mmc, mmc-supply.vmmc,
 +   ios-vdd);
 +   if (ret) {
 +   dev_err(host-dev, Failed to set vmmc 
 power!\n);
 +   return;
 +   }
 +   }
 +   break;
 +   case MMC_POWER_ON:
 +   if (!IS_ERR(mmc-supply.vqmmc)  !host-vqmmc_enabled) {
 +   ret = regulator_enable(mmc-supply.vqmmc);
 +   if (ret)
 +   dev_err(host-dev, Failed to set vqmmc 
 power!\n);
 +   else
 +   host-vqmmc_enabled = true;
 +   }
 +   msdc_ungate_clock(host);

I suggest that clocks that is managed through the clk API, should be
enabled during -probe(). Then leave them enabled until the -remove()
callback gets invoked.

In the -set_ios() callback you should care about the internal
registers of your controller to enable/disable bus clocks.
Though, that should be considering of what value the ios-clock has
and not due MMC_POWER_ON|OFF|UP.

See more comments in the -probe() function.

 +   break;
 +   case MMC_POWER_OFF:
 +   if (!IS_ERR(mmc-supply.vmmc))
 +   mmc_regulator_set_ocr(mmc, mmc-supply.vmmc, 0);
 +
 +   if (!IS_ERR(mmc-supply.vqmmc)  host-vqmmc_enabled) {
 +   regulator_disable(mmc-supply.vqmmc);
 +   host-vqmmc_enabled = false;
 +   }
 +   msdc_gate_clock(host);

Same comment as above and see more comments in the -probe() function.

 +   break;
 +   default:
 +   break;
 +   }
 +
 +   /* Apply different pinctrl settings for different timing */
 +   if (timing_is_uhs(ios))
 +   pinctrl_select_state(host-pinctrl, host-pins_uhs);
 +   

Re: [Query] PCIe power management with designware

2015-05-05 Thread Kishon Vijay Abraham I

Hi Pratyush,

On Tuesday 05 May 2015 06:33 PM, Pratyush Anand wrote:

Thank you for responding.

Hi Kishon,

Correcting Mohit's ID

On Mon, May 4, 2015 at 9:54 PM, Kishon Vijay Abraham I kis...@ti.com wrote:


Hi,

I'm planning to add power management (suspend/resume) support for DRA7xx and 
have a query.

The pci_pm_suspend_noirq callback being a bus pm_ops gets invoked late i.e 
after the suspend hooks of the pci devices (including the RC driver). The 
problem is after the 'suspend' of the RC driver, the clocks are disabled. Now


I think, clocks should not be disabled at this point.

pci_pm_suspend_noirq has a call to pci_save_state() which tries to access the

configuration space registers. Since the clocks are disabled by now, this 
results in an abort. Shouldn't we do save_state() earlier?


So, RC driver should need to implement a pm-suspend_noirq() where it
can handle all these.


okay.. let me try that.




After working around the above problem, I face one more issue with broadcom 
BCM95721 A211 card. After resuming, I'm unable to access the memory space. I'm 
not sure if that is specific to that particular card, since I have no problems 
with USB cards.


If you are able to access configuration space and  not able to access
memory space then that seems strange.
If cfg is also not accessible then can you check if link training with
BCM95721 A211 card was successful?


I'm able to access the configuration space. The pci core writes D0 to the pmcsr 
register of the card and I get


tg3 :01:00.0: Refused to change power state, currently in D3.

After that in the resume callback of the card, when it tries to access the 
ethernet registers it hangs.


Thanks
Kishon
--
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 v2 for-4.0] mm, thp: really limit transparent hugepage allocation to local node

2015-05-05 Thread Aneesh Kumar K.V
Vlastimil Babka vba...@suse.cz writes:

 On 04/21/2015 09:31 AM, Aneesh Kumar K.V wrote:
 Vlastimil Babka vba...@suse.cz writes:

 On 25.2.2015 22:24, David Rientjes wrote:

 alloc_pages_preferred_node() variant, change the exact_node() variant to 
 pass
 __GFP_THISNODE, and audit and adjust all callers accordingly.


...
 Right, we might be changing behavior not just for slab allocators, but
 also others using such
 combination of flags.

 Any update on this ? Did we reach a conclusion on how to go forward here
 ?

 I believe David's later version was merged already. Or what exactly are 
 you asking about?

When I checked last time I didn't find it. Hence I asked here. Now I
see that it got committed as 5265047ac30191ea24b16503165000c225f54feb

Thanks
-aneesh

--
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 bisected regression] input_available_p() sometimes says 'no' when it should say 'yes'

2015-05-05 Thread Peter Hurley
Stop top-posting.

On 05/05/2015 08:03 AM, Nic Percival wrote:
 
 There is only ever one debuggee process.
 My original demo (and indeed the original test failure) is not threaded. The 
 debugger is multi-threaded.
 
 I've brought in Chris, Fletch and Paul, my immediate colleagues, into the 
 discussion.
 
 The email thread is getting a little tangled, however, from my standpoint I 
 have..
 
 1) poll tells us we have nothing to read on a pty, when we know something was 
 written into the other end.

You're using a synchronization mechanism (ptrace) to validate an
asynchronous process (tty i/o). That's not going to work.

 2) Given that 'poll' is not telling us that data has been written into the 
 pty, what can we use? Surely that is what poll is for.

poll() doesn't tell you that nothing has been written.

You're inferring that using a broken understanding of terminal i/o:
ttys are not synchronous pipes.

 3) If a debuggee program has displayed 'how old are you?' and then hit a 
 breakpoint on the 'ACCEPT' response, then the question might very well not be 
 displayed, despite the debugger  sitting on the statement some way subsequent 
 to the display. 

Let's extend your logic process here to a general-purpose debugger
that can control all output devices.

1. The debugger and debuggee are running on X-Windows.
2. The debuggee outputs 'how old are you?'
3. The debugger immediately halts the debuggee and all output devices.

The output will not appear on the monitor because X-Windows
output is asynchronous. So is terminal i/o.

 
 4) If I understand correctly, the modification is a performance enhancement. 
 Obviously in the case of 'ptrace' debugging, performance is not a requirement.

Nothing obvious about it. Not all uses of ptrace are interactive, and certainly 
don't
want alternate behavior based on whether the process is ptraced.

 5) Given 'xterm' use pty's, could a scenario happen where a user is prompted 
 'How old are you?' in the xterm, but an input (getchar, whatever) is hit 
 before that output is displayed? With or without ptrace?

Of course. It's called typeahead. Since tty i/o is buffered, the following is 
possible:

1. The user types '15\r'
2. The process writes 'How old are you?'
3. The process reads '15\n'

Processes that don't want typeahead call tcflush() before reading input.

Regards,
Peter Hurley

 Thanks,
 Nic
 
 
 
 -Original Message-
 From: Peter Hurley [mailto:pe...@hurleysoftware.com] 
 Sent: 05 May 2015 12:19
 To: Nic Percival; Michael Matz
 Cc: NeilBrown; Greg Kroah-Hartman; Jiri Slaby; linux-kernel@vger.kernel.org
 Subject: Re: [PATCH bisected regression] input_available_p() sometimes says 
 'no' when it should say 'yes'
 
 
 A: No.
 Q: Should I include quotations after my reply?
 
 http://daringfireball.net/2007/07/on_top
 
 
 On 05/05/2015 04:20 AM, Nic Percival wrote:
 Michael is correct.
 Our COBOL debugger has a test feature whereby we can drive it to step 
 through debugging code, hitting breakpoints and so on.
 The debugger maintains a 'user screen' which is what the 'debuggee' process 
 has displayed.
 This is communicated to the debugger with pseudo-tty's.
 The state of this user screen is checked as part of this (and other) tests.
 
 So the debugger doesn't display output from other non-TRACEME threads or 
 child processes of the debuggee, right?
 
 When that's fixed, you'll see that the test failure has gone away.
 
 The actual test failure is a failure of some text to be displayed on the 
 debuggee user screen when we know, given it has hit a certain breakpoint, 
 that the text has been written.

 What is worse is its non-deterministic.
 
 That your test is non-deterministic stems from the fact that the i/o is 
 asynchronous.
 
 You would experience the same problem if your test setup was a tty in 
 loopback.
 
 Sometimes the text makes it and is displayed, so it wouldn't even be 
 practical to modify the test to make it pass.
 We wouldn't really want to do that anyway - the test is just fine on other 
 earlier SUSE, on RedHat (intel and 390), HP/UX, AIX and Solaris.
 
 There is a reason Linux is the platform of choice for scalability.
 
 Regards,
 Peter Hurley
 
 -Original Message-
 From: Michael Matz [mailto:m...@suse.de]
 Sent: 04 May 2015 13:24
 To: Peter Hurley
 Cc: NeilBrown; Nic Percival; Greg Kroah-Hartman; Jiri Slaby; 
 linux-kernel@vger.kernel.org
 Subject: Re: [PATCH bisected regression] input_available_p() sometimes says 
 'no' when it should say 'yes'

 Hi,

 On Fri, 1 May 2015, Peter Hurley wrote:

 I don't think this a real bug, in the sense that pty i/o is not 
 synchronous, in the same way that tty i/o is not synchronous.

 Here's what I wrote internally about my speculations about this being a bug 
 or not:

 I also never hit it with pipes (remove the USEPTY define), also not 
 on sle12, so it must be some change specific to the pty implementation.

 Now, all of this is of course unspecified.  There are two 
 asynchronous 

Re: [Cocci] [PATCH RFC] Coccinelle: Check for return not matching function signature

2015-05-05 Thread Julia Lawall
On Tue, 5 May 2015, Nicholas Mc Guire wrote:

 On Tue, 05 May 2015, SF Markus Elfring wrote:

   Check if the signature of a function and the return value type match.
 
  Is this a task that is usually performed by a compiler?
 
 
   In many cases this mismatch will have no side-effects
   but in some cases it may lead to hard to locate problems
 
  It is another software development challenge to find concrete
  open issues there.
 
 
   - and for readability and code understanding it is also helpful
   when types match.
 
  How would you like to check for compatible data types here?
 

 coccinelle knows the type so all you need to do is comare them in
 phython .

 
   The output is a bit lengthy - not sure if that is too much
   but it seemed useful to me to see the non-matching types explicitly
   in the warning message.
 
  How do you think about to import the result list into a database table?
 

 working on that re-cycling your parameter count example
 top 10:
 488 ssize_t != int
 195 int != unsigned int
 183 long != int
 113 int != u32
  55 int != unsigned long
  48 int != u8
  45 int != u16
  44 unsigned int != int
  37 int != s32
  30 int != long

Thanks for the specific results.  That looks very useful.

julia



 
   +if T1 != T2:
   +   print %s:%s,%s WARNING: return of wrong type (%s != %s) % 
   (p[0].file,fn,p[0].line,T1,T2)
 
  Is such a check a bit too simple?
 
 Nop - why ?
 Cocci knwow C so the assignment of types is reliable -
 flaging a s32 != int is fine with respect to readability
 even if they are technically the same.

 thx!
 hofrat
 ___
 Cocci mailing list
 co...@systeme.lip6.fr
 https://systeme.lip6.fr/mailman/listinfo/cocci

--
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] ARM: bcm2835: Use 0x4 prefix for DMA bus addresses to SDRAM.

2015-05-05 Thread Noralf Trønnes

Den 05.05.2015 02:07, skrev Eric Anholt:

Noralf Trønnes nor...@tronnes.org writes:


Den 04.05.2015 21:33, skrev Eric Anholt:

There exists a tiny MMU, configurable only by the VC (running the
closed firmware), which maps from the ARM's physical addresses to bus
addresses.  These bus addresses determine the caching behavior in the
VC's L1/L2 (note: separate from the ARM's L1/L2) according to the top
2 bits.  The bits in the bus address mean:

  From the VideoCore processor:
0x0... L1 and L2 cache allocating and coherent
0x4... L1 non-allocating, but coherent. L2 allocating and coherent
0x8... L1 non-allocating, but coherent. L2 non-allocating, but coherent
0xc... SDRAM alias. Cache is bypassed. Not L1 or L2 allocating or coherent

  From the GPU peripherals (note: all peripherals bypass the L1
cache. The ARM will see this view once through the VC MMU):
0x0... Do not use
0x4... L1 non-allocating, and incoherent. L2 allocating and coherent.
0x8... L1 non-allocating, and incoherent. L2 non-allocating, but coherent
0xc... SDRAM alias. Cache is bypassed. Not L1 or L2 allocating or coherent

The 2835 firmware always configures the MMU to turn ARM physical
addresses with 0x0 top bits to 0x4, meaning present in L2 but
incoherent with L1.  However, any bus addresses we were generating in
the kernel to be passed to a device had 0x0 bits.  That would be a
reserved (possibly totally incoherent) value if sent to a GPU
peripheral like USB, or L1 allocating if sent to the VC (like a
firmware property request).  By setting dma-ranges, all of the devices
below it get a dev-dma_pfn_offset, so that dma_alloc_coherent() and
friends return addresses with 0x4 bits and avoid cache incoherency.

This matches the behavior in the downstream 2708 kernel (see
BUS_OFFSET in arch/arm/mach-bcm2708/include/mach/memory.h).

Signed-off-by: Eric Anholt e...@anholt.net
Cc: popcorn...@gmail.com
---
   arch/arm/boot/dts/bcm2835.dtsi | 1 +
   1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi
index 5734650..2df1b5c 100644
--- a/arch/arm/boot/dts/bcm2835.dtsi
+++ b/arch/arm/boot/dts/bcm2835.dtsi
@@ -15,6 +15,7 @@
#address-cells = 1;
#size-cells = 1;
ranges = 0x7e00 0x2000 0x0200;
+   dma-ranges = 0x4000 0x 0x1f00;
   
   		timer@7e003000 {

compatible = brcm,bcm2835-system-timer;

This was quite a coincidence. I discovered the need for 'dma-ranges'
yesterday while trying to get the downstream bcm2708_fb driver to
work with ARCH_BCM2835. The driver is using the mailbox to get info
about the framebuffer from the firmware. When it failed I discovered
that the bus address was wrong.

What I don't understand, is that mmc and spi works fine with a wrong
bus address. It's only the framebuffer driver and the vchiq driver
when using mailbox that fails.

Tested-by: Noralf Trønnes nor...@tronnes.org

Yeah, it was the mailbox driver I've been trying to merge, on pi2, that
made me get this patch together.  I'm suspicious that 0x0 works the same
as 0x4 for GPU peripherals (mmc, spi, vc4) on pi1, though I've had
occasional instability (something like 3 events per ~5000 tests) that I
sure hope is due to this.


Since you mention Pi2:
Dom Cobley made me aware that 0xC is used on MACH_BCM2709.
The macros in arch/arm/mach-bcm270X/include/mach/memory.h are identical,
but arch/arm/mach-bcm2709/Kconfig has BCM2708_NOL2CACHE as default (as 
opposed to 2708/Kconfig).

This changes the _REAL_BUS_OFFSET macro:

#ifdef CONFIG_BCM2708_NOL2CACHE
 #define _REAL_BUS_OFFSET UL(0xC000)   /* don't use L1 or L2 caches */
#else
 #define _REAL_BUS_OFFSET UL(0x4000)   /* use L2 cache */
#endif


--
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] adm8211: fix checkpatch errors for indentation and new line around switch-case

2015-05-05 Thread Okash Khawaja
This patch fixes these checkpatch.pl errors around a single switch-case block:

ERROR: switch and case should be at the same indent
ERROR: trailing statements should be on next line

More specifically, the fix has been applied to the five occurances of the 
errors listed below.

ERROR: switch and case should be at the same indent
#1100: FILE: adm8211.c:1100:
+   switch (cline) {
[...]
+ default: reg |= (0x0  14);

ERROR: trailing statements should be on next line
#1101: FILE: adm8211.c:1101:
+   case  0x8: reg |= (0x1  14);

ERROR: trailing statements should be on next line
#1103: FILE: adm8211.c:1103:
+   case 0x16: reg |= (0x2  14);

ERROR: trailing statements should be on next line
#1105: FILE: adm8211.c:1105:
+   case 0x32: reg |= (0x3  14);

ERROR: trailing statements should be on next line
#1107: FILE: adm8211.c:1107:
+ default: reg |= (0x0  14);

Signed-off-by: Okash Khawaja okash.khaw...@gmail.com
---
 drivers/net/wireless/adm8211.c | 20 
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/drivers/net/wireless/adm8211.c b/drivers/net/wireless/adm8211.c
index f07a618..058fb4b 100644
--- a/drivers/net/wireless/adm8211.c
+++ b/drivers/net/wireless/adm8211.c
@@ -1098,14 +1098,18 @@ static void adm8211_hw_init(struct ieee80211_hw *dev)
pci_read_config_byte(priv-pdev, PCI_CACHE_LINE_SIZE, cline);
 
switch (cline) {
-   case  0x8: reg |= (0x1  14);
-  break;
-   case 0x16: reg |= (0x2  14);
-  break;
-   case 0x32: reg |= (0x3  14);
-  break;
- default: reg |= (0x0  14);
-  break;
+   case  0x8:
+   reg |= (0x1  14);
+   break;
+   case 0x16:
+   reg |= (0x2  14);
+   break;
+   case 0x32:
+   reg |= (0x3  14);
+   break;
+   default:
+   reg |= (0x0  14);
+   break;
}
}
 
-- 
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 7/7] arm-cci: Add aliases for PMU events

2015-05-05 Thread Suzuki K. Poulose
From: Suzuki K. Poulose suzuki.poul...@arm.com

Each CCI model have different event/source codes and formats. This
patch exports this information via the sysfs, which includes the
aliases for the events. The aliases are listed by 'perf list', helping
the users to specify the name of the event instead of the binary
config values.

Each event alias must accompany the 'source' code except for the
following cases :

1) CCI-400 - cycles event, doesn't relate to an interface.
2) CCI-500 - Global events to the CCI. (Fixed source code = 0xf)

Each CCI model provides two sets of attributes(format and event),
which are dynamically populated before registering the PMU, to
allow for the appropriate information.

Cc: Punit Agrawal punit.agra...@arm.com
Cc: Will Deacon will.dea...@arm.com
Cc: Pawel Moll pawel.m...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Signed-off-by: Suzuki K. Poulose suzuki.poul...@arm.com
---
 drivers/bus/arm-cci.c |  296 -
 1 file changed, 295 insertions(+), 1 deletion(-)

diff --git a/drivers/bus/arm-cci.c b/drivers/bus/arm-cci.c
index e12ddba..a72fccb 100644
--- a/drivers/bus/arm-cci.c
+++ b/drivers/bus/arm-cci.c
@@ -121,6 +121,10 @@ struct cci_pmu_model {
u32 fixed_hw_cntrs;
u32 num_hw_cntrs;
u32 cntr_size;
+   u64 nformat_attrs;
+   u64 nevent_attrs;
+   struct dev_ext_attribute *format_attrs;
+   struct dev_ext_attribute *event_attrs;
struct event_range event_ranges[CCI_IF_MAX];
int (*validate_hw_event)(struct cci_pmu *, unsigned long);
int (*get_event_idx)(struct cci_pmu *, struct cci_pmu_hw_events *, 
unsigned long);
@@ -157,6 +161,19 @@ enum cci_models {
CCI_MODEL_MAX
 };
 
+static ssize_t cci_pmu_format_show(struct device *dev,
+   struct device_attribute *attr, char *buf);
+static ssize_t cci_pmu_event_show(struct device *dev,
+   struct device_attribute *attr, char *buf);
+
+#define CCI_EXT_ATTR_ENTRY(_name, _func, _config) \
+   { __ATTR(_name, S_IRUGO, _func, NULL), (void *)_config }
+
+#define CCI_FORMAT_EXT_ATTR_ENTRY(_name, _config) \
+   CCI_EXT_ATTR_ENTRY(_name, cci_pmu_format_show, (char *)_config)
+#define CCI_EVENT_EXT_ATTR_ENTRY(_name, _config) \
+   CCI_EXT_ATTR_ENTRY(_name, cci_pmu_event_show, (unsigned long)_config)
+
 /* CCI400 PMU Specific definitions */
 
 #ifdef CONFIG_ARM_CCI400_PMU
@@ -218,6 +235,106 @@ enum cci400_perf_events {
 #define CCI400_R1_MASTER_PORT_MIN_EV   0x00
 #define CCI400_R1_MASTER_PORT_MAX_EV   0x11
 
+#define CCI400_CYCLE_EVENT_EXT_ATTR_ENTRY(_name, _config) \
+   CCI_EXT_ATTR_ENTRY(_name, cci400_pmu_cycle_event_show, \
+   (unsigned long)_config)
+
+static ssize_t cci400_pmu_cycle_event_show(struct device *dev,
+   struct device_attribute *attr, char *buf);
+
+static struct dev_ext_attribute cci400_pmu_format_attrs[] = {
+   CCI_FORMAT_EXT_ATTR_ENTRY(event, config:0-4),
+   CCI_FORMAT_EXT_ATTR_ENTRY(source, config:5-7),
+};
+
+static struct dev_ext_attribute cci400_r0_pmu_event_attrs[] = {
+   /* Slave events */
+   CCI_EVENT_EXT_ATTR_ENTRY(si_rrq_hs_any, 0x0),
+   CCI_EVENT_EXT_ATTR_ENTRY(si_rrq_hs_device, 0x01),
+   CCI_EVENT_EXT_ATTR_ENTRY(si_rrq_hs_normal_or_nonshareable, 0x2),
+   CCI_EVENT_EXT_ATTR_ENTRY(si_rrq_hs_inner_or_outershareable, 0x3),
+   CCI_EVENT_EXT_ATTR_ENTRY(si_rrq_hs_cache_maintenance, 0x4),
+   CCI_EVENT_EXT_ATTR_ENTRY(si_rrq_hs_mem_barrier, 0x5),
+   CCI_EVENT_EXT_ATTR_ENTRY(si_rrq_hs_sync_barrier, 0x6),
+   CCI_EVENT_EXT_ATTR_ENTRY(si_rrq_hs_dvm_msg, 0x7),
+   CCI_EVENT_EXT_ATTR_ENTRY(si_rrq_hs_dvm_msg_sync, 0x8),
+   CCI_EVENT_EXT_ATTR_ENTRY(si_rrq_stall_tt_full, 0x9),
+   CCI_EVENT_EXT_ATTR_ENTRY(si_r_data_last_hs_snoop, 0xA),
+   CCI_EVENT_EXT_ATTR_ENTRY(si_r_data_stall_rvalids_h_rready_l, 0xB),
+   CCI_EVENT_EXT_ATTR_ENTRY(si_wrq_hs_any, 0xC),
+   CCI_EVENT_EXT_ATTR_ENTRY(si_wrq_hs_device, 0xD),
+   CCI_EVENT_EXT_ATTR_ENTRY(si_wrq_hs_normal_or_nonshareable, 0xE),
+   CCI_EVENT_EXT_ATTR_ENTRY(si_wrq_hs_inner_or_outershare_wback_wclean, 
0xF),
+   CCI_EVENT_EXT_ATTR_ENTRY(si_wrq_hs_write_unique, 0x10),
+   CCI_EVENT_EXT_ATTR_ENTRY(si_wrq_hs_write_line_unique, 0x11),
+   CCI_EVENT_EXT_ATTR_ENTRY(si_wrq_hs_evict, 0x12),
+   CCI_EVENT_EXT_ATTR_ENTRY(si_wrq_stall_tt_full, 0x13),
+   /* Master events */
+   CCI_EVENT_EXT_ATTR_ENTRY(mi_retry_speculative_fetch, 0x14),
+   CCI_EVENT_EXT_ATTR_ENTRY(mi_rrq_stall_addr_hazard, 0x15),
+   CCI_EVENT_EXT_ATTR_ENTRY(mi_rrq_stall_id_hazard, 0x16),
+   CCI_EVENT_EXT_ATTR_ENTRY(mi_rrq_stall_tt_full, 0x17),
+   CCI_EVENT_EXT_ATTR_ENTRY(mi_rrq_stall_barrier_hazard, 0x18),
+   CCI_EVENT_EXT_ATTR_ENTRY(mi_wrq_stall_barrier_hazard, 0x19),
+   CCI_EVENT_EXT_ATTR_ENTRY(mi_wrq_stall_tt_full, 0x1A),
+   /* Special event for cycles counter 

[PATCH 2/2] block: loop: avoiding too many pending per work I/O

2015-05-05 Thread Ming Lei
If there are too many pending per work I/O, too many
high priority work thread can be generated so that
system performance can be effected.

This patch limits the max_active parameter of workqueue as 16.

This patch fixes Fedora 22 live booting performance
regression when it is booted from squashfs over dm
based on loop, and looks the following reasons are
related with the problem:

- not like other filesyststems(such as ext4), squashfs
is a bit special, and I observed that increasing I/O jobs
to access file in squashfs only improve I/O performance a
little, but it can make big difference for ext4

- nested loop: both squashfs.img and ext3fs.img are mounted
as loop block, and ext3fs.img is inside the squashfs

- during booting, lots of tasks may run concurrently

Fixes: b5dd2f6047ca108001328aac0e8588edd15f1778
Cc: sta...@vger.kernel.org (v4.0)
Cc: Justin M. Forbes jfor...@fedoraproject.org
Signed-off-by: Ming Lei ming@canonical.com
---
 drivers/block/loop.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index 3dc1598..1bee523 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -725,7 +725,7 @@ static int loop_set_fd(struct loop_device *lo, fmode_t mode,
goto out_putf;
error = -ENOMEM;
lo-wq = alloc_workqueue(kloopd%d,
-   WQ_MEM_RECLAIM | WQ_HIGHPRI | WQ_UNBOUND, 0,
+   WQ_MEM_RECLAIM | WQ_HIGHPRI | WQ_UNBOUND, 16,
lo-lo_number);
if (!lo-wq)
goto out_putf;
-- 
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 1/2] block: loop: convert to per-device workqueue

2015-05-05 Thread Ming Lei
Documentation/workqueue.txt:
If there is dependency among multiple work items used
during memory reclaim, they should be queued to separate
wq each with WQ_MEM_RECLAIM.

Loop devices can be stacked, so we have to convert to per-device
workqueue. One example is Fedora live CD.

Fixes: b5dd2f6047ca108001328aac0e8588edd15f1778
Cc: sta...@vger.kernel.org (v4.0)
Cc: Justin M. Forbes jfor...@fedoraproject.org
Signed-off-by: Ming Lei ming@canonical.com
---
 drivers/block/loop.c | 30 ++
 drivers/block/loop.h |  1 +
 2 files changed, 15 insertions(+), 16 deletions(-)

diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index ae3fcb4..3dc1598 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -86,8 +86,6 @@ static DEFINE_MUTEX(loop_index_mutex);
 static int max_part;
 static int part_shift;
 
-static struct workqueue_struct *loop_wq;
-
 static int transfer_xor(struct loop_device *lo, int cmd,
struct page *raw_page, unsigned raw_off,
struct page *loop_page, unsigned loop_off,
@@ -725,6 +723,12 @@ static int loop_set_fd(struct loop_device *lo, fmode_t 
mode,
size = get_loop_size(lo, file);
if ((loff_t)(sector_t)size != size)
goto out_putf;
+   error = -ENOMEM;
+   lo-wq = alloc_workqueue(kloopd%d,
+   WQ_MEM_RECLAIM | WQ_HIGHPRI | WQ_UNBOUND, 0,
+   lo-lo_number);
+   if (!lo-wq)
+   goto out_putf;
 
error = 0;
 
@@ -872,6 +876,8 @@ static int loop_clr_fd(struct loop_device *lo)
lo-lo_flags = 0;
if (!part_shift)
lo-lo_disk-flags |= GENHD_FL_NO_PART_SCAN;
+   destroy_workqueue(lo-wq);
+   lo-wq = NULL;
mutex_unlock(lo-lo_ctl_mutex);
/*
 * Need not hold lo_ctl_mutex to fput backing file.
@@ -1425,9 +1431,13 @@ static int loop_queue_rq(struct blk_mq_hw_ctx *hctx,
const struct blk_mq_queue_data *bd)
 {
struct loop_cmd *cmd = blk_mq_rq_to_pdu(bd-rq);
+   struct loop_device *lo = cmd-rq-q-queuedata;
 
blk_mq_start_request(bd-rq);
 
+   if (lo-lo_state != Lo_bound)
+   return -EIO;
+
if (cmd-rq-cmd_flags  REQ_WRITE) {
struct loop_device *lo = cmd-rq-q-queuedata;
bool need_sched = true;
@@ -1441,9 +1451,9 @@ static int loop_queue_rq(struct blk_mq_hw_ctx *hctx,
spin_unlock_irq(lo-lo_lock);
 
if (need_sched)
-   queue_work(loop_wq, lo-write_work);
+   queue_work(lo-wq, lo-write_work);
} else {
-   queue_work(loop_wq, cmd-read_work);
+   queue_work(lo-wq, cmd-read_work);
}
 
return BLK_MQ_RQ_QUEUE_OK;
@@ -1455,9 +1465,6 @@ static void loop_handle_cmd(struct loop_cmd *cmd)
struct loop_device *lo = cmd-rq-q-queuedata;
int ret = -EIO;
 
-   if (lo-lo_state != Lo_bound)
-   goto failed;
-
if (write  (lo-lo_flags  LO_FLAGS_READ_ONLY))
goto failed;
 
@@ -1806,13 +1813,6 @@ static int __init loop_init(void)
goto misc_out;
}
 
-   loop_wq = alloc_workqueue(kloopd,
-   WQ_MEM_RECLAIM | WQ_HIGHPRI | WQ_UNBOUND, 0);
-   if (!loop_wq) {
-   err = -ENOMEM;
-   goto misc_out;
-   }
-
blk_register_region(MKDEV(LOOP_MAJOR, 0), range,
  THIS_MODULE, loop_probe, NULL, NULL);
 
@@ -1850,8 +1850,6 @@ static void __exit loop_exit(void)
blk_unregister_region(MKDEV(LOOP_MAJOR, 0), range);
unregister_blkdev(LOOP_MAJOR, loop);
 
-   destroy_workqueue(loop_wq);
-
misc_deregister(loop_misc);
 }
 
diff --git a/drivers/block/loop.h b/drivers/block/loop.h
index 301c27f..49564ed 100644
--- a/drivers/block/loop.h
+++ b/drivers/block/loop.h
@@ -54,6 +54,7 @@ struct loop_device {
gfp_t   old_gfp_mask;
 
spinlock_t  lo_lock;
+   struct workqueue_struct *wq;
struct list_headwrite_cmd_head;
struct work_struct  write_work;
boolwrite_started;
-- 
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 0/2] block: loop: fix stacked loop and performance regression

2015-05-05 Thread Ming Lei
Hi,

The 1st patch convers to per-device workqueue because loop devices
can be stacked.

The 2nd patch decreases max active works as 16, so that fedora 22's
boot performance regression can be fixed.

 drivers/block/loop.c | 30 ++
 drivers/block/loop.h |  1 +
 2 files changed, 15 insertions(+), 16 deletions(-)


Thanks,
Ming Lei


--
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/9] ARM: tegra: Cardhu device-tree comment spelling fix

2015-05-05 Thread Thierry Reding
On Fri, Apr 10, 2015 at 11:35:56PM +0200, Marcel Ziswiler wrote:
 From: Marcel Ziswiler marcel.ziswi...@toradex.com
 
 Signed-off-by: Marcel Ziswiler marcel.ziswi...@toradex.com
 ---
  arch/arm/boot/dts/tegra30-cardhu.dtsi | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

I added a short commit message and applied this.

Thanks,
Thierry


pgpuKzizcHePM.pgp
Description: PGP signature


Re: [PATCH] serial/amba-pl011: fix minor bugs for pio mode

2015-05-05 Thread Leo Yan
On Tue, May 05, 2015 at 08:09:27PM +0800, Leo Yan wrote:
 On Tue, May 05, 2015 at 12:11:56PM +0100, Dave P Martin wrote:
  On Tue, May 05, 2015 at 04:00:25AM +0100, Leo Yan wrote:
  [...]
  
  Thanks for the fixes, but I already posted patches that probably fix the
  issues you are observing, And Greg took them into his tty-testing branch.
  
  Can you give them a try instead of your patches?
  
  Dave Martin (2):
Revert serial/amba-pl011: Leave the TX IRQ alone when the UART is 
  not open
serial/amba-pl011: Refactor and simplify TX FIFO handling
  
  from
  
  git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git tty-testing
  
  
  It would be good to have some feedback on them.
 
 Tested w/t your two patches, it can fix issues quite well;
 Also will back port them into local branch. Thanks u and Daniel
 pointing out this.

Sorry, fix typo:

Tested-by: Leo Yan leo@linaro.org

 Thanks,
 Leo Yan
--
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 v8 06/23] IB/Verbs: Reform IB-core multicast

2015-05-05 Thread Michael Wang
Use raw management helpers to reform IB-core multicast.

Signed-off-by: Michael Wang yun.w...@profitbricks.com
---
 drivers/infiniband/core/multicast.c | 12 +++-
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/drivers/infiniband/core/multicast.c 
b/drivers/infiniband/core/multicast.c
index fa17b55..b57ed03 100644
--- a/drivers/infiniband/core/multicast.c
+++ b/drivers/infiniband/core/multicast.c
@@ -780,8 +780,7 @@ static void mcast_event_handler(struct ib_event_handler 
*handler,
int index;
 
dev = container_of(handler, struct mcast_device, event_handler);
-   if (rdma_port_get_link_layer(dev-device, event-element.port_num) !=
-   IB_LINK_LAYER_INFINIBAND)
+   if (WARN_ON(!rdma_protocol_ib(dev-device, event-element.port_num)))
return;
 
index = event-element.port_num - dev-start_port;
@@ -808,9 +807,6 @@ static void mcast_add_one(struct ib_device *device)
int i;
int count = 0;
 
-   if (rdma_node_get_transport(device-node_type) != RDMA_TRANSPORT_IB)
-   return;
-
dev = kmalloc(sizeof *dev + device-phys_port_cnt * sizeof *port,
  GFP_KERNEL);
if (!dev)
@@ -824,8 +820,7 @@ static void mcast_add_one(struct ib_device *device)
}
 
for (i = 0; i = dev-end_port - dev-start_port; i++) {
-   if (rdma_port_get_link_layer(device, dev-start_port + i) !=
-   IB_LINK_LAYER_INFINIBAND)
+   if (!rdma_protocol_ib(device, dev-start_port + i))
continue;
port = dev-port[i];
port-dev = dev;
@@ -863,8 +858,7 @@ static void mcast_remove_one(struct ib_device *device)
flush_workqueue(mcast_wq);
 
for (i = 0; i = dev-end_port - dev-start_port; i++) {
-   if (rdma_port_get_link_layer(device, dev-start_port + i) ==
-   IB_LINK_LAYER_INFINIBAND) {
+   if (rdma_protocol_ib(device, dev-start_port + i)) {
port = dev-port[i];
deref_port(port);
wait_for_completion(port-comp);
-- 
2.1.0

--
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 v8 07/23] IB/Verbs: Reform IB-ulp ipoib

2015-05-05 Thread Michael Wang
Use raw management helpers to reform IB-ulp ipoib.

Signed-off-by: Michael Wang yun.w...@profitbricks.com
---
 drivers/infiniband/ulp/ipoib/ipoib_main.c | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/infiniband/ulp/ipoib/ipoib_main.c 
b/drivers/infiniband/ulp/ipoib/ipoib_main.c
index 7cad4dd..468fc2b 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_main.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c
@@ -1680,9 +1680,7 @@ static void ipoib_add_one(struct ib_device *device)
struct net_device *dev;
struct ipoib_dev_priv *priv;
int s, e, p;
-
-   if (rdma_node_get_transport(device-node_type) != RDMA_TRANSPORT_IB)
-   return;
+   int count = 0;
 
dev_list = kmalloc(sizeof *dev_list, GFP_KERNEL);
if (!dev_list)
@@ -1699,15 +1697,21 @@ static void ipoib_add_one(struct ib_device *device)
}
 
for (p = s; p = e; ++p) {
-   if (rdma_port_get_link_layer(device, p) != 
IB_LINK_LAYER_INFINIBAND)
+   if (!rdma_protocol_ib(device, p))
continue;
dev = ipoib_add_port(ib%d, device, p);
if (!IS_ERR(dev)) {
priv = netdev_priv(dev);
list_add_tail(priv-list, dev_list);
+   count++;
}
}
 
+   if (!count) {
+   kfree(dev_list);
+   return;
+   }
+
ib_set_client_data(device, ipoib_client, dev_list);
 }
 
@@ -1716,9 +1720,6 @@ static void ipoib_remove_one(struct ib_device *device)
struct ipoib_dev_priv *priv, *tmp;
struct list_head *dev_list;
 
-   if (rdma_node_get_transport(device-node_type) != RDMA_TRANSPORT_IB)
-   return;
-
dev_list = ib_get_client_data(device, ipoib_client);
if (!dev_list)
return;
-- 
2.1.0

--
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 v8 17/23] IB/Verbs: Use management helper rdma_cap_ib_cm()

2015-05-05 Thread Michael Wang
Introduce helper rdma_cap_ib_cm() to help us check if the port of an
IB device support Infiniband Communication Manager.

Signed-off-by: Michael Wang yun.w...@profitbricks.com
---
 drivers/infiniband/core/cm.c  |  6 +++---
 drivers/infiniband/core/cma.c | 19 +--
 drivers/infiniband/core/ucm.c |  2 +-
 include/rdma/ib_verbs.h   | 15 +++
 4 files changed, 28 insertions(+), 14 deletions(-)

diff --git a/drivers/infiniband/core/cm.c b/drivers/infiniband/core/cm.c
index add5e484..7073f98 100644
--- a/drivers/infiniband/core/cm.c
+++ b/drivers/infiniband/core/cm.c
@@ -3781,7 +3781,7 @@ static void cm_add_one(struct ib_device *ib_device)
 
set_bit(IB_MGMT_METHOD_SEND, reg_req.method_mask);
for (i = 1; i = ib_device-phys_port_cnt; i++) {
-   if (!rdma_ib_or_iboe(ib_device, i))
+   if (!rdma_cap_ib_cm(ib_device, i))
continue;
 
port = kzalloc(sizeof *port, GFP_KERNEL);
@@ -3832,7 +3832,7 @@ error1:
port_modify.set_port_cap_mask = 0;
port_modify.clr_port_cap_mask = IB_PORT_CM_SUP;
while (--i) {
-   if (!rdma_ib_or_iboe(ib_device, i))
+   if (!rdma_cap_ib_cm(ib_device, i))
continue;
 
port = cm_dev-port[i-1];
@@ -3864,7 +3864,7 @@ static void cm_remove_one(struct ib_device *ib_device)
write_unlock_irqrestore(cm.device_lock, flags);
 
for (i = 1; i = ib_device-phys_port_cnt; i++) {
-   if (!rdma_ib_or_iboe(ib_device, i))
+   if (!rdma_cap_ib_cm(ib_device, i))
continue;
 
port = cm_dev-port[i-1];
diff --git a/drivers/infiniband/core/cma.c b/drivers/infiniband/core/cma.c
index d43f492f..71a3668 100644
--- a/drivers/infiniband/core/cma.c
+++ b/drivers/infiniband/core/cma.c
@@ -745,7 +745,7 @@ int rdma_init_qp_attr(struct rdma_cm_id *id, struct 
ib_qp_attr *qp_attr,
int ret = 0;
 
id_priv = container_of(id, struct rdma_id_private, id);
-   if (rdma_ib_or_iboe(id-device, id-port_num)) {
+   if (rdma_cap_ib_cm(id-device, id-port_num)) {
if (!id_priv-cm_id.ib || (id_priv-id.qp_type == IB_QPT_UD))
ret = cma_ib_init_qp_attr(id_priv, qp_attr, 
qp_attr_mask);
else
@@ -1033,7 +1033,7 @@ void rdma_destroy_id(struct rdma_cm_id *id)
mutex_unlock(id_priv-handler_mutex);
 
if (id_priv-cma_dev) {
-   if (rdma_ib_or_iboe(id_priv-id.device, 1)) {
+   if (rdma_cap_ib_cm(id_priv-id.device, 1)) {
if (id_priv-cm_id.ib)
ib_destroy_cm_id(id_priv-cm_id.ib);
} else if (rdma_protocol_iwarp(id_priv-id.device, 1)) {
@@ -1616,8 +1616,7 @@ static void cma_listen_on_dev(struct rdma_id_private 
*id_priv,
struct rdma_cm_id *id;
int ret;
 
-   if (cma_family(id_priv) == AF_IB 
-   !rdma_ib_or_iboe(cma_dev-device, 1))
+   if (cma_family(id_priv) == AF_IB  !rdma_cap_ib_cm(cma_dev-device, 1))
return;
 
id = rdma_create_id(cma_listen_handler, id_priv, id_priv-id.ps,
@@ -2008,7 +2007,7 @@ static int cma_bind_loopback(struct rdma_id_private 
*id_priv)
mutex_lock(lock);
list_for_each_entry(cur_dev, dev_list, list) {
if (cma_family(id_priv) == AF_IB 
-   !rdma_ib_or_iboe(cur_dev-device, 1))
+   !rdma_cap_ib_cm(cur_dev-device, 1))
continue;
 
if (!cma_dev)
@@ -2517,7 +2516,7 @@ int rdma_listen(struct rdma_cm_id *id, int backlog)
 
id_priv-backlog = backlog;
if (id-device) {
-   if (rdma_ib_or_iboe(id-device, 1)) {
+   if (rdma_cap_ib_cm(id-device, 1)) {
ret = cma_ib_listen(id_priv);
if (ret)
goto err;
@@ -2861,7 +2860,7 @@ int rdma_connect(struct rdma_cm_id *id, struct 
rdma_conn_param *conn_param)
id_priv-srq = conn_param-srq;
}
 
-   if (rdma_ib_or_iboe(id-device, id-port_num)) {
+   if (rdma_cap_ib_cm(id-device, id-port_num)) {
if (id-qp_type == IB_QPT_UD)
ret = cma_resolve_ib_udp(id_priv, conn_param);
else
@@ -2972,7 +2971,7 @@ int rdma_accept(struct rdma_cm_id *id, struct 
rdma_conn_param *conn_param)
id_priv-srq = conn_param-srq;
}
 
-   if (rdma_ib_or_iboe(id-device, id-port_num)) {
+   if (rdma_cap_ib_cm(id-device, id-port_num)) {
if (id-qp_type == IB_QPT_UD) {
if (conn_param)
ret = cma_send_sidr_rep(id_priv, 
IB_SIDR_SUCCESS,
@@ -3035,7 +3034,7 @@ int rdma_reject(struct rdma_cm_id *id, const void 
*private_data,
if (!id_priv-cm_id.ib)
return -EINVAL;
 
-   if (rdma_ib_or_iboe(id-device, id-port_num)) 

[PATCH v8 18/23] IB/Verbs: Use management helper rdma_cap_iw_cm()

2015-05-05 Thread Michael Wang
Introduce helper rdma_cap_iw_cm() to help us check if the port of an
IB device support IWARP Communication Manager.

Signed-off-by: Michael Wang yun.w...@profitbricks.com
---
 drivers/infiniband/core/cma.c | 14 +++---
 include/rdma/ib_verbs.h   | 15 +++
 2 files changed, 22 insertions(+), 7 deletions(-)

diff --git a/drivers/infiniband/core/cma.c b/drivers/infiniband/core/cma.c
index 71a3668..0787035 100644
--- a/drivers/infiniband/core/cma.c
+++ b/drivers/infiniband/core/cma.c
@@ -754,7 +754,7 @@ int rdma_init_qp_attr(struct rdma_cm_id *id, struct 
ib_qp_attr *qp_attr,
 
if (qp_attr-qp_state == IB_QPS_RTR)
qp_attr-rq_psn = id_priv-seq_num;
-   } else if (rdma_protocol_iwarp(id-device, id-port_num)) {
+   } else if (rdma_cap_iw_cm(id-device, id-port_num)) {
if (!id_priv-cm_id.iw) {
qp_attr-qp_access_flags = 0;
*qp_attr_mask = IB_QP_STATE | IB_QP_ACCESS_FLAGS;
@@ -1036,7 +1036,7 @@ void rdma_destroy_id(struct rdma_cm_id *id)
if (rdma_cap_ib_cm(id_priv-id.device, 1)) {
if (id_priv-cm_id.ib)
ib_destroy_cm_id(id_priv-cm_id.ib);
-   } else if (rdma_protocol_iwarp(id_priv-id.device, 1)) {
+   } else if (rdma_cap_iw_cm(id_priv-id.device, 1)) {
if (id_priv-cm_id.iw)
iw_destroy_cm_id(id_priv-cm_id.iw);
}
@@ -2520,7 +2520,7 @@ int rdma_listen(struct rdma_cm_id *id, int backlog)
ret = cma_ib_listen(id_priv);
if (ret)
goto err;
-   } else if (rdma_protocol_iwarp(id-device, 1)) {
+   } else if (rdma_cap_iw_cm(id-device, 1)) {
ret = cma_iw_listen(id_priv, backlog);
if (ret)
goto err;
@@ -2865,7 +2865,7 @@ int rdma_connect(struct rdma_cm_id *id, struct 
rdma_conn_param *conn_param)
ret = cma_resolve_ib_udp(id_priv, conn_param);
else
ret = cma_connect_ib(id_priv, conn_param);
-   } else if (rdma_protocol_iwarp(id-device, id-port_num))
+   } else if (rdma_cap_iw_cm(id-device, id-port_num))
ret = cma_connect_iw(id_priv, conn_param);
else
ret = -ENOSYS;
@@ -2987,7 +2987,7 @@ int rdma_accept(struct rdma_cm_id *id, struct 
rdma_conn_param *conn_param)
else
ret = cma_rep_recv(id_priv);
}
-   } else if (rdma_protocol_iwarp(id-device, id-port_num))
+   } else if (rdma_cap_iw_cm(id-device, id-port_num))
ret = cma_accept_iw(id_priv, conn_param);
else
ret = -ENOSYS;
@@ -3042,7 +3042,7 @@ int rdma_reject(struct rdma_cm_id *id, const void 
*private_data,
ret = ib_send_cm_rej(id_priv-cm_id.ib,
 IB_CM_REJ_CONSUMER_DEFINED, NULL,
 0, private_data, private_data_len);
-   } else if (rdma_protocol_iwarp(id-device, id-port_num)) {
+   } else if (rdma_cap_iw_cm(id-device, id-port_num)) {
ret = iw_cm_reject(id_priv-cm_id.iw,
   private_data, private_data_len);
} else
@@ -3068,7 +3068,7 @@ int rdma_disconnect(struct rdma_cm_id *id)
/* Initiate or respond to a disconnect. */
if (ib_send_cm_dreq(id_priv-cm_id.ib, NULL, 0))
ib_send_cm_drep(id_priv-cm_id.ib, NULL, 0);
-   } else if (rdma_protocol_iwarp(id-device, id-port_num)) {
+   } else if (rdma_cap_iw_cm(id-device, id-port_num)) {
ret = iw_cm_disconnect(id_priv-cm_id.iw, 0);
} else
ret = -EINVAL;
diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
index e349596..cc92a64 100644
--- a/include/rdma/ib_verbs.h
+++ b/include/rdma/ib_verbs.h
@@ -1819,6 +1819,21 @@ static inline bool rdma_cap_ib_cm(struct ib_device 
*device, u8 port_num)
return rdma_ib_or_iboe(device, port_num);
 }
 
+/**
+ * rdma_cap_iw_cm - Check if the port of device has the capability IWARP
+ * Communication Manager.
+ *
+ * @device: Device to be checked
+ * @port_num: Port number of the device
+ *
+ * Return false when port of the device don't support IWARP
+ * Communication Manager.
+ */
+static inline bool rdma_cap_iw_cm(struct ib_device *device, u8 port_num)
+{
+   return rdma_protocol_iwarp(device, port_num);
+}
+
 int ib_query_gid(struct ib_device *device,
 u8 port_num, int index, union ib_gid *gid);
 
-- 
2.1.0

--
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

[PATCH v8 16/23] IB/Verbs: Use management helper rdma_cap_ib_smi()

2015-05-05 Thread Michael Wang
Introduce helper rdma_cap_ib_smi() to help us check if the port of an
IB device support Infiniband Subnet Management Interface.

Signed-off-by: Michael Wang yun.w...@profitbricks.com
---
 drivers/infiniband/core/agent.c |  2 +-
 drivers/infiniband/core/mad.c   |  2 +-
 include/rdma/ib_verbs.h | 15 +++
 3 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/drivers/infiniband/core/agent.c b/drivers/infiniband/core/agent.c
index 89d4fbc..a6fc4d6 100644
--- a/drivers/infiniband/core/agent.c
+++ b/drivers/infiniband/core/agent.c
@@ -156,7 +156,7 @@ int ib_agent_port_open(struct ib_device *device, int 
port_num)
goto error1;
}
 
-   if (rdma_protocol_ib(device, port_num)) {
+   if (rdma_cap_ib_smi(device, port_num)) {
/* Obtain send only MAD agent for SMI QP */
port_priv-agent[0] = ib_register_mad_agent(device, port_num,
IB_QPT_SMI, NULL, 0,
diff --git a/drivers/infiniband/core/mad.c b/drivers/infiniband/core/mad.c
index 80777cd..e9699c9 100644
--- a/drivers/infiniband/core/mad.c
+++ b/drivers/infiniband/core/mad.c
@@ -2938,7 +2938,7 @@ static int ib_mad_port_open(struct ib_device *device,
init_mad_qp(port_priv, port_priv-qp_info[1]);
 
cq_size = mad_sendq_size + mad_recvq_size;
-   has_smi = rdma_protocol_ib(device, port_num);
+   has_smi = rdma_cap_ib_smi(device, port_num);
if (has_smi)
cq_size *= 2;
 
diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
index 23ba66e..e983e33 100644
--- a/include/rdma/ib_verbs.h
+++ b/include/rdma/ib_verbs.h
@@ -1789,6 +1789,21 @@ static inline bool rdma_cap_ib_mad(struct ib_device 
*device, u8 port_num)
return rdma_ib_or_iboe(device, port_num);
 }
 
+/**
+ * rdma_cap_ib_smi - Check if the port of device has the capability Infiniband
+ * Subnet Management Interface.
+ *
+ * @device: Device to be checked
+ * @port_num: Port number of the device
+ *
+ * Return false when port of the device don't support Infiniband
+ * Subnet Management Interface.
+ */
+static inline bool rdma_cap_ib_smi(struct ib_device *device, u8 port_num)
+{
+   return rdma_protocol_ib(device, port_num);
+}
+
 int ib_query_gid(struct ib_device *device,
 u8 port_num, int index, union ib_gid *gid);
 
-- 
2.1.0

--
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 v8 20/23] IB/Verbs: Use management helper rdma_cap_ib_mcast()

2015-05-05 Thread Michael Wang
Introduce helper rdma_cap_ib_mcast() to help us check if the port of an
IB device support Infiniband Multicast.

Signed-off-by: Michael Wang yun.w...@profitbricks.com
---
 drivers/infiniband/core/cma.c   |  6 +++---
 drivers/infiniband/core/multicast.c |  6 +++---
 include/rdma/ib_verbs.h | 15 +++
 3 files changed, 21 insertions(+), 6 deletions(-)

diff --git a/drivers/infiniband/core/cma.c b/drivers/infiniband/core/cma.c
index 8def2f5..101e9cc 100644
--- a/drivers/infiniband/core/cma.c
+++ b/drivers/infiniband/core/cma.c
@@ -1007,7 +1007,7 @@ static void cma_leave_mc_groups(struct rdma_id_private 
*id_priv)
mc = container_of(id_priv-mc_list.next,
  struct cma_multicast, list);
list_del(mc-list);
-   if (rdma_protocol_ib(id_priv-cma_dev-device,
+   if (rdma_cap_ib_mcast(id_priv-cma_dev-device,
  id_priv-id.port_num)) {
ib_sa_free_multicast(mc-multicast.ib);
kfree(mc);
@@ -3321,7 +3321,7 @@ int rdma_join_multicast(struct rdma_cm_id *id, struct 
sockaddr *addr,
if (rdma_protocol_iboe(id-device, id-port_num)) {
kref_init(mc-mcref);
ret = cma_iboe_join_multicast(id_priv, mc);
-   } else if (rdma_protocol_ib(id-device, id-port_num))
+   } else if (rdma_cap_ib_mcast(id-device, id-port_num))
ret = cma_join_ib_multicast(id_priv, mc);
else
ret = -ENOSYS;
@@ -3355,7 +3355,7 @@ void rdma_leave_multicast(struct rdma_cm_id *id, struct 
sockaddr *addr)
 
BUG_ON(id_priv-cma_dev-device != id-device);
 
-   if (rdma_protocol_ib(id-device, id-port_num)) {
+   if (rdma_cap_ib_mcast(id-device, id-port_num)) {
ib_sa_free_multicast(mc-multicast.ib);
kfree(mc);
} else if (rdma_protocol_iboe(id-device, id-port_num))
diff --git a/drivers/infiniband/core/multicast.c 
b/drivers/infiniband/core/multicast.c
index b57ed03..605f20a 100644
--- a/drivers/infiniband/core/multicast.c
+++ b/drivers/infiniband/core/multicast.c
@@ -780,7 +780,7 @@ static void mcast_event_handler(struct ib_event_handler 
*handler,
int index;
 
dev = container_of(handler, struct mcast_device, event_handler);
-   if (WARN_ON(!rdma_protocol_ib(dev-device, event-element.port_num)))
+   if (WARN_ON(!rdma_cap_ib_mcast(dev-device, event-element.port_num)))
return;
 
index = event-element.port_num - dev-start_port;
@@ -820,7 +820,7 @@ static void mcast_add_one(struct ib_device *device)
}
 
for (i = 0; i = dev-end_port - dev-start_port; i++) {
-   if (!rdma_protocol_ib(device, dev-start_port + i))
+   if (!rdma_cap_ib_mcast(device, dev-start_port + i))
continue;
port = dev-port[i];
port-dev = dev;
@@ -858,7 +858,7 @@ static void mcast_remove_one(struct ib_device *device)
flush_workqueue(mcast_wq);
 
for (i = 0; i = dev-end_port - dev-start_port; i++) {
-   if (rdma_protocol_ib(device, dev-start_port + i)) {
+   if (rdma_cap_ib_mcast(device, dev-start_port + i)) {
port = dev-port[i];
deref_port(port);
wait_for_completion(port-comp);
diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
index c3a561e8..6bbbc86 100644
--- a/include/rdma/ib_verbs.h
+++ b/include/rdma/ib_verbs.h
@@ -1849,6 +1849,21 @@ static inline bool rdma_cap_ib_sa(struct ib_device 
*device, u8 port_num)
return rdma_protocol_ib(device, port_num);
 }
 
+/**
+ * rdma_cap_ib_mcast - Check if the port of device has the capability 
Infiniband
+ * Multicast.
+ *
+ * @device: Device to be checked
+ * @port_num: Port number of the device
+ *
+ * Return false when port of the device don't support Infiniband
+ * Multicast.
+ */
+static inline bool rdma_cap_ib_mcast(struct ib_device *device, u8 port_num)
+{
+   return rdma_cap_ib_sa(device, port_num);
+}
+
 int ib_query_gid(struct ib_device *device,
 u8 port_num, int index, union ib_gid *gid);
 
-- 
2.1.0

--
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 v8 19/23] IB/Verbs: Use management helper rdma_cap_ib_sa()

2015-05-05 Thread Michael Wang
Introduce helper rdma_cap_ib_sa() to help us check if the port of an
IB device support Infiniband Subnet Administration.

Signed-off-by: Michael Wang yun.w...@profitbricks.com
---
 drivers/infiniband/core/cma.c  |  4 ++--
 drivers/infiniband/core/sa_query.c | 10 +-
 drivers/infiniband/core/ucma.c |  2 +-
 include/rdma/ib_verbs.h| 15 +++
 4 files changed, 23 insertions(+), 8 deletions(-)

diff --git a/drivers/infiniband/core/cma.c b/drivers/infiniband/core/cma.c
index 0787035..8def2f5 100644
--- a/drivers/infiniband/core/cma.c
+++ b/drivers/infiniband/core/cma.c
@@ -933,7 +933,7 @@ static inline int cma_user_data_offset(struct 
rdma_id_private *id_priv)
 
 static void cma_cancel_route(struct rdma_id_private *id_priv)
 {
-   if (rdma_protocol_ib(id_priv-id.device, id_priv-id.port_num)) {
+   if (rdma_cap_ib_sa(id_priv-id.device, id_priv-id.port_num)) {
if (id_priv-query)
ib_sa_cancel_query(id_priv-query_id, id_priv-query);
}
@@ -1957,7 +1957,7 @@ int rdma_resolve_route(struct rdma_cm_id *id, int 
timeout_ms)
return -EINVAL;
 
atomic_inc(id_priv-refcount);
-   if (rdma_protocol_ib(id-device, id-port_num))
+   if (rdma_cap_ib_sa(id-device, id-port_num))
ret = cma_resolve_ib_route(id_priv, timeout_ms);
else if (rdma_protocol_iboe(id-device, id-port_num))
ret = cma_resolve_iboe_route(id_priv);
diff --git a/drivers/infiniband/core/sa_query.c 
b/drivers/infiniband/core/sa_query.c
index b115c28..30aa5e5 100644
--- a/drivers/infiniband/core/sa_query.c
+++ b/drivers/infiniband/core/sa_query.c
@@ -450,7 +450,7 @@ static void ib_sa_event(struct ib_event_handler *handler, 
struct ib_event *event
struct ib_sa_port *port =
sa_dev-port[event-element.port_num - 
sa_dev-start_port];
 
-   if (WARN_ON(!rdma_protocol_ib(handler-device, port-port_num)))
+   if (WARN_ON(!rdma_cap_ib_sa(handler-device, port-port_num)))
return;
 
spin_lock_irqsave(port-ah_lock, flags);
@@ -1173,7 +1173,7 @@ static void ib_sa_add_one(struct ib_device *device)
 
for (i = 0; i = e - s; ++i) {
spin_lock_init(sa_dev-port[i].ah_lock);
-   if (!rdma_protocol_ib(device, i + 1))
+   if (!rdma_cap_ib_sa(device, i + 1))
continue;
 
sa_dev-port[i].sm_ah= NULL;
@@ -1208,7 +1208,7 @@ static void ib_sa_add_one(struct ib_device *device)
goto err;
 
for (i = 0; i = e - s; ++i) {
-   if (rdma_protocol_ib(device, i + 1))
+   if (rdma_cap_ib_sa(device, i + 1))
update_sm_ah(sa_dev-port[i].update_task);
}
 
@@ -1216,7 +1216,7 @@ static void ib_sa_add_one(struct ib_device *device)
 
 err:
while (--i = 0) {
-   if (rdma_protocol_ib(device, i + 1))
+   if (rdma_cap_ib_sa(device, i + 1))
ib_unregister_mad_agent(sa_dev-port[i].agent);
}
 free:
@@ -1237,7 +1237,7 @@ static void ib_sa_remove_one(struct ib_device *device)
flush_workqueue(ib_wq);
 
for (i = 0; i = sa_dev-end_port - sa_dev-start_port; ++i) {
-   if (rdma_protocol_ib(device, i + 1)) {
+   if (rdma_cap_ib_sa(device, i + 1)) {
ib_unregister_mad_agent(sa_dev-port[i].agent);
if (sa_dev-port[i].sm_ah)
kref_put(sa_dev-port[i].sm_ah-ref, 
free_sm_ah);
diff --git a/drivers/infiniband/core/ucma.c b/drivers/infiniband/core/ucma.c
index dae7620..d42b816 100644
--- a/drivers/infiniband/core/ucma.c
+++ b/drivers/infiniband/core/ucma.c
@@ -723,7 +723,7 @@ static ssize_t ucma_query_route(struct ucma_file *file,
resp.node_guid = (__force __u64) ctx-cm_id-device-node_guid;
resp.port_num = ctx-cm_id-port_num;
 
-   if (rdma_protocol_ib(ctx-cm_id-device, ctx-cm_id-port_num))
+   if (rdma_cap_ib_sa(ctx-cm_id-device, ctx-cm_id-port_num))
ucma_copy_ib_route(resp, ctx-cm_id-route);
else if (rdma_protocol_iboe(ctx-cm_id-device, ctx-cm_id-port_num))
ucma_copy_iboe_route(resp, ctx-cm_id-route);
diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
index cc92a64..c3a561e8 100644
--- a/include/rdma/ib_verbs.h
+++ b/include/rdma/ib_verbs.h
@@ -1834,6 +1834,21 @@ static inline bool rdma_cap_iw_cm(struct ib_device 
*device, u8 port_num)
return rdma_protocol_iwarp(device, port_num);
 }
 
+/**
+ * rdma_cap_ib_sa - Check if the port of device has the capability Infiniband
+ * Subnet Administration.
+ *
+ * @device: Device to be checked
+ * @port_num: Port number of the device
+ *
+ * Return false when port of the device don't support Infiniband
+ * Subnet Administration.
+ */
+static inline bool rdma_cap_ib_sa(struct ib_device *device, u8 port_num)

[PATCH v8 23/23] IB/Verbs: Use management helper rdma_cap_eth_ah()

2015-05-05 Thread Michael Wang
Introduce helper rdma_cap_eth_ah() to help us check if the port of an
IB device support Ethernet Address Handler.

Signed-off-by: Michael Wang yun.w...@profitbricks.com
---
 drivers/infiniband/core/cma.c  |  2 +-
 drivers/infiniband/core/sa_query.c |  2 +-
 drivers/infiniband/core/verbs.c|  4 ++--
 include/rdma/ib_verbs.h| 15 +++
 4 files changed, 19 insertions(+), 4 deletions(-)

diff --git a/drivers/infiniband/core/cma.c b/drivers/infiniband/core/cma.c
index a6cbf42..0a3e859 100644
--- a/drivers/infiniband/core/cma.c
+++ b/drivers/infiniband/core/cma.c
@@ -711,7 +711,7 @@ static int cma_ib_init_qp_attr(struct rdma_id_private 
*id_priv,
int ret;
u16 pkey;
 
-   if (rdma_protocol_iboe(id_priv-id.device, id_priv-id.port_num))
+   if (rdma_cap_eth_ah(id_priv-id.device, id_priv-id.port_num))
pkey = 0x;
else
pkey = ib_addr_get_pkey(dev_addr);
diff --git a/drivers/infiniband/core/sa_query.c 
b/drivers/infiniband/core/sa_query.c
index 30aa5e5..7f7c8c9 100644
--- a/drivers/infiniband/core/sa_query.c
+++ b/drivers/infiniband/core/sa_query.c
@@ -540,7 +540,7 @@ int ib_init_ah_from_path(struct ib_device *device, u8 
port_num,
ah_attr-port_num = port_num;
ah_attr-static_rate = rec-rate;
 
-   force_grh = rdma_protocol_iboe(device, port_num);
+   force_grh = rdma_cap_eth_ah(device, port_num);
 
if (rec-hop_limit  1 || force_grh) {
ah_attr-ah_flags = IB_AH_GRH;
diff --git a/drivers/infiniband/core/verbs.c b/drivers/infiniband/core/verbs.c
index 7dd2f51..d110a5e 100644
--- a/drivers/infiniband/core/verbs.c
+++ b/drivers/infiniband/core/verbs.c
@@ -200,7 +200,7 @@ int ib_init_ah_from_wc(struct ib_device *device, u8 
port_num, struct ib_wc *wc,
int ret;
 
memset(ah_attr, 0, sizeof *ah_attr);
-   if (rdma_protocol_iboe(device, port_num)) {
+   if (rdma_cap_eth_ah(device, port_num)) {
if (!(wc-wc_flags  IB_WC_GRH))
return -EPROTOTYPE;
 
@@ -869,7 +869,7 @@ int ib_resolve_eth_l2_attrs(struct ib_qp *qp,
union ib_gid  sgid;
 
if ((*qp_attr_mask  IB_QP_AV)  
-   (rdma_protocol_iboe(qp-device, qp_attr-ah_attr.port_num))) {
+   (rdma_cap_eth_ah(qp-device, qp_attr-ah_attr.port_num))) {
ret = ib_query_gid(qp-device, qp_attr-ah_attr.port_num,
   qp_attr-ah_attr.grh.sgid_index, sgid);
if (ret)
diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
index 41f8445..721c378 100644
--- a/include/rdma/ib_verbs.h
+++ b/include/rdma/ib_verbs.h
@@ -1880,6 +1880,21 @@ static inline bool rdma_cap_af_ib(struct ib_device 
*device, u8 port_num)
 }
 
 /**
+ * rdma_cap_eth_ah - Check if the port of device has the capability
+ * Ethernet Address Handler.
+ *
+ * @device: Device to be checked
+ * @port_num: Port number of the device
+ *
+ * Return false when port of the device don't support
+ * Ethernet Address Handler.
+ */
+static inline bool rdma_cap_eth_ah(struct ib_device *device, u8 port_num)
+{
+   return rdma_protocol_iboe(device, port_num);
+}
+
+/**
  * rdma_cap_read_multi_sge - Check if the port of device has the capability
  * RDMA Read Multiple Scatter-Gather Entries.
  *
-- 
2.1.0

--
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 v8 21/23] IB/Verbs: Use management helper rdma_cap_read_multi_sge()

2015-05-05 Thread Michael Wang
Introduce helper rdma_cap_read_multi_sge() to help us check if the port of an
IB device support RDMA Read Multiple Scatter-Gather Entries.

Signed-off-by: Michael Wang yun.w...@profitbricks.com
---
 include/rdma/ib_verbs.h | 16 
 net/sunrpc/xprtrdma/svc_rdma_recvfrom.c |  4 ++--
 2 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
index 6bbbc86..2cf23b1 100644
--- a/include/rdma/ib_verbs.h
+++ b/include/rdma/ib_verbs.h
@@ -1864,6 +1864,22 @@ static inline bool rdma_cap_ib_mcast(struct ib_device 
*device, u8 port_num)
return rdma_cap_ib_sa(device, port_num);
 }
 
+/**
+ * rdma_cap_read_multi_sge - Check if the port of device has the capability
+ * RDMA Read Multiple Scatter-Gather Entries.
+ *
+ * @device: Device to be checked
+ * @port_num: Port number of the device
+ *
+ * Return false when port of the device don't support
+ * RDMA Read Multiple Scatter-Gather Entries.
+ */
+static inline bool rdma_cap_read_multi_sge(struct ib_device *device,
+  u8 port_num)
+{
+   return !rdma_protocol_iwarp(device, port_num);
+}
+
 int ib_query_gid(struct ib_device *device,
 u8 port_num, int index, union ib_gid *gid);
 
diff --git a/net/sunrpc/xprtrdma/svc_rdma_recvfrom.c 
b/net/sunrpc/xprtrdma/svc_rdma_recvfrom.c
index 2cc625d..86b4416 100644
--- a/net/sunrpc/xprtrdma/svc_rdma_recvfrom.c
+++ b/net/sunrpc/xprtrdma/svc_rdma_recvfrom.c
@@ -117,8 +117,8 @@ static void rdma_build_arg_xdr(struct svc_rqst *rqstp,
 
 static int rdma_read_max_sge(struct svcxprt_rdma *xprt, int sge_count)
 {
-   if (rdma_protocol_iwarp(xprt-sc_cm_id-device,
-   xprt-sc_cm_id-port_num))
+   if (!rdma_cap_read_multi_sge(xprt-sc_cm_id-device,
+xprt-sc_cm_id-port_num))
return 1;
else
return min_t(int, sge_count, xprt-sc_max_sge);
-- 
2.1.0

--
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 v8 22/23] IB/Verbs: Use management helper rdma_cap_af_ib()

2015-05-05 Thread Michael Wang
Introduce helper rdma_cap_af_ib() to help us check if the port of an
IB device support Native Infiniband Address.

Signed-off-by: Michael Wang yun.w...@profitbricks.com
---
 drivers/infiniband/core/cma.c |  2 +-
 include/rdma/ib_verbs.h   | 15 +++
 2 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/drivers/infiniband/core/cma.c b/drivers/infiniband/core/cma.c
index 101e9cc..a6cbf42 100644
--- a/drivers/infiniband/core/cma.c
+++ b/drivers/infiniband/core/cma.c
@@ -448,7 +448,7 @@ static int cma_resolve_ib_dev(struct rdma_id_private 
*id_priv)
 
list_for_each_entry(cur_dev, dev_list, list) {
for (p = 1; p = cur_dev-device-phys_port_cnt; ++p) {
-   if (!rdma_ib_or_iboe(cur_dev-device, p))
+   if (!rdma_cap_af_ib(cur_dev-device, p))
continue;
 
if (ib_find_cached_pkey(cur_dev-device, p, pkey, 
index))
diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
index ac1e7f1..41f8445 100644
--- a/include/rdma/ib_verbs.h
+++ b/include/rdma/ib_verbs.h
@@ -1865,6 +1865,21 @@ static inline bool rdma_cap_ib_mcast(struct ib_device 
*device, u8 port_num)
 }
 
 /**
+ * rdma_cap_af_ib - Check if the port of device has the capability
+ * Native Infiniband Address.
+ *
+ * @device: Device to be checked
+ * @port_num: Port number of the device
+ *
+ * Return false when port of the device don't support
+ * Native Infiniband Address.
+ */
+static inline bool rdma_cap_af_ib(struct ib_device *device, u8 port_num)
+{
+   return rdma_ib_or_iboe(device, port_num);
+}
+
+/**
  * rdma_cap_read_multi_sge - Check if the port of device has the capability
  * RDMA Read Multiple Scatter-Gather Entries.
  *
-- 
2.1.0

--
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 v2 0/3] leds: blink resolution improvements

2015-05-05 Thread Stas Sergeev

05.05.2015 11:22, Jacek Anaszewski пишет:

On 05/04/2015 07:20 PM, Stas Sergeev wrote:

04.05.2015 18:22, Jacek Anaszewski пишет:

On 05/04/2015 02:12 PM, Stas Sergeev wrote:

Only under that condition:
---
if (led_cdev-blink_delay_on || led_cdev-blink_delay_off) {
 led_cdev-delayed_set_value = brightness;
schedule_work(led_cdev-set_brightness_work);
---

But the main condition is:
---
if (led_cdev-flags  SET_BRIGHTNESS_ASYNC) {
 led_set_brightness_async(led_cdev, brightness);
---

So I think it is actually unused.
I don't see why schedule_work() above can't be just replaced
with led_set_brightness_async(). Is there the reason not to do so?

set_brightness_work not only sets the brightness but also
stops software blinking, which was the primary reason
for adding this work queue I think. Here is the commit message:

But led_trigger_set() does led_stop_software_blink(), which
IMHO means led_set_brightness() will in most cases be called
when sw blocking is already stopped. There seem to be just a
few cases where this is not true: oneshot_trig_deactivate() and
timer_trig_deactivate(), and I think I'll just change these two to
led_stop_software_blink(). I am pretty sure the work-queue is
not needed, but I'll have to test that with the patch it seems.

It is used e.g. in the following case:

#echo timer  trigger
#echo 1  brightness

Indeed, thanks.
I'll study that case next week when my board is back to me.
Looking at sources, it seems in that case it would disable the
software blinking (del_timer_sync()) without changing the
trigger back to none, which does not make sense to me.






 Now your leds-aat1290 already asks for such a change,

because it can sleep but does not use a work-queue the
way other drivers do.

It doesn't need this change - it defines two ops: brightness_set
(the async one) and brightness_set_sync (the sync one). The
former is called from led_set_brightness_async and the latter
form led_set_brightness_sync.
led_set_brightness_async is called from led_set_brightness
for drivers that define SET_BRIGHTNESS_ASYNC flag and
led_set_brightness_sync for the drivers that define
SET_BRIGHTNESS_SYNC flags.

led_timer_function calls always led_set_brightness_async.

OK, I googled the patch:
https://lkml.org/lkml/2015/3/4/960
So the async one uses the work-queue, and the sync one
does not. Since led_timer_function calls always 
led_set_brightness_async,

it should always be using a work-queue.
But then I fail to explain your diagnostic that with my patch and
your driver, the hrtimer gives warning about a high interrupt
latency. I thought this is because your driver does sleeps and
does not use a work queue. Its not the case. Could you please
clarify, what then caused the high interrupt latency warning in
your testing?

An accurate explanation would require thorough investigation.
It can be related to the fact that the driver uses delays.

Even if your driver just does schedule_work() and nothing
more in an async method? Strange.


In the first place we have to take into account that Linux is not
a real time operating system. The feature you're trying to implement
is realized by hardware with use of pwm. There might be narrow group
of drivers that could benefit from it in specific circumstances
(the system couldn't be too busy at the time when timer trigger is
running), but this is too weak argument in favour of supporting small
delay intervals.

If you mean the drivers that don't have any sleeps, then the
system load is irrelevant because the hrtimer callback is AFAIK
running in an irq context. So for them it would be a clear win,
not just in a specific circumstances. Of course I wonder if it is
only leds-gpio, or anything else too. :) Though I could suspect
that leds-gpio have a very wide usage, and it may worth the
troubles even to improve just leds-gpio alone.
--
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 v2 3/7] ACPI / processor: Introduce invalid_logical_cpuid()

2015-05-05 Thread Hanjun Guo

On 2015年05月05日 20:01, Rafael J. Wysocki wrote:

On Tuesday, May 05, 2015 10:46:34 AM Hanjun Guo wrote:

In ACPI processor drivers, we use direct comparisons of cpu logical
id with -1 which are error prone in case logical cpuid is accidentally
assinged an error code and prevents us from returning an error-encoding
cpuid directly in some cases.

So introduce invalid_logical_cpuid() to identify cpu with invalid
logical cpu num, then it will be used to replace the direct comparisons
with -1.

Signed-off-by: Hanjun Guo hanjun@linaro.org
---
  drivers/acpi/acpi_processor.c | 4 ++--
  drivers/acpi/processor_pdc.c  | 5 +
  include/linux/acpi.h  | 5 +
  3 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
index 95492d0..62c846b 100644
--- a/drivers/acpi/acpi_processor.c
+++ b/drivers/acpi/acpi_processor.c
@@ -274,7 +274,7 @@ static int acpi_processor_get_info(struct acpi_device 
*device)
 * Handle UP system running SMP kernel, with no CPU
 * entry in MADT
 */
-   if ((pr-id == -1)  (num_online_cpus() == 1))
+   if (invalid_logical_cpuid(pr-id)  (num_online_cpus() == 1))
pr-id = 0;
}

@@ -283,7 +283,7 @@ static int acpi_processor_get_info(struct acpi_device 
*device)
 *  less than the max # of CPUs. They should be ignored _iff
 *  they are physically not present.
 */
-   if (pr-id == -1) {
+   if (invalid_logical_cpuid(pr-id)) {
int ret = acpi_processor_hotadd_init(pr);
if (ret)
return ret;
diff --git a/drivers/acpi/processor_pdc.c b/drivers/acpi/processor_pdc.c
index e5dd808..6dd98d0 100644
--- a/drivers/acpi/processor_pdc.c
+++ b/drivers/acpi/processor_pdc.c
@@ -52,10 +52,7 @@ static bool __init processor_physically_present(acpi_handle 
handle)
type = (acpi_type == ACPI_TYPE_DEVICE) ? 1 : 0;
cpuid = acpi_get_cpuid(handle, type, acpi_id);

-   if (cpuid == -1)
-   return false;
-
-   return true;
+   return invalid_logical_cpuid(cpuid) ? false : true;


What about

return !invalid_logical_cpuid(cpuid);


yes, cleaner, will update my patch.

Thanks
Hanjun
--
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: [RESEND PATCH] xen: vcpu_info would be reset to wrong place on canceled suspend on PVOPS VM which has multi-cpu

2015-05-05 Thread Ouyang Zhaowei (Charles)


On 2015.5.5 17:09, David Vrabel wrote:
 On 04/05/15 03:56, Ouyang Zhaowei (Charles) wrote:
 The hypervisor continues assuming that vcpu_info is stored in per-cpu data 
 which was set up by xen_vcpu_setup(),
 while on canceled suspend, the call to xen_hvm_init_shared_info() will now 
 make the guest think that vcpu_info
 is in the shared page, so we do not call xen_hvm_init_shared_info() on 
 suspend canceled.
 
 I don't understand what the impact of this fix is.  Can you include this
 in the commit message?
 
 David

Sure, please let me know if there is anything not clear enough.

vcpu_info would be reset to wrong place on canceled suspend on PVOPS VM which 
has multi-cpu

The hypervisor continues assuming that vcpu_info is stored in per-cpu data 
which was set up by xen_vcpu_setup(),
while on canceled suspend, the call to xen_hvm_init_shared_info() will make the 
guest think that vcpu_info
is in the shared page. This will cause non-boot cpus keep checking a wrong 
vcpu_info address and can not handle
irqs any more after suspend canceled, for example after we do xl save 
-c/restore, PVOPS VM can not be resumed
as the cpus can not finish their irqs.

 
 Signed-off-by: Charles Ouyang ouyangzhao...@huawei.com
 Reviewed-by: Boris Ostrovsky boris.ostrov...@oracle.com
 ---
  arch/x86/xen/suspend.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

 diff --git a/arch/x86/xen/suspend.c b/arch/x86/xen/suspend.c
 index d949769..b2bed45 100644
 --- a/arch/x86/xen/suspend.c
 +++ b/arch/x86/xen/suspend.c
 @@ -32,7 +32,8 @@ static void xen_hvm_post_suspend(int suspend_cancelled)
  {
  #ifdef CONFIG_XEN_PVHVM
 int cpu;
 -   xen_hvm_init_shared_info();
 +   if (!suspend_cancelled)
 +   xen_hvm_init_shared_info();
 xen_callback_vector();
 xen_unplug_emulated_devices();
 if (xen_feature(XENFEAT_hvm_safe_pvclock)) {

 
 
 .
 

--
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 kgr on klp 4/9] livepatch: add kgr infrastructure

2015-05-05 Thread Jiri Slaby
On 05/04/2015, 02:23 PM, Martin Schwidefsky wrote:
 On Mon,  4 May 2015 13:40:20 +0200
 Jiri Slaby jsl...@suse.cz wrote:
 
 This means:
 * add a per-thread flag to indicate whether a task is in the old or in
   the new universe,
 * reset it in _slow_ paths of syscall's entry/exit,
 * add helpers around the flag to sched.h,
 * export the status in /proc/pid/kgr_in_progress,
 
 @@ -217,6 +226,7 @@ ENTRY(system_call)
  mvc __PT_INT_CODE(4,%r11),__LC_SVC_ILC
  stg %r14,__PT_FLAGS(%r11)
  .Lsysc_do_svc:
 +HANDLE_KGRAFT %r12
  lg  %r10,__TI_sysc_table(%r12)  # address of system call table
  llgh%r8,__PT_INT_CODE+2(%r11)
  slag%r8,%r8,2   # shift and test for svc 0
 
 This is not the slow path, .Lsysc_do_svc is on the main svc path. It is
 only two instruction but nevertheless this should be avoided.

Hi,

the commit log says the reset is in the slow path, not the test. But OK,
we can optimize, see below.

 One way is to combine it with the _TIF_TRACE mechanics:
 
 .Lsysc_nr_ok:
 xc  __SF_BACKCHAIN(8,%r15),__SF_BACKCHAIN(%r15)
 stg %r2,__PT_ORIG_GPR2(%r11)
 stg %r7,STACK_FRAME_OVERHEAD(%r15)
 lgf %r9,0(%r8,%r10) # get system call add.
  - tm  __TI_flags+6(%r12),_TIF_TRACE8
  - jnz .Lsysc_tracesys
 basr%r14,%r9# call sys_
 stg %r2,__PT_R2(%r11)   # store return value
 
 Add _TIF_KGR_IN_PROGRESS to _TIF_TRACE and branch to a new label,
 e.g. to .Lsysc_trace. Distinguish between _TIF_KGR_IN_PROGRESS and
 the other trace reasons and either call s390_handle_kgraft or
 do_syscall_trace_enter / do_syscall_trace_exit.
 
 The same for the exit work, add _TIF_KGR_IN_PROGRESS to _TIF_WORK
 and sort out the reason in .Lsysc_work. That avoids another two
 instructions on the main system call path.

I considered this, but there was no space in the word.

_TIF_WORK is:
TIF_NOTIFY_RESUME   0
TIF_SIGPENDING  1
TIF_NEED_RESCHED2
TIF_UPROBE  7

_TIF_TRACE is:
TIF_SYSCALL_TRACE   3
TIF_SYSCALL_AUDIT   4
TIF_SECCOMP 5
TIF_SYSCALL_TRACEPOINT  6

=

What I could do is to split them and make this setup:

_TIF_WORK:
TIF_NOTIFY_RESUME   0
TIF_SIGPENDING  1
TIF_NEED_RESCHED2
TIF_KGR_IN_PROGRESS_W   3
TIF_UPROBE  7

_TIF_TRACE:
TIF_SYSCALL_TRACE   24
TIF_SYSCALL_AUDIT   25
TIF_SECCOMP 26
TIF_SYSCALL_TRACEPOINT  27
TIF_KGR_IN_PROGRESS_T   28

=

Then make TIF_KGR_IN_PROGRESS_W fire when tm-ing _TIF_WORK in
__TI_flags+7. TIF_KGR_IN_PROGRESS_T will work along with _TIF_TRACE
using tm on __TI_flags+4.

What do you think?

thanks,
-- 
js
suse labs
--
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 v2 04/15] posix timers:Introduce the 64bit methods with timespec64 type for k_clock structure

2015-05-05 Thread Thomas Gleixner
On Thu, 30 Apr 2015, Baolin Wang wrote:
 diff --git a/include/linux/posix-timers.h b/include/linux/posix-timers.h
 index 907f3fd..35786c5 100644
 --- a/include/linux/posix-timers.h
 +++ b/include/linux/posix-timers.h
 @@ -98,9 +98,13 @@ struct k_itimer {
  
  struct k_clock {
   int (*clock_getres) (const clockid_t which_clock, struct timespec *tp);
 + int (*clock_getres64) (const clockid_t which_clock, struct timespec64 
 *tp);
   int (*clock_set) (const clockid_t which_clock,
 const struct timespec *tp);
 + int (*clock_set64) (const clockid_t which_clock,
 + const struct timespec64 *tp);
   int (*clock_get) (const clockid_t which_clock, struct timespec * tp);
 + int (*clock_get64) (const clockid_t which_clock, struct timespec64 *tp);
   int (*clock_adj) (const clockid_t which_clock, struct timex *tx);
   int (*timer_create) (struct k_itimer *timer);
   int (*nsleep) (const clockid_t which_clock, int flags,
 @@ -109,10 +113,15 @@ struct k_clock {
   int (*timer_set) (struct k_itimer * timr, int flags,
 struct itimerspec * new_setting,
 struct itimerspec * old_setting);
 + int (*timer_set64) (struct k_itimer *timr, int flags,
 + struct itimerspec64 *new_setting,
 + struct itimerspec64 *old_setting);
   int (*timer_del) (struct k_itimer * timr);
  #define TIMER_RETRY 1
   void (*timer_get) (struct k_itimer * timr,
  struct itimerspec * cur_setting);
 + void (*timer_get64) (struct k_itimer *timr,
 +  struct itimerspec64 *cur_setting);

I asked you last time to provide a conversion for a single instance
first and I gave you even step by step instructions.

But you insist on resending the whole mess in one go. Try again.

Thanks,

tglx
--
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 0/5] arm64,hi6220: Enable Hisilicon Hi6220 SoC

2015-05-05 Thread Haojian Zhuang
On 5 May 2015 at 12:30, Bintian Wang bintian.w...@huawei.com wrote:
 Hi6220 is one mobile solution of Hisilicon, this patchset contains
 initial support for Hi6220 SoC and HiKey development board, which
 supports octal ARM Cortex A53 cores. Initial support is minimal and
 includes just the arch configuration, clock driver, device tree
 configuration.

 PSCI is enabled in device tree and there is no problem to boot all the
 octal cores, and the CPU hotplug is also working now, you can download
 and compile the latest firmware based on the following link to run this
 patch set:
 https://github.com/96boards/documentation/wiki/UEFI

 Changes v3:
 * Verified the CPU hotplug based on the new released firmware
 * Redefined the compatible strings of four system controllers in dts
 * Setting COMMON_CLK_HI6220 to a bool symbol
 * Keep CONFGI_ARCH_HISI sorted alphabetically

 Changes v2:
 * Split the DT bindings documents into earlier patches
 * Change SMP enable method from spin-table to PSCI in device tree
 * Remove clock-frequency from armv8-timer device node in device tree
 * Add more description about Hisilicon designed system controllers
   in DT bindings document
 * Enable high speed clock on UART1 mux
 * Other changes based on the discussion in the mailing list:
   https://lkml.org/lkml/2015/2/5/147

 Bintian Wang (5):
   arm64: Enable Hisilicon ARMv8 SoC family in Kconfig and defconfig
   arm64: hi6220: Document devicetree bindings for Hisilicon hi6220 SoC
   clk: hi6220: Document devicetree bindings for hi6220 clock
   clk: hi6220: Clock driver support for Hisilicon hi6220 SoC
   arm64: dts: Add dts files for Hisilicon Hi6220 SoC



Acked-by: Haojian Zhuang haojian.zhu...@linaro.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: [PATCH v3 7/8] ASoC: wm8998: Initial WM8998 codec driver

2015-05-05 Thread Richard Fitzgerald
 
+static const char * const wm8998_inmux_texts[] = {
+   A,
+   B,
 
   Those are some fun input names...
 
  ... that's what the mux positions are called and it seems nice to have 
  consistent
  naming for all similar muxes across channels and across future codecs. Like 
  for
  example to switch both muxes of a stereo input you set them both to the same
  position name (both A or both B) is clearer, and quicker to spot in a 
  dump
  of ALSA control settings, than having the two muxes set to different 
  enumeration
  strings that actually mean the same mux position.
 
 Equally when setting the muxes settings called A and B that's not really
 telling people what they do.

We can't really tell people what the selection does because that depends on
the external hardware. The A setting might be a headset mic, or a line in,
or a builtin mic...

All we can do is say what the selection is called generically by the codec.
So take the IN1L signal, on the codec it has two inputs A and B. The
IN1L Mux control has two settings A and B. That seems clear.
--
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 bisected regression] input_available_p() sometimes says 'no' when it should say 'yes'

2015-05-05 Thread Chris Purvis
A way of giving context.



This message has been scanned for malware by Websense. www.websense.com
N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z��w���?��)ߢf��^jǫy�m��@A�a���
0��h���i

Re: [PATCH 9/9] ARM: tegra: apalis t30: fix pin muxing and add HDA in device tree

2015-05-05 Thread Thierry Reding
On Fri, Apr 10, 2015 at 11:36:04PM +0200, Marcel Ziswiler wrote:
 From: Marcel Ziswiler marcel.ziswi...@toradex.com
 
 Fix pin muxing, add digital audio aka HDA pin muxing and activate HDA
 driver.
 Fix pu vs. gpio_pu pin muxing.
 While at it also update comment about supported module hardware
 versions.
 While at it also add an emmc label to the SDHCI node just like on
 Colibri T30.
 While at it set the dr_mode of the primary USB EHCI instance to OTG as
 well.
 
 Signed-off-by: Marcel Ziswiler marcel.ziswi...@toradex.com

Same as for patch 8/9, please split these up into smaller patches that
do one thing each. And again, I'm not sure adding an emmc label just for
consistency here is worth it. If it's never used there's no need to have
it.

Thierry


pgpFSsH4xC22x.pgp
Description: PGP signature


[PATCH 1/9] usb:fsl:otg: Add controller version based ULPI and UTMI phy

2015-05-05 Thread Ramneek Mehresh
Add controller version based ULPI and UTMI phy initialization for
otg driver

Signed-off-by: Shengzhou Liu shengzhou@freescale.com
Signed-off-by: Ramneek Mehresh ramneek.mehr...@freescale.com
Reviewed-by: Fleming Andrew-AFLEMING aflem...@freescale.com
Tested-by: Fleming Andrew-AFLEMING aflem...@freescale.com
---
 drivers/usb/phy/phy-fsl-usb.c | 20 
 drivers/usb/phy/phy-fsl-usb.h |  7 +++
 2 files changed, 27 insertions(+)

diff --git a/drivers/usb/phy/phy-fsl-usb.c b/drivers/usb/phy/phy-fsl-usb.c
index 94eb292..f90093a 100644
--- a/drivers/usb/phy/phy-fsl-usb.c
+++ b/drivers/usb/phy/phy-fsl-usb.c
@@ -923,12 +923,32 @@ int usb_otg_start(struct platform_device *pdev)
temp = ~(PORTSC_PHY_TYPE_SEL | PORTSC_PTW);
switch (pdata-phy_mode) {
case FSL_USB2_PHY_ULPI:
+   if (pdata-controller_ver) {
+   /* controller version 1.6 or above */
+   setbits32(p_otg-dr_mem_map-control,
+   USB_CTRL_ULPI_PHY_CLK_SEL);
+   /*
+* Due to controller issue of PHY_CLK_VALID in ULPI
+* mode, we set USB_CTRL_USB_EN before checking
+* PHY_CLK_VALID, otherwise PHY_CLK_VALID doesn't work.
+*/
+   clrsetbits_be32(p_otg-dr_mem_map-control,
+USB_CTRL_UTMI_PHY_EN, USB_CTRL_IOENB);
+   }
temp |= PORTSC_PTS_ULPI;
break;
case FSL_USB2_PHY_UTMI_WIDE:
temp |= PORTSC_PTW_16BIT;
/* fall through */
case FSL_USB2_PHY_UTMI:
+   if (pdata-controller_ver) {
+   /* controller version 1.6 or above */
+   setbits32(p_otg-dr_mem_map-control,
+USB_CTRL_UTMI_PHY_EN);
+   /* Delay for UTMI PHY CLK to become stable - 10ms */
+   mdelay(FSL_UTMI_PHY_DLY);
+   }
+   setbits32(p_otg-dr_mem_map-control, USB_CTRL_UTMI_PHY_EN);
temp |= PORTSC_PTS_UTMI;
/* fall through */
default:
diff --git a/drivers/usb/phy/phy-fsl-usb.h b/drivers/usb/phy/phy-fsl-usb.h
index 2314995..4a78fb3 100644
--- a/drivers/usb/phy/phy-fsl-usb.h
+++ b/drivers/usb/phy/phy-fsl-usb.h
@@ -199,6 +199,13 @@
 /* control Register Bit Masks */
 #define  USB_CTRL_IOENB(0x12)
 #define  USB_CTRL_ULPI_INT0EN  (0x10)
+#define  USB_CTRL_WU_INT_EN(0x11)
+#define  USB_CTRL_LINE_STATE_FILTER__EN(0x13)
+#define  USB_CTRL_KEEP_OTG_ON  (0x14)
+#define  USB_CTRL_OTG_PORT (0x15)
+#define  USB_CTRL_PLL_RESET(0x18)
+#define  USB_CTRL_UTMI_PHY_EN  (0x19)
+#define  USB_CTRL_ULPI_PHY_CLK_SEL (0x110)
 
 /* BCSR5 */
 #define BCSR5_INT_USB  (0x02)
-- 
1.8.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/


  1   2   3   4   5   6   7   8   9   10   >