Re: [PATCH] ARM: dts: am335x-boards: Fixup the usb control module address in respective Board files

[Mugunthan V N]

On Tuesday 08 April 2014 06:37 PM, George Cherian wrote:
> The USB Contol Module address was updated in am33xx.dtsi file
> by the following commit 8abcdd680d543fb582371e146e62ba9f2af8a816
> ARM: dts: am33xx: correcting dt node unit address for usb
>
> The same changes need to be done for respective board files.
> Without these changes USB wont be detected in any of the boards.
>
> Signed-off-by: George Cherian 

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

Re: [Intel-gfx] i915 DVI resolution regression (3.13.7+)

[Dave Airlie]

On Wed, Apr 9, 2014 at 4:07 PM, Daniel J Blueman  wrote:
> On 9 April 2014 11:41, Dave Airlie  wrote:
>> On Tue, Apr 8, 2014 at 5:32 PM, Daniel J Blueman  wrote:
>>> On 8 April 2014 15:14, Jani Nikula  wrote:
 On Tue, 08 Apr 2014, Daniel J Blueman  wrote:
> Ville et al,
>
> It looks like commit e3ea8fa6beaf55fee64bf816f3b8a80ad733b2c2 (or
> another commit in 3.13.7) broke modes which require DVI-D dual-link,
> eg 2560x1440 with my panel.
>
> I don't see these modelines in 3.13.7 or later (eg 3.14):
>
> [ 5.582] (II) intel(0): Modeline "2560x1440"x60.0  312.25  2560
> 2752 3024 3488  1440 1443 1448 1493 -hsync +vsync (89.5 kHz eP)
> [ 5.582] (II) intel(0): Modeline "2560x1440"x60.0  312.25  2560
> 2752 3024 3488  1440 1443 1448 1493 -hsync +vsync (89.5 kHz eP)
> [ 5.582] (II) intel(0): Modeline "1920x1200"x59.9  193.25  1920
> 2056 2256 2592  1200 1203 1209 1245 -hsync +vsync (74.6 kHz e)
>
> My monitor is a Dell U2713HM; mobo uses an H87 chipset with i5-4670.

 By allowing those modes we regressed setups which were not capable of
 displaying them. So you've got an HDMI->DVI converter?

 https://bugzilla.kernel.org/show_bug.cgi?id=72961
>>>
>>> I am using a dual-link DVI-D to DVI-D cable to this monitor, since I
>>> previously couldn't get 2560x1440 via HDMI.
>>
>> Intel hw has dual-link DVI-D? I'm not sure I've ever seen that, is
>> this SDVO device or plain DVI-D?
>
> It's the DVI-D connector on: https://www.asus.com/Motherboards/H87IPLUS/

The link which says "

Integrated Graphics Processor
- Supports HDMI with max. resolution 4096 x 2304 @ 24 Hz
- Supports DVI with max. resolution 1920 x 1200 @ 60 Hz
- Supports RGB with max. resolution 1920 x 1200 @ 60 Hz

I'm even wondering electrically how a HDMI->dual-link DVI adapter works.

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/

Zusammenarbeit!

[Herr.James Menka]

Guter Tag, 

Ich vermute das diese E-Mail eine uberraschung fur Sie sein wird, aber es ist 
wahr.Ich bin bei einer routinen uberprufung in meiner Bank(Zambia National 
Commercial Bank) wo ich arbeite, auf einem Konto gestoben, was nicht in 
anspruch genommen worden ist, wo derzeit $14,200,000 (Vierzehn Millionen 
zweihunderttausend US Dollar) gutgeschrieben sind. Dieses Konto gehurte Herrn 
Johannes Horn, der einKunde in unsere Bank war, der leider verstorben ist. Herr 
Horn war eingeburtiger Deutscher.

Damit es mir moglich ist dieses Geld $14,200,000 inanspruch zunehmen, benotige 
ich die zusammenarbeit eines Auslandischen Partners wie Sie,den ich als 
Verwandter und Erbe des verstorbenen Herrn Horn vorstellen kann,damit wir das 
Geld inanspruch nehmen konnen.

Fur diese Unterstutzung erhalten Sie 30% der Erbschaftsumme und die restlichen 
70% teile ich mirmit meinen zwei Arbeitskollegen, die mich bei dieser 
Transaktion ebenfalls unterstutzen.Wenn Sie interessiert sind, konnen Sie mir 
bitte eine E-Mail schicken, damit ich Ihnen mehr Details zukommen lassen kann. 
Schicken Sie bitte Ihre Antwort auf diese E-Mail:
mko...@aol.com
Mit freundlichen Grussen,
Herr.James Menka.
Antwort E-Mail: mko...@aol.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] kbuild: support simultaneous "make %config" and "make all"

[Masahiro Yamada]

Kbuild is supposed to support mixed targets. (%config and build targets)

But "make all" did nothing if it was run with configuration targets.
For example,

  $ LANG=C make defconfig all
HOSTCC  scripts/basic/fixdep
HOSTCC  scripts/kconfig/conf.o
SHIPPED scripts/kconfig/zconf.tab.c
SHIPPED scripts/kconfig/zconf.lex.c
SHIPPED scripts/kconfig/zconf.hash.c
HOSTCC  scripts/kconfig/zconf.tab.o
HOSTLD  scripts/kconfig/conf
  *** Default configuration is based on 'x86_64_defconfig'
  #
  # configuration written to .config
  #
  make: Nothing to be done for `all'.

This commits allows "make %config all" and makes sure
mixed targets are built one by one in the given order.

Signed-off-by: Masahiro Yamada 
Cc: Michal Marek 
CC: Sam Ravnborg 
---
 Makefile   | 12 ++--
 scripts/mkmakefile | 15 ---
 2 files changed, 14 insertions(+), 13 deletions(-)

diff --git a/Makefile b/Makefile
index 4eadf2d..40f731b 100644
--- a/Makefile
+++ b/Makefile
@@ -486,8 +486,16 @@ ifeq ($(mixed-targets),1)
 # We're called with mixed targets (*config and build targets).
 # Handle them one by one.
 
-%:: FORCE
-   $(Q)$(MAKE) -C $(srctree) KBUILD_SRC= $@
+PHONY += $(MAKECMDGOALS) __build_one_by_one
+
+$(filter-out __build_one_by_one, $(MAKECMDGOALS)): __build_one_by_one
+   @:
+
+__build_one_by_one:
+   $(Q)set -e; \
+   for i in $(MAKECMDGOALS); do \
+   $(MAKE) -f $(srctree)/Makefile $$i; \
+   done
 
 else
 ifeq ($(config-targets),1)
diff --git a/scripts/mkmakefile b/scripts/mkmakefile
index 0cc0442..84af27b 100644
--- a/scripts/mkmakefile
+++ b/scripts/mkmakefile
@@ -42,18 +42,11 @@ MAKEARGS += O=\$(if \$(patsubst 
/%,,\$(makedir)),\$(CURDIR)/)\$(patsubst %/,%,\$
 
 MAKEFLAGS += --no-print-directory
 
-.PHONY: all \$(MAKECMDGOALS)
+.PHONY: __sub-make \$(MAKECMDGOALS)
 
-all:= \$(filter-out all Makefile,\$(MAKECMDGOALS))
+__sub-make:
+   \$(Q)\$(MAKE) \$(MAKEARGS) \$(MAKECMDGOALS)
 
-all:
-   \$(Q)\$(MAKE) \$(MAKEARGS) \$(all)
-
-Makefile:;
-
-\$(all): all
-   @:
-
-%/: all
+\$(filter-out __sub-make, \$(MAKECMDGOALS)): __sub-make
@:
 EOF
-- 
1.8.3.2

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

Re: [RFC PATCH 0/5] Use an alternative to _PAGE_PROTNONE for _PAGE_NUMA v2

[Ingo Molnar]

* Peter Zijlstra  wrote:

> On Tue, Apr 08, 2014 at 05:46:52PM +0100, Mel Gorman wrote:
> > Someone will ask why automatic NUMA balancing hints do not use "real"
> > PROT_NONE but as it would need VMA information to do that on all
> > architectures it would mean that VMA-fixups would be required when marking
> > PTEs for NUMA hinting faults so would be expensive.
> 
> Like this:
> 
>   https://lkml.org/lkml/2012/11/13/431
> 
> That used the generic PROT_NONE infrastructure and compared, on fault,
> the page protection bits against the vma->vm_page_prot bits?
> 
> So the objection to that approach was the vma-> dereference in
> pte_numa() ?

I think the real underlying objection was that PTE_NUMA was the last 
leftover from AutoNUMA, and removing it would have made it not a 
'compromise' patch set between 'AutoNUMA' and 'sched/numa', but would 
have made the sched/numa approach 'win' by and large.

The whole 'losing face' annoyance that plagues all of us (me 
included).

I didn't feel it was important to the general logic of adding access 
pattern aware NUMA placement logic to the scheduler, and I obviously 
could not ignore the NAKs from various mm folks insisting on PTE_NUMA, 
so I conceded that point and Mel built on that approach as well.

Nice it's being cleaned up, and I'm pretty happy about how NUMA 
balancing ended up looking like.

Thanks,

Ingo
--
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 v6 3/4] mmc: Add realtek USB sdmmc host driver

[rogerable]

From: Roger Tseng 

Realtek USB SD/MMC host driver provides mmc host support based on the Realtek
USB card reader MFD driver.

Signed-off-by: Roger Tseng 
---
 drivers/mmc/host/Kconfig  |7 +
 drivers/mmc/host/Makefile |1 +
 drivers/mmc/host/rtsx_usb_sdmmc.c | 1462 +
 3 files changed, 1470 insertions(+)
 create mode 100644 drivers/mmc/host/rtsx_usb_sdmmc.c

diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 1384f67..1c01df4 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -689,3 +689,10 @@ config MMC_REALTEK_PCI
help
  Say Y here to include driver code to support SD/MMC card interface
  of Realtek PCI-E card reader
+
+config MMC_REALTEK_USB
+   tristate "Realtek USB SD/MMC Card Interface Driver"
+   depends on MFD_RTSX_USB
+   help
+ Say Y here to include driver code to support SD/MMC card interface
+ of Realtek RTS5129/39 series card reader
diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
index 3483b6b..8194317 100644
--- a/drivers/mmc/host/Makefile
+++ b/drivers/mmc/host/Makefile
@@ -53,6 +53,7 @@ obj-$(CONFIG_MMC_USHC)+= ushc.o
 obj-$(CONFIG_MMC_WMT)  += wmt-sdmmc.o
 
 obj-$(CONFIG_MMC_REALTEK_PCI)  += rtsx_pci_sdmmc.o
+obj-$(CONFIG_MMC_REALTEK_USB)  += rtsx_usb_sdmmc.o
 
 obj-$(CONFIG_MMC_SDHCI_PLTFM)  += sdhci-pltfm.o
 obj-$(CONFIG_MMC_SDHCI_CNS3XXX)+= sdhci-cns3xxx.o
diff --git a/drivers/mmc/host/rtsx_usb_sdmmc.c 
b/drivers/mmc/host/rtsx_usb_sdmmc.c
new file mode 100644
index 000..37f58b5
--- /dev/null
+++ b/drivers/mmc/host/rtsx_usb_sdmmc.c
@@ -0,0 +1,1462 @@
+/* Realtek USB SD/MMC Card Interface driver
+ *
+ * Copyright(c) 2009-2013 Realtek Semiconductor Corp. All rights reserved.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, see .
+ *
+ * Author:
+ *   Roger Tseng 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#if defined(CONFIG_LEDS_CLASS) || defined(CONFIG_LEDS_CLASS_MODULE)
+#include 
+#include 
+#define RTSX_USB_USE_LEDS_CLASS
+#endif
+
+struct rtsx_usb_sdmmc {
+   struct platform_device  *pdev;
+   struct rtsx_ucr *ucr;
+   struct mmc_host *mmc;
+   struct mmc_request  *mrq;
+
+   struct mutexhost_mutex;
+
+   u8  ssc_depth;
+   unsigned intclock;
+   boolvpclk;
+   booldouble_clk;
+   boolhost_removal;
+   boolcard_exist;
+   boolinitial_mode;
+   boolddr_mode;
+
+   unsigned char   power_mode;
+
+#if defined(CONFIG_LEDS_CLASS) || defined(CONFIG_LEDS_CLASS_MODULE)
+   struct led_classdev led;
+   charled_name[32];
+   struct work_struct  led_work;
+#endif
+};
+
+static inline struct device *sdmmc_dev(struct rtsx_usb_sdmmc *host)
+{
+   return &(host->pdev->dev);
+}
+
+static inline void sd_clear_error(struct rtsx_usb_sdmmc *host)
+{
+   struct rtsx_ucr *ucr = host->ucr;
+   rtsx_usb_ep0_write_register(ucr, CARD_STOP,
+ SD_STOP | SD_CLR_ERR,
+ SD_STOP | SD_CLR_ERR);
+
+   rtsx_usb_clear_dma_err(ucr);
+   rtsx_usb_clear_fsm_err(ucr);
+}
+
+#ifdef DEBUG
+static void sd_print_debug_regs(struct rtsx_usb_sdmmc *host)
+{
+   struct rtsx_ucr *ucr = host->ucr;
+   u8 val = 0;
+
+   rtsx_usb_ep0_read_register(ucr, SD_STAT1, &val);
+   dev_dbg(sdmmc_dev(host), "SD_STAT1: 0x%x\n", val);
+   rtsx_usb_ep0_read_register(ucr, SD_STAT2, &val);
+   dev_dbg(sdmmc_dev(host), "SD_STAT2: 0x%x\n", val);
+   rtsx_usb_ep0_read_register(ucr, SD_BUS_STAT, &val);
+   dev_dbg(sdmmc_dev(host), "SD_BUS_STAT: 0x%x\n", val);
+}
+#else
+#define sd_print_debug_regs(host)
+#endif /* DEBUG */
+
+static int sd_read_data(struct rtsx_usb_sdmmc *host, struct mmc_command *cmd,
+  u16 byte_cnt, u8 *buf, int buf_len, int timeout)
+{
+   struct rtsx_ucr *ucr = host->ucr;
+   int err;
+   u8 trans_mode;
+
+   if (!buf)
+   buf_len = 0;
+
+   rtsx_usb_init_cmd(ucr);
+   if (cmd != NULL) {
+   dev_dbg(sdmmc_dev(host), "%s

[PATCH v6 4/4] memstick: Add realtek USB memstick host driver

[rogerable]

From: Roger Tseng 

Realtek USB memstick host driver provides memstick host support based on the
Realtek USB card reader MFD driver.

Signed-off-by: Roger Tseng 
---
 drivers/memstick/host/Kconfig   |  10 +
 drivers/memstick/host/Makefile  |   1 +
 drivers/memstick/host/rtsx_usb_ms.c | 839 
 3 files changed, 850 insertions(+)
 create mode 100644 drivers/memstick/host/rtsx_usb_ms.c

diff --git a/drivers/memstick/host/Kconfig b/drivers/memstick/host/Kconfig
index 1b37cf8..7310e32 100644
--- a/drivers/memstick/host/Kconfig
+++ b/drivers/memstick/host/Kconfig
@@ -52,3 +52,13 @@ config MEMSTICK_REALTEK_PCI
 
  To compile this driver as a module, choose M here: the module will
  be called rtsx_pci_ms.
+
+config MEMSTICK_REALTEK_USB
+   tristate "Realtek USB Memstick Card Interface Driver"
+   depends on MFD_RTSX_USB
+   help
+ Say Y here to include driver code to support Memstick card interface
+ of Realtek RTS5129/39 series USB card reader
+
+ To compile this driver as a module, choose M here: the module will
+ be called rts5139_ms.
diff --git a/drivers/memstick/host/Makefile b/drivers/memstick/host/Makefile
index af3459d..491c955 100644
--- a/drivers/memstick/host/Makefile
+++ b/drivers/memstick/host/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_MEMSTICK_TIFM_MS)  += tifm_ms.o
 obj-$(CONFIG_MEMSTICK_JMICRON_38X) += jmb38x_ms.o
 obj-$(CONFIG_MEMSTICK_R592)+= r592.o
 obj-$(CONFIG_MEMSTICK_REALTEK_PCI) += rtsx_pci_ms.o
+obj-$(CONFIG_MEMSTICK_REALTEK_USB) += rtsx_usb_ms.o
diff --git a/drivers/memstick/host/rtsx_usb_ms.c 
b/drivers/memstick/host/rtsx_usb_ms.c
new file mode 100644
index 000..a7282b7
--- /dev/null
+++ b/drivers/memstick/host/rtsx_usb_ms.c
@@ -0,0 +1,839 @@
+/* Realtek USB Memstick Card Interface driver
+ *
+ * Copyright(c) 2009-2013 Realtek Semiconductor Corp. All rights reserved.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, see .
+ *
+ * Author:
+ *   Roger Tseng 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct rtsx_usb_ms {
+   struct platform_device  *pdev;
+   struct rtsx_ucr *ucr;
+   struct memstick_host*msh;
+   struct memstick_request *req;
+
+   struct mutexhost_mutex;
+   struct work_struct  handle_req;
+
+   struct task_struct  *detect_ms;
+   struct completion   detect_ms_exit;
+
+   u8  ssc_depth;
+   unsigned intclock;
+   int power_mode;
+   unsigned char   ifmode;
+   booleject;
+};
+
+static inline struct device *ms_dev(struct rtsx_usb_ms *host)
+{
+   return &(host->pdev->dev);
+}
+
+static inline void ms_clear_error(struct rtsx_usb_ms *host)
+{
+   struct rtsx_ucr *ucr = host->ucr;
+   rtsx_usb_ep0_write_register(ucr, CARD_STOP,
+ MS_STOP | MS_CLR_ERR,
+ MS_STOP | MS_CLR_ERR);
+
+   rtsx_usb_clear_dma_err(ucr);
+   rtsx_usb_clear_fsm_err(ucr);
+}
+
+#ifdef DEBUG
+
+static void ms_print_debug_regs(struct rtsx_usb_ms *host)
+{
+   struct rtsx_ucr *ucr = host->ucr;
+   u16 i;
+   u8 *ptr;
+
+   /* Print MS host internal registers */
+   rtsx_usb_init_cmd(ucr);
+
+   /* MS_CFG to MS_INT_REG */
+   for (i = 0xFD40; i <= 0xFD44; i++)
+   rtsx_usb_add_cmd(ucr, READ_REG_CMD, i, 0, 0);
+
+   /* CARD_SHARE_MODE to CARD_GPIO */
+   for (i = 0xFD51; i <= 0xFD56; i++)
+   rtsx_usb_add_cmd(ucr, READ_REG_CMD, i, 0, 0);
+
+   /* CARD_PULL_CTLx */
+   for (i = 0xFD60; i <= 0xFD65; i++)
+   rtsx_usb_add_cmd(ucr, READ_REG_CMD, i, 0, 0);
+
+   /* CARD_DATA_SOURCE, CARD_SELECT, CARD_CLK_EN, CARD_PWR_CTL */
+   rtsx_usb_add_cmd(ucr, READ_REG_CMD, CARD_DATA_SOURCE, 0, 0);
+   rtsx_usb_add_cmd(ucr, READ_REG_CMD, CARD_SELECT, 0, 0);
+   rtsx_usb_add_cmd(ucr, READ_REG_CMD, CARD_CLK_EN, 0, 0);
+   rtsx_usb_add_cmd(ucr, READ_REG_CMD, CARD_PWR_CTL, 0, 0);
+
+   rtsx_usb_send_cmd(ucr, MODE_CR, 100);
+   rtsx_usb_get_rsp(ucr, 21, 100);
+
+   ptr = ucr->rsp_buf;
+   for (i = 0xFD40; i <= 0xFD44; i++)
+   dev_dbg(ms_dev(host), "0x%04X: 0x%02x\n", i, *(ptr++));
+   for (i =

[PATCH v6 0/4] Add modules for realtek USB card reader

[rogerable]

From: Roger Tseng 

This patchset adds modules to support Realtek USB vendor specific class flash
card reader: one base module in MFD subsystem and two host modules in both mmc
and memstick subsystems. The architecture is similar to rtsx_pci.

This work is done primarily to replace the staging driver: staging/rts5139,
which doesn't utilize mmc nor memstick subsystems. Once the patchset or its
revision is applied, we may need Greg's help to remove the staging one.

v2:
1. Fix potential buffer overflow in rtsx_usb_seq_write_register()
2. Remove unnecessary casting and messages
3. Revise coding style and white spaces

v3:
1. Fix MMC detection fail when under xhci
2. Minor change of pm_runtime behavior in rtsx_usb_ms to prevent some rare
   freeze due to erroneous Memstick card(not MS-Pro)
3. Further revise coding style as suggested in the thread of v2
4. Using managed resources: devm_*
5. Change license from "GPL v2 and later" to "GPL v2"

v4:
1. Remove invocations to deprecated/removed mmc_suspend|resume_host APIs and
   unnecessary platform device pm routines
2. Support CRC-ignored R1 response for CMD13 in response to commit:
   a27fbf2f067b0cd6f172c8b696b9a44c58bfaa7a: mmc: add ignorance case for 
   CMD13 CRC error
3. Remove unnecessary #ifdef CONFIG_PM_RUNTIME

v5:
1. rtsx_usb_ms.c: adding header inclusion, removing unnecessary NULL checking,
   and add cancel_work_sync in removal handler to wait possible pending
   works.
(Changes only rtsx_usb_ms. Other files remain the same to v4)

v6:
NOTE:since the v3 of patch 1/3 (rtsx_usb) has been merged, only diffs are
submitted and splitted into two.
1. rtsx_usb.c: fix possible race conditions:
   rtsx_usb_bulk_transfer_sglist(): del_timer() => del_timer_sync()
   rtsx_usb_probe(): move setup_timer() before mfd_add_devices() and also
 remove unnecessary init_timer()
2. rtsx_usb.c: rtsx_usb_suspend(): add comments to LED turn-off
(Changes only rtsx_usb.c. Other files remain the same to v5)

Roger Tseng (4):
  [v6 fix] mfd/rtsx_usb: fix possible race condition
  [v6 fix] mfd/rtsx_usb: add comment in rtsx_usb_suspend
  mmc: Add realtek USB sdmmc host driver
  memstick: Add realtek USB memstick host driver

 drivers/memstick/host/Kconfig   |   10 +
 drivers/memstick/host/Makefile  |1 +
 drivers/memstick/host/rtsx_usb_ms.c |  839 
 drivers/mfd/rtsx_usb.c  |   14 +-
 drivers/mmc/host/Kconfig|7 +
 drivers/mmc/host/Makefile   |1 +
 drivers/mmc/host/rtsx_usb_sdmmc.c   | 1462 +++
 7 files changed, 2330 insertions(+), 4 deletions(-)
 create mode 100644 drivers/memstick/host/rtsx_usb_ms.c
 create mode 100644 drivers/mmc/host/rtsx_usb_sdmmc.c

-- 
1.8.2

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

[PATCH v6 2/4] [v6 fix] mfd/rtsx_usb: add comment in rtsx_usb_suspend

[rogerable]

From: Roger Tseng 

Explain why there is no need to have a symmetric LED turn-on in resume handler
while calling rtsx_usb_turn_off_led() in suspend handler.

Signed-off-by: Roger Tseng 
---
 drivers/mfd/rtsx_usb.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/mfd/rtsx_usb.c b/drivers/mfd/rtsx_usb.c
index 0ca7973..141ea52 100644
--- a/drivers/mfd/rtsx_usb.c
+++ b/drivers/mfd/rtsx_usb.c
@@ -687,9 +687,15 @@ static int rtsx_usb_suspend(struct usb_interface *intf, 
pm_message_t message)
dev_dbg(&intf->dev, "%s called with pm message 0x%04u\n",
__func__, message.event);
 
+   /*
+* Call to make sure LED is off during suspend to save more power.
+* It is NOT a permanent state and could be turned on anytime later.
+* Thus no need to call turn_on when resunming.
+*/
mutex_lock(&ucr->dev_mutex);
rtsx_usb_turn_off_led(ucr);
mutex_unlock(&ucr->dev_mutex);
+
return 0;
 }
 
-- 
1.8.2

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

[PATCH v6 1/4] [v6 fix] mfd/rtsx_usb: fix possible race condition

[rogerable]

From: Roger Tseng 

Fix two possible race condition generated by misuse of del_timer in
rtsx_usb_bulk_transfer_sglist() and uninitialized timers before mfd_add_devices
in rtsx_usb_probe().

Signed-off-by: Roger Tseng 
---
 drivers/mfd/rtsx_usb.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/mfd/rtsx_usb.c b/drivers/mfd/rtsx_usb.c
index b53b9d4..0ca7973 100644
--- a/drivers/mfd/rtsx_usb.c
+++ b/drivers/mfd/rtsx_usb.c
@@ -67,7 +67,7 @@ static int rtsx_usb_bulk_transfer_sglist(struct rtsx_ucr *ucr,
ucr->sg_timer.expires = jiffies + msecs_to_jiffies(timeout);
add_timer(&ucr->sg_timer);
usb_sg_wait(&ucr->current_sg);
-   del_timer(&ucr->sg_timer);
+   del_timer_sync(&ucr->sg_timer);
 
if (act_len)
*act_len = ucr->current_sg.bytes;
@@ -644,14 +644,14 @@ static int rtsx_usb_probe(struct usb_interface *intf,
if (ret)
goto out_init_fail;
 
+   /* initialize USB SG transfer timer */
+   setup_timer(&ucr->sg_timer, rtsx_usb_sg_timed_out, (unsigned long) ucr);
+
ret = mfd_add_devices(&intf->dev, usb_dev->devnum, rtsx_usb_cells,
ARRAY_SIZE(rtsx_usb_cells), NULL, 0, NULL);
if (ret)
goto out_init_fail;
 
-   /* initialize USB SG transfer timer */
-   init_timer(&ucr->sg_timer);
-   setup_timer(&ucr->sg_timer, rtsx_usb_sg_timed_out, (unsigned long) ucr);
 #ifdef CONFIG_PM
intf->needs_remote_wakeup = 1;
usb_enable_autosuspend(usb_dev);
-- 
1.8.2

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

Re: [PATCH v2] bus: mvebu-mbus: Avoid setting an undefined window size

[Willy Tarreau]

Hi Jason,

On Tue, Apr 08, 2014 at 05:44:14PM -0600, Jason Gunthorpe wrote:
> The mbus hardware requires a power of two size, and size aligned base.
> Currently, if a non-power of two is passed in to the low level routines
> they configure the register in a way that results in undefined behaviour.
> 
> Call WARN and return EINVAL instead.

The WARN is correctly emitted for both igb ports here, but unfortunately
despite EINVAL, I still get the panic. Also I find it surprizing that it
reports sizes ending in . I read the patch and it looks correct, so
we possibly have something else wrong here.

OK I just got it by adding two printk() in pci-mvebu.c. Both functions
mvebu_pcie_handle_iobase_change() and mvebu_pcie_handle_membase_change()
do pass a size which is in fact a mask (size - 1) and not the real size.
So the mbus is fed with an incorrect size which is off by one :

root@xpgp:~# modprobe igb
igb: Intel(R) Gigabit Ethernet Network Driver - version 5.0.5-k
igb: Copyright (c) 2007-2013 Intel Corporation.
PCI: enabling device :00:09.0 (0140 -> 0143)
mvebu_pcie_handle_iobase_change: base=e801 size=0fff
[ cut here ]
WARNING: CPU: 0 PID: 1258 at drivers/bus/mvebu-mbus.c:271 
mvebu_mbus_setup_window+0xb3/0xe4()
Invalid MBus window size: 0xfff
Modules linked in: igb(+) i2c_algo_bit
CPU: 0 PID: 1258 Comm: modprobe Not tainted 3.14.0-mvebu #18
[] (unwind_backtrace) from [] (show_stack+0xb/0xc)
[] (show_stack) from [] (dump_stack+0x4f/0x64)
[] (dump_stack) from [] (warn_slowpath_common+0x49/0x68)
[] (warn_slowpath_common) from [] 
(warn_slowpath_fmt+0x1d/0x28)
[] (warn_slowpath_fmt) from [] 
(mvebu_mbus_setup_window+0xb3/0xe4)
[] (mvebu_mbus_setup_window) from [] 
(mvebu_mbus_alloc_window.constprop.7+0x65/0xc4)
[] (mvebu_mbus_alloc_window.constprop.7) from [] 
(mvebu_pcie_handle_iobase_change+0x6b/0xb0)
[] (mvebu_pcie_handle_iobase_change) from [] 
(mvebu_pcie_wr_conf+0x2eb/0x2f4)
[] (mvebu_pcie_wr_conf) from [] 
(pci_bus_write_config_word+0x35/0x44)
[] (pci_bus_write_config_word) from [] 
(pcibios_enable_device+0xab/0xc0)
[] (pcibios_enable_device) from [] 
(do_pci_enable_device+0x27/0x80)
[] (do_pci_enable_device) from [] 
(pci_enable_device_flags+0x8f/0xc4)
[] (pci_enable_device_flags) from [] 
(pci_enable_bridge+0x2b/0x48)
[] (pci_enable_bridge) from [] 
(pci_enable_device_flags+0x49/0xc4)
[] (pci_enable_device_flags) from [] (igb_probe+0x1c/0xb80 
[igb])
[] (igb_probe [igb]) from [] (pci_device_probe+0x45/0x6c)
[] (pci_device_probe) from [] 
(driver_probe_device+0xb5/0x174)
[] (driver_probe_device) from [] (__driver_attach+0x4b/0x4c)
[] (__driver_attach) from [] (bus_for_each_dev+0x27/0x48)
[] (bus_for_each_dev) from [] (bus_add_driver+0x87/0x128)
[] (bus_add_driver) from [] (driver_register+0x35/0x84)
[] (driver_register) from [] (init_module+0x26/0x3f [igb])
[] (init_module [igb]) from [] (do_one_initcall+0xa1/0xe4)
[] (do_one_initcall) from [] (load_module+0x1067/0x1544)
[] (load_module) from [] (SyS_init_module+0x7f/0x8c)
[] (SyS_init_module) from [] (ret_fast_syscall+0x1/0x46)
---[ end trace 53f41ddadca51c5e ]---
mvebu_pcie_handle_membase_change: base=e000 size=002f
[ cut here ]
WARNING: CPU: 0 PID: 1258 at drivers/bus/mvebu-mbus.c:271 
mvebu_mbus_setup_window+0xb3/0xe4()
Invalid MBus window size: 0x2f
Modules linked in: igb(+) i2c_algo_bit
CPU: 0 PID: 1258 Comm: modprobe Tainted: GW3.14.0-mvebu #18
[] (unwind_backtrace) from [] (show_stack+0xb/0xc)
[] (show_stack) from [] (dump_stack+0x4f/0x64)
[] (dump_stack) from [] (warn_slowpath_common+0x49/0x68)
[] (warn_slowpath_common) from [] 
(warn_slowpath_fmt+0x1d/0x28)
[] (warn_slowpath_fmt) from [] 
(mvebu_mbus_setup_window+0xb3/0xe4)
[] (mvebu_mbus_setup_window) from [] 
(mvebu_mbus_alloc_window.constprop.7+0xb9/0xc4)
[] (mvebu_mbus_alloc_window.constprop.7) from [] 
(mvebu_mbus_add_window_by_id+0xf/0x14)
[] (mvebu_mbus_add_window_by_id) from [] 
(mvebu_pcie_wr_conf+0x2c1/0x2f4)
[] (mvebu_pcie_wr_conf) from [] 
(pci_bus_write_config_word+0x35/0x44)
[] (pci_bus_write_config_word) from [] 
(pcibios_enable_device+0xab/0xc0)
[] (pcibios_enable_device) from [] 
(do_pci_enable_device+0x27/0x80)
[] (do_pci_enable_device) from [] 
(pci_enable_device_flags+0x8f/0xc4)
[] (pci_enable_device_flags) from [] 
(pci_enable_bridge+0x2b/0x48)
[] (pci_enable_bridge) from [] 
(pci_enable_device_flags+0x49/0xc4)
[] (pci_enable_device_flags) from [] (igb_probe+0x1c/0xb80 
[igb])
[] (igb_probe [igb]) from [] (pci_device_probe+0x45/0x6c)
[] (pci_device_probe) from [] 
(driver_probe_device+0xb5/0x174)
[] (driver_probe_device) from [] (__driver_attach+0x4b/0x4c)
[] (__driver_attach) from [] (bus_for_each_dev+0x27/0x48)
[] (bus_for_each_dev) from [] (bus_add_driver+0x87/0x128)
[] (bus_add_driver) from [] (driver_register+0x35/0x84)
[] (driver_register) from [] (init_module+0x26/0x3f [igb])
[] (init_module [igb]) from [] (do_one_initcall+0xa1/0xe4)
[] (do_one_initcall) from [] (load_module+0x1067/

Re: [PATCHv3 1/3] pwm: make the PWM_POLARITY flag in DTB optional

[Sascha Hauer]

On Tue, Apr 08, 2014 at 01:43:22PM -0700, Tim Kryger wrote:
> On Mon, Apr 7, 2014 at 10:02 PM, Lothar Waßmann  
> wrote:
> > Thierry Reding wrote:
> 
> >> No. You cannot emulate polarity inversion in software.
> >>
> > Why not?
> >
> > duty_ns = period_ns - duty_ns;
> 
> Since I made the same mistake, I will pass along the pointer Thierry gave me.
> 
> In include/linux/pwm.h the second difference for an inverted signal is
> described.
> 
> /**
>  * enum pwm_polarity - polarity of a PWM signal
>  * @PWM_POLARITY_NORMAL: a high signal for the duration of the duty-
>  * cycle, followed by a low signal for the remainder of the pulse
>  * period
>  * @PWM_POLARITY_INVERSED: a low signal for the duration of the duty-
>  * cycle, followed by a high signal for the remainder of the pulse
>  * period
>  */
> enum pwm_polarity {
> PWM_POLARITY_NORMAL,
> PWM_POLARITY_INVERSED,
> };
> 
> Of course, I suspect not all PWM hardware respects this definition of
> inverted output.
> 
> Either way, hacking the duty in software certainly would get the
> high/low order wrong.

This only relevant if you have some reference signal the PWM must be
relative to, for example if you combine multiple PWMs for motor control.
For PWMs used for backlight or beepers a signal inversion in software is
perfectly fine. And I also think that it makes sense to put it once into
the framework instead of bothering all consumer drivers with the
inversion.

Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
--
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] tick, broadcast: Prevent false alarm when force mask contains offline cpus

[Preeti U Murthy]

Hi Thomas,
Any comments on this patch?

Regards
Preeti U Murthy

On 04/01/2014 11:02 AM, Preeti U Murthy wrote:
> On 03/28/2014 02:17 PM, Srivatsa S. Bhat wrote:
>> On 03/27/2014 03:44 PM, Preeti U Murthy wrote:
>>> On 03/27/2014 11:58 AM, Srivatsa S. Bhat wrote:

 Actually, my suggestion was to remove the dying CPU from the force_mask 
 alone,
 in the CPU_DYING notifier. The rest of the cleanup (removing it from the 
 other
 masks, moving the broadcast duty to someone else etc can still be done at
 the CPU_DEAD stage). Also, note that the CPU which is set in force_mask is
 definitely not the one doing the broadcast.

 Basically, my reasoning was this:

 If we look at how the 3 broadcast masks (oneshot, pending and force) are
 set and cleared during idle entry/exit, we see this pattern:

 oneshot_mask: This is set at BROADCAST_ENTER and cleared at EXIT.
 pending_mask: This is set at tick_handle_oneshot_broadcast and cleared at
   EXIT.
 force_mask:   This is set at EXIT and cleared at the next call to
   tick_handle_oneshot_broadcast. (Also, if the CPU is set in 
 this
   mask, the CPU doesn't enter deep idle states in subsequent
   idle durations, and keeps polling instead, until it gets the
   broadcast interrupt).

 What we can derive from this is that force_mask is the only mask that can
 remain set across an idle ENTER/EXIT sequence. Both of the other 2 masks
 can never remain set across a full idle ENTER/EXIT sequence. And a CPU 
 going
 offline certainly goes through EXIT if it had gone through ENTER, before
 entering stop_machine().

 That means, force_mask is the only odd one out here, which can remain set
 when entering stop_machine() for CPU offline. So that's the only mask that
 needs to be cleared separately. The other 2 masks take care of themselves
 automatically. So, we can have a CPU_DYING callback which just clears the
 dying CPU from the force_mask (and does nothing more). That should work, 
 no?
>>>
>>> Yep I think this will work. Find the modified patch below:
>>>
>>> Thanks.
>>>
>>> Regards
>>> Preeti U Murthy
>>>
>>>
>>> tick,broadcast:Clear hotplugged cpu in broadcast masks during CPU_DYING 
>>> notification
>>>
>>> From: Preeti U Murthy 
>>>
>>> Its possible that the tick_broadcast_force_mask contains cpus which are not
>>> in cpu_online_mask when a broadcast tick occurs. This could happen under the
>>> following circumstance assuming CPU1 is among the CPUs waiting for 
>>> broadcast.
>>>
>>> CPU0CPU1
>>>
>>> Run CPU_DOWN_PREPARE notifiers
>>>
>>> Start stop_machine  Gets woken up by IPI to run
>>> stop_machine, sets itself in
>>> tick_broadcast_force_mask if the
>>> time of broadcast interrupt is around
>>> the same time as this IPI.
>>>
>>> Start stop_machine
>>>   set_cpu_online(cpu1, false)
>>> End stop_machineEnd stop_machine
>>>
>>> Broadcast interrupt
>>>   Finds that cpu1 in
>>>   tick_broadcast_force_mask is offline
>>>   and triggers the WARN_ON in
>>>   tick_handle_oneshot_broadcast()
>>>
>>> Clears all broadcast masks
>>> in CPU_DEAD stage.
>>>
>>> While the hotplugged cpu clears its bit in the tick_broadcast_oneshot_mask
>>> and tick_broadcast_pending mask during BROADCAST_EXIT, it *sets* its bit
>>> in the tick_broadcast_force_mask if the broadcast interrupt is found to be
>>> around the same time as the present time. Today we clear all the broadcast
>>> masks and shutdown tick devices in the CPU_DEAD stage. But as shown above
>>> the broadcast interrupt could occur before this stage is reached and the
>>> WARN_ON() gets triggered when it is found that the tick_broadcast_force_mask
>>> contains an offline cpu.
>>>
>>> This WARN_ON was added to capture scenarios where the broadcast mask, be it
>>> oneshot/pending/force_mask contain offline cpus whose tick devices have been
>>> removed. But here is a case where we trigger the WARN_ON() when the tick
>>> device of the hotplugged cpu is still around but we are delaying the 
>>> clearing
>>> of the broadcast masks. This has not been a problem for
>>> tick_broadcastoneshot_mask and tick_broadcast_pending_mask since they get
>>> cleared on exit from broadcast.
>>>But since the force_mask gets set at the same time on certain occasions
>>> it is necessary to move the clearing of masks to a stage during cpu hotplug
>>> before the hotplugged cpu clears itself in the online_mask.
>>>
>>
>> That last sentence is not entirely accurate. During stop-machine in the CPU
>> offline path, the CPU removes itself from the cpu_online_mask at the 

Re: [Intel-gfx] i915 DVI resolution regression (3.13.7+)

[Daniel J Blueman]

On 9 April 2014 11:41, Dave Airlie  wrote:
> On Tue, Apr 8, 2014 at 5:32 PM, Daniel J Blueman  wrote:
>> On 8 April 2014 15:14, Jani Nikula  wrote:
>>> On Tue, 08 Apr 2014, Daniel J Blueman  wrote:
 Ville et al,

 It looks like commit e3ea8fa6beaf55fee64bf816f3b8a80ad733b2c2 (or
 another commit in 3.13.7) broke modes which require DVI-D dual-link,
 eg 2560x1440 with my panel.

 I don't see these modelines in 3.13.7 or later (eg 3.14):

 [ 5.582] (II) intel(0): Modeline "2560x1440"x60.0  312.25  2560
 2752 3024 3488  1440 1443 1448 1493 -hsync +vsync (89.5 kHz eP)
 [ 5.582] (II) intel(0): Modeline "2560x1440"x60.0  312.25  2560
 2752 3024 3488  1440 1443 1448 1493 -hsync +vsync (89.5 kHz eP)
 [ 5.582] (II) intel(0): Modeline "1920x1200"x59.9  193.25  1920
 2056 2256 2592  1200 1203 1209 1245 -hsync +vsync (74.6 kHz e)

 My monitor is a Dell U2713HM; mobo uses an H87 chipset with i5-4670.
>>>
>>> By allowing those modes we regressed setups which were not capable of
>>> displaying them. So you've got an HDMI->DVI converter?
>>>
>>> https://bugzilla.kernel.org/show_bug.cgi?id=72961
>>
>> I am using a dual-link DVI-D to DVI-D cable to this monitor, since I
>> previously couldn't get 2560x1440 via HDMI.
>
> Intel hw has dual-link DVI-D? I'm not sure I've ever seen that, is
> this SDVO device or plain DVI-D?

It's the DVI-D connector on: https://www.asus.com/Motherboards/H87IPLUS/

However, it is logically detected as HDMI-0:

$ xrandr
Screen 0: minimum 320 x 320, current 2560 x 1440, maximum 32767 x 32767
VGA-0 disconnected (normal left inverted right x axis y axis)
HDMI-0 connected primary 2560x1440+0+0 (normal left inverted right x
axis y axis) 600mm x 340mm
   2560x1440  60.0*+
   1920x1200  59.9
   1920x1080  60.0
   1600x1200  59.9
   1680x1050  59.9
   1280x1024  74.9 59.9
   1280x800   59.8
   1152x864   74.8
   1024x768   74.9 59.9
   800x60074.9 60.3
   640x48074.8 59.4
   720x40069.8
HDMI-1 disconnected (normal left inverted right x axis y axis)

Using the mobo HDMI socket and a HDMI to dual-link DVI-D cable
(logically detected as HDMI-1), the same patch causes the same issue.

Thanks,
  Daniel
-- 
Daniel J Blueman
--
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: [PATCHv3 1/3] pwm: make the PWM_POLARITY flag in DTB optional

[Lothar Waßmann]

Hi,

Tim Kryger wrote:
> On Mon, Apr 7, 2014 at 10:02 PM, Lothar Waßmann 
> wrote:
> >
> >
> > Thierry Reding wrote:
> >
> > > No. You cannot emulate polarity inversion in software.
> > >
> > Why not?
> >
> > duty_ns = period_ns - duty_ns;
> >
> 
> Since I made the same mistake, I will pass along the pointer Thierry gave
> me.
> 
> In include/linux/pwm.h the second difference for an inverted signal is
> described.
> 
> /**
>  * enum pwm_polarity - polarity of a PWM signal
>  * @PWM_POLARITY_NORMAL: a high signal for the duration of the duty-
>  * cycle, followed by a low signal for the remainder of the pulse
>  * period
>  * @PWM_POLARITY_INVERSED: a low signal for the duration of the duty-
>  * cycle, followed by a high signal for the remainder of the pulse
>  * period
>  */
> enum pwm_polarity {
> PWM_POLARITY_NORMAL,
> PWM_POLARITY_INVERSED,
> };
> 
> Of course, I suspect not all PWM hardware respects this definition of
> inverted output.
> 
> Either way, hacking the duty in software certainly would get the high/low
> order wrong.
> 
OK. But for a periodic signal this doesn't make any difference. It's
just a matter of where you set your reference point.
Only if you program the PWM to create a single cycle you would see the
difference. I wonder if this is a real life usecase though.


Lothar Waßmann
-- 
___

Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Geschäftsführer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996

www.karo-electronics.de | i...@karo-electronics.de
___
--
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/

CKRM, WorkLoad Management!

[Eugène Ngontang]

Hi all,


I've recently discover the CKRM project/framework, which intends to
integrate workload management in linux kernel.

I'm trying to master the concept, and I've some basic questions :
 - Is it or will it be possible to manage workload on remote systems
via the framework?
 - Could one use the framework to make applications/programs
development at the user level? For example coordinate in real-time a
varied set of workload types with dependencies across a broad spectrum
of operating systems and application platforms.

In other words I would like to know if the project is just for kernel
development, or can be also used in application development.

With regards,
Eugène NG

-- 
ngont...@epitech.net
sympav...@gmail.com

Aux hommes il faut un chef, et au chef il faut des hommes!
L'habit ne fait pas le moine, mais lorsqu'on te voit on te juge!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH v2] edac: synopsys: Added EDAC support for zynq ddr ecc controller

[punnaiah choudary kalluri]

On Wed, Apr 9, 2014 at 2:10 AM, Borislav Petkov  wrote:
> On Mon, Mar 17, 2014 at 10:53:44AM +0530, Punnaiah Choudary Kalluri wrote:
>> Added EDAC support for reporting the ecc errors of synopsys ddr controller.
>> The ddr ecc controller corrects single bit errors and detects double bit
>> errors
>>
>> Signed-off-by: Punnaiah Choudary Kalluri 
>> ---
>> Changes for v2:
>> - Updated the commit header and message
>> - Renamed the filenames to synopsys_edac
>> - Corrected the compatilble string, commnets
>> - Renamed the macros,fucntions and data structures
>> ---
>>  .../devicetree/bindings/edac/synopsys_edac.txt |   18 +
>>  drivers/edac/Kconfig   |7 +
>>  drivers/edac/Makefile  |1 +
>>  drivers/edac/synopsys_edac.c   |  614 
>> 
>>  4 files changed, 640 insertions(+), 0 deletions(-)
>>  create mode 100644 Documentation/devicetree/bindings/edac/synopsys_edac.txt
>>  create mode 100644 drivers/edac/synopsys_edac.c
>>
>> diff --git a/Documentation/devicetree/bindings/edac/synopsys_edac.txt 
>> b/Documentation/devicetree/bindings/edac/synopsys_edac.txt
>> new file mode 100644
>> index 000..c4a559b
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/edac/synopsys_edac.txt
>> @@ -0,0 +1,18 @@
>> +Synopsys EDAC driver, it does reports the DDR ECC single bit errors that are
>> +corrected and double bit ecc errors that are detected by the DDR ECC 
>> controller.
>> +ECC support for DDR is available in half-bus width(16 bit) configuration 
>> only.
>> +
>> +Required properties:
>> +- compatible: Should be "xlnx,zynq-ddrc-1.04"
>> +- reg: Should contain DDR controller registers location and length.
>> +
>> +Example:
>> +
>> +
>> +ddrc0: ddrc@f8006000 {
>> + compatible = "xlnx,zynq-ddrc-1.04";
>> + reg = <0xf8006000 0x1000>;
>> +};
>> +
>> +Synopsys EDAC driver detects the DDR ECC enable state by reading the 
>> appropriate
>> +control register.
>> diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
>> index 878f090..58b69b1 100644
>> --- a/drivers/edac/Kconfig
>> +++ b/drivers/edac/Kconfig
>> @@ -368,4 +368,11 @@ config EDAC_OCTEON_PCI
>> Support for error detection and correction on the
>> Cavium Octeon family of SOCs.
>>
>> +config EDAC_SYNOPSYS
>> + tristate "Synopsys DDR Memory Controller"
>> + depends on EDAC_MM_EDAC && ARCH_ZYNQ
>> + help
>> +   This enables support for EDAC on the ECC memory used
>> +   with the Synopsys DDR memory controller.
>
> s/This enables s/S/
>
>> +
>>  endif # EDAC
>> diff --git a/drivers/edac/Makefile b/drivers/edac/Makefile
>> index 4154ed6..5628a6f 100644
>> --- a/drivers/edac/Makefile
>> +++ b/drivers/edac/Makefile
>> @@ -64,3 +64,4 @@ obj-$(CONFIG_EDAC_OCTEON_PC)+= 
>> octeon_edac-pc.o
>>  obj-$(CONFIG_EDAC_OCTEON_L2C)+= octeon_edac-l2c.o
>>  obj-$(CONFIG_EDAC_OCTEON_LMC)+= octeon_edac-lmc.o
>>  obj-$(CONFIG_EDAC_OCTEON_PCI)+= octeon_edac-pci.o
>> +obj-$(CONFIG_EDAC_SYNOPSYS)  += synopsys_edac.o
>> diff --git a/drivers/edac/synopsys_edac.c b/drivers/edac/synopsys_edac.c
>> new file mode 100644
>> index 000..7cec331
>> --- /dev/null
>> +++ b/drivers/edac/synopsys_edac.c
>> @@ -0,0 +1,614 @@
>> +/*
>> + * Synopsys DDR ECC Driver
>> + * This driver is based on ppc4xx_edac.c drivers
>> + *
>> + * Copyright (C) 2012 - 2014 Xilinx, Inc.
>
> The same question to you: are you going to maintain this driver? If so,
> please consider adding yourself to the MAINTAINERS file so that people
> reporting issues with it can send you a note.

Let me check internally with team and get back to you on this.
>
>> + *
>> + * This program is free software: you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation, either version 2 of the License, or
>> + * (at your option) any later version.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program.  If not, see .
>> + */
>
> Please drop the GPL boilerplate - simply refer to the COPYING file in
> the kernel source repository instead.
>
>> +
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include "edac_core.h"
>> +
>> +/* Number of cs_rows needed per memory controller */
>> +#define SYNOPSYS_EDAC_NR_CSROWS  1
>> +
>> +/* Number of channels per memory controller */
>> +#define SYNOPSYS_EDAC_NR_CHANS   1
>> +
>> +/* Granularity of reported error in bytes */
>> +#define SYNOPSYS_EDAC_ERROR_GRAIN1
>> +
>> +#define SYNOPSYS_EDAC_MESSAGE_SIZE   256
>> +
>> +/* 

Re: [GIT] kbuild/lto changes for 3.15-rc1

[Ingo Molnar]

* Andi Kleen  wrote:

> On Tue, Apr 08, 2014 at 03:44:25PM -0700, Linus Torvalds wrote:
> > On Tue, Apr 8, 2014 at 1:49 PM,   wrote:
> > >
> > > In addition to making the kernel smaller and such (I'll leave the
> > > specific stats there to Andi), here's the key awesomeness of LTO that
> > > you, personally, should find useful and compelling: LTO will eliminate
> > > the need to add many lower-level Kconfig symbols to compile out bits of
> > > the kernel.
> > 
> > Actually that, to me, is a negative right now.
> > 
> > Since there's no way we'll make LTO the default in the foreseeable
> > future, people starting to use it like that is just a bad bad thing.
> > 
> > So really, the main advantage of LTO would be any actual 
> > optimizations it can do. And call me anal, but I want *numbers* 
> > for that before I merge it. Not handwaving. I'm not actually aware 
> > of how well - if at all - code generation actually improves.
> 
> Well it looks very different if you look at the generated code. gcc 
> becomes a lot more aggressive.
> 
> But as I said there's currently no significant performance 
> improvement known, so if your only goal is better performance this 
> patch (as currently) known is not a big winner.  My suspicion is 
> that's mostly because the standard benchmarks we run are not too 
> compiler sensitive.
> 
> However the users seem to care about the other benefits, like code 
> size.
> 
> And there may well be loads that are compiler sensitive. As Honza 
> posted, for non kernel workloads LTO is known to have large 
> benefits.
> 
> Besides at this point it's pretty much just some additions to the 
> Makefiles.

So the reason I've been mostly ignoring the LTO patches myself (I only 
took LTO related changes that had other justifications such as 
cleanups) is that I've actually implemented full LTO in a userspace 
project myself, and my experience was:

  1) There was very little if any measurable LTO runtime speedup, 
 despite agressive GCC options and despite user-space generally 
 offering more optimizations opportunities than kernel space.

  2) LTO with current build tools meant a 1.5x-3x build speed
 slowdown (on a very fast box with tons of CPUs and RAM),
 which made LTO essentially a non-starter for development
 work. (And that was with the Gold linker.)

and looking at your characterisation of LTO you only conceded
#1 much after you started pushing LTO and you are clearly trying
to avoid talking about #2 while it's very much relevant...

I'm willing to be convinced by actual numbers, and LTO tooling might 
eventually improve, etc., but right now LTO is much ado about very 
little, being pushed in a somewhat dishonest way.

Thanks,

Ingo
--
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 07/15] mtd: st_spi_fsm: Extend fsm_clear_fifo to handle unwanted bytes

[Brian Norris]

On Wed, Mar 26, 2014 at 04:39:21PM +, Lee Jones wrote:
> From: Angus Clark 
...
> diff --git a/drivers/mtd/devices/st_spi_fsm.c 
> b/drivers/mtd/devices/st_spi_fsm.c
> index 8c56b94..9df59e7 100644
> --- a/drivers/mtd/devices/st_spi_fsm.c
> +++ b/drivers/mtd/devices/st_spi_fsm.c
...
> + dev_dbg(fsm->dev, "cleared %d byte(s) from the data FIFO\n", 4 - i);
> +}
> +
>  static int stfsm_write_fifo(struct stfsm *fsm, uint32_t *buf, uint32_t size)

This patch does not apply to l2-mtd.git, and neither do several of the
following patches. You probably didn't rebase onto the patches regarding
the above line (adding 'const').

>  {
>   uint32_t words = size >> 2;

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

[PATCH v2] kbuild: move extra gcc checks to scripts/Makefile.extrawarn

[Masahiro Yamada]

W=... provides extra gcc checks.

Having such code in scripts/Makefile.build results in the same flags
being added to KBUILD_CFLAGS multiple times becuase
scripts/Makefile.build is invoked every time Kbuild descends into
the subdirectories.

Since the top Makefile is already too cluttered, this commit moves
all of extra gcc check stuff to a new file scripts/Makefile.extrawarn,
which is included from the top Makefile.

Signed-off-by: Masahiro Yamada 
Cc: Michal Marek 
CC: Sam Ravnborg 
---

Changes in v2:
  - Move the code to a new file scripts/Makefile.extrawarn
  - Move also "KBUILD_ENABLE_EXTRA_GCC_CHECKS" definition



 Makefile   |  6 ++---
 scripts/Makefile.build | 51 -
 scripts/Makefile.extrawarn | 57 ++
 3 files changed, 59 insertions(+), 55 deletions(-)
 create mode 100644 scripts/Makefile.extrawarn

diff --git a/Makefile b/Makefile
index cf3e075..4eadf2d 100644
--- a/Makefile
+++ b/Makefile
@@ -105,10 +105,6 @@ ifeq ("$(origin O)", "command line")
   KBUILD_OUTPUT := $(O)
 endif
 
-ifeq ("$(origin W)", "command line")
-  export KBUILD_ENABLE_EXTRA_GCC_CHECKS := $(W)
-endif
-
 # That's our default target when none is given on the command line
 PHONY := _all
 _all:
@@ -702,6 +698,8 @@ ifeq ($(shell $(CONFIG_SHELL) 
$(srctree)/scripts/gcc-goto.sh $(CC)), y)
KBUILD_CFLAGS += -DCC_HAVE_ASM_GOTO
 endif
 
+include $(srctree)/scripts/Makefile.extrawarn
+
 # Add user supplied CPPFLAGS, AFLAGS and CFLAGS as the last assignments
 KBUILD_CPPFLAGS += $(KCPPFLAGS)
 KBUILD_AFLAGS += $(KAFLAGS)
diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index 9f0ee22..b5e02b6 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -50,57 +50,6 @@ ifeq ($(KBUILD_NOPEDANTIC),)
 endif
 endif
 
-#
-# make W=... settings
-#
-# W=1 - warnings that may be relevant and does not occur too often
-# W=2 - warnings that occur quite often but may still be relevant
-# W=3 - the more obscure warnings, can most likely be ignored
-#
-# $(call cc-option, -W...) handles gcc -W.. options which
-# are not supported by all versions of the compiler
-ifdef KBUILD_ENABLE_EXTRA_GCC_CHECKS
-warning-  := $(empty)
-
-warning-1 := -Wextra -Wunused -Wno-unused-parameter
-warning-1 += -Wmissing-declarations
-warning-1 += -Wmissing-format-attribute
-warning-1 += -Wmissing-prototypes
-warning-1 += -Wold-style-definition
-warning-1 += $(call cc-option, -Wmissing-include-dirs)
-warning-1 += $(call cc-option, -Wunused-but-set-variable)
-warning-1 += $(call cc-disable-warning, missing-field-initializers)
-
-warning-2 := -Waggregate-return
-warning-2 += -Wcast-align
-warning-2 += -Wdisabled-optimization
-warning-2 += -Wnested-externs
-warning-2 += -Wshadow
-warning-2 += $(call cc-option, -Wlogical-op)
-warning-2 += $(call cc-option, -Wmissing-field-initializers)
-
-warning-3 := -Wbad-function-cast
-warning-3 += -Wcast-qual
-warning-3 += -Wconversion
-warning-3 += -Wpacked
-warning-3 += -Wpadded
-warning-3 += -Wpointer-arith
-warning-3 += -Wredundant-decls
-warning-3 += -Wswitch-default
-warning-3 += $(call cc-option, -Wpacked-bitfield-compat)
-warning-3 += $(call cc-option, -Wvla)
-
-warning := $(warning-$(findstring 1, $(KBUILD_ENABLE_EXTRA_GCC_CHECKS)))
-warning += $(warning-$(findstring 2, $(KBUILD_ENABLE_EXTRA_GCC_CHECKS)))
-warning += $(warning-$(findstring 3, $(KBUILD_ENABLE_EXTRA_GCC_CHECKS)))
-
-ifeq ("$(strip $(warning))","")
-$(error W=$(KBUILD_ENABLE_EXTRA_GCC_CHECKS) is unknown)
-endif
-
-KBUILD_CFLAGS += $(warning)
-endif
-
 include scripts/Makefile.lib
 
 ifdef host-progs
diff --git a/scripts/Makefile.extrawarn b/scripts/Makefile.extrawarn
new file mode 100644
index 000..54aaddb
--- /dev/null
+++ b/scripts/Makefile.extrawarn
@@ -0,0 +1,57 @@
+# ==
+#
+# make W=... settings
+#
+# W=1 - warnings that may be relevant and does not occur too often
+# W=2 - warnings that occur quite often but may still be relevant
+# W=3 - the more obscure warnings, can most likely be ignored
+#
+# $(call cc-option, -W...) handles gcc -W.. options which
+# are not supported by all versions of the compiler
+# ==
+
+ifeq ("$(origin W)", "command line")
+  export KBUILD_ENABLE_EXTRA_GCC_CHECKS := $(W)
+endif
+
+ifdef KBUILD_ENABLE_EXTRA_GCC_CHECKS
+warning-  := $(empty)
+
+warning-1 := -Wextra -Wunused -Wno-unused-parameter
+warning-1 += -Wmissing-declarations
+warning-1 += -Wmissing-format-attribute
+warning-1 += -Wmissing-prototypes
+warning-1 += -Wold-style-definition
+warning-1 += $(call cc-option, -Wmissing-include-dirs)
+warning-1 += $(call cc-option, -Wunused-but-set-variable)
+warning-1 += $(call cc-disable-warning, missing-field-initializers)
+
+warning-2 := -Waggregate-return
+warning-2 += -Wcast-align
+warning-2 += -Wdisabled-optimization
+warning-2 += -Wnested-externs

Re: [PATCH] futex: avoid race between requeue and wake

[Mike Galbraith]

On Wed, 2014-04-09 at 07:41 +0200, Peter Zijlstra wrote: 
> On Tue, Apr 08, 2014 at 03:30:07PM -0700, Linus Torvalds wrote:
> > So I'll have to leave this decision to the futex people. But the
> > attached slightly more complex patch *may* be the better one.
> 
> Of course, tglx is the main futex 'people' and he's not on CC.. *sigh*.

(Darren is a futex people _and_ a futextest people)

--
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 01/15] mtd: st_spi_fsm: Add Macronix MX25L25655E device

[Brian Norris]

On Thu, Mar 27, 2014 at 08:20:47AM +, Lee Jones wrote:
> > > From: Angus Clark 
> > >
> > > Add Macronix MX25L25655E to the list of known devices.
> > >
> > > Signed-off-by: Angus Clark 
> > > Signed-off-by: Lee Jones 
> > > ---
> > >  drivers/mtd/devices/st_spi_fsm.c | 3 +++
> > >  1 file changed, 3 insertions(+)
> > >
> > > diff --git a/drivers/mtd/devices/st_spi_fsm.c 
> > > b/drivers/mtd/devices/st_spi_fsm.c
> > > index bea1416..2471061 100644
> > > --- a/drivers/mtd/devices/st_spi_fsm.c
> > > +++ b/drivers/mtd/devices/st_spi_fsm.c
> > > @@ -380,6 +380,9 @@ static struct flash_info flash_types[] = {
> > > { "mx25l25635e", 0xc22019, 0, 64*1024, 512,
> > >   (MX25_FLAG | FLASH_FLAG_32BIT_ADDR | FLASH_FLAG_RESET), 70,
> > >   stfsm_mx25_config },
> > > +   { "mx25l25655e", 0xc22619, 0, 64*1024, 512,
> > > + (MX25_FLAG | FLASH_FLAG_32BIT_ADDR | FLASH_FLAG_RESET), 70,
> > > + stfsm_mx25_config},
> > >
> > >  #define N25Q_FLAG (FLASH_FLAG_READ_WRITE   |   \
> > >FLASH_FLAG_READ_FAST |   \
> > 
> > How much of this table can be shared with the one in m25p80.c?
> 
> I have a long term plan to merge the two. Just waiting for the SPI NOR
> Framework to land before I do so.

Huang's work landed in the spinor branch at l2-mtd.git a bit ago. I will
take a look at this series and probably take this as-is, but long-term I
will not be taking many more additions to this custom table.

Regards,
Brian
--
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/6 V2] perf, sort: Add physid sorting based on mmap2 data

[Peter Zijlstra]

On Wed, Apr 09, 2014 at 02:21:49PM +0900, Namhyung Kim wrote:
> > create a new 'physid mode' to group all the sorting rules together
> >   (mimics the mem-mode)
> 
> What is 'physid' then?  I guess you meant physical id but it seems
> unique id or unique map id looks like a better fit IMHO.

I suspect this is legacy naming; they used to do this using physical
addresses.
--
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] futex: avoid race between requeue and wake

[Peter Zijlstra]

On Tue, Apr 08, 2014 at 03:30:07PM -0700, Linus Torvalds wrote:
> So I'll have to leave this decision to the futex people. But the
> attached slightly more complex patch *may* be the better one.

Of course, tglx is the main futex 'people' and he's not on CC.. *sigh*.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL 00/10] perf/core improvements and fixes

[Ingo Molnar]

* Namhyung Kim  wrote:

> Hi Andi,
> 
> On Wed, Apr 9, 2014 at 4:50 AM, Andi Kleen  wrote:
> > Jiri Olsa  writes:
> >
> >> hi Ingo,
> >> please consider pulling
> >
> > So who actually maintains perf user space now?
> >
> > I have at least 4 perf user patchkits/bug fixes pending, but 
> > Arnaldo hasn't answered any email for weeks.

So a bit of background: sloppy, abusive contributors not willing to 
change get ignored after some time. For example Andi got such a bad 
track record in the x86 and perf space with me that all your mails go 
to /dev/null currently. (I only saw this one because Namhyung replied 
to it.)

Andi, as I explained it to you previously, if you want me to merge 
patches from you then you need to 1) improve the way you work 2) send 
it to someone who is willing to deal with you and sign off on it and 
forward it to me.

Seems like you managed to burn up your goodwill with Arnaldo as well. 
You need to find someone else willing to pay the expense of dealing 
with your passive-aggressive style.

Just a quick example of your abuse: for example you know it perfectly 
well that perf is well maintained, a simple 'git log tools/perf/' will 
tell you that there's a steady stream of patches going in and that 
perf contributors are busy.

Yet in this mail you actually lie about that: you pretend that you 
don't know that most Linux maintainers have trouble working with you, 
you pretend that perf is "unmaintained", you pretend that you don't 
know who is maintaining it, just to create unfair pressure on Arnaldo 
...

That kind of approach really sucks, and if you run out of people's 
patience with petty office tactics like that then you should not fault 
them, you should fault yourself.

Thanks,

Ingo
--
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 6/6] perf, sort: Allow unique sorting instead of combining hist_entries

[Namhyung Kim]

On Mon, 24 Mar 2014 15:34:36 -0400, Don Zickus wrote:
> The cache contention tools needs to keep all the perf records unique in order
> to properly parse all the data.  Currently add_hist_entry() will combine
> the duplicate record and add the weight/period to the existing record.
>
> This throws away the unique data the cache contention tool needs (mainly
> the data source).  Create a flag to force the records to stay unique.

No.  This is why I said you need to add 'mem' and 'snoop' sort keys into
the c2c tool.  This is not how sort works IMHO - if you need to make
samples unique let the sort key(s) distinguish them somehow, or you can
combine same samples (in terms of sort kes) and use the combined entry's
stat.nr_events and stat.period or weight.

Thanks,
Namhyung
--
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: [FMC] BUG: scheduling while atomic: swapper/1/0x10000002

[Fengguang Wu]

On Wed, Apr 09, 2014 at 07:08:43AM +0200, Alessandro Rubini wrote:
> Hello.
> Thank you for the report.
> 
> I'm at a conference and I fear I won't be able to test myself in the
> next days, but I think this is already fixed (it is part of
> the "misc_register" call path, so it's the same problem).
> 
> The fix is commit v3.11-rc2-11-g783c2fb
> 
>783c2fb FMC: fix locking in sample chardev driver
> 
> This commit, however, is not part of v3.11 and I think this is why you
> are finding the problem in the v3.10..v3.11 interval.

Alessandro, you are right. There are no more "scheduling while 
atomic" bugs in v3.12 and v3.13.

Our bisect log shows

git bisect  bad 38dbfb59d1175ef458d006556061adeaa8751b72  # 10:03  0-
345  Linus 3.14-rc1

However that happen to be caused by an independent "scheduling while
atomic" bug:

[   20.038125] Fixing recursive fault but reboot is needed!
[   20.038125] BUG: scheduling while atomic: kworker/0:1H/77/0x0005
[   20.038125] INFO: lockdep is turned off.
[   20.038125] irq event stamp: 758
[   20.038125] hardirqs last  enabled at (757): [] 
_raw_spin_unlock_irq+0x22/0x30
[   20.038125] hardirqs last disabled at (758): [] 
_raw_spin_lock_irq+0x14/0x73
[   20.038125] softirqs last  enabled at (302): [] 
__do_softirq+0x186/0x1d2
[   20.038125] softirqs last disabled at (295): [] 
do_softirq_own_stack+0x2f/0x35
[   20.038125] CPU: 0 PID: 77 Comm: kworker/0:1H Tainted: G  D W
3.14.0-rc1 #1
[   20.038125] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[   20.038125]  c0420610 c0420610 c0449a38 c1c1f562 c0449a54 c1c1b59c c1f91661 
c0420938
[   20.038125]  004d 0005 c0420610 c0449acc c1c2e4e2 c105fff8 01449a7c 
04af
[   20.038125]  c0420610 002c 0001 c0449a7c c0420610 c0449ab4 c106001c 

[   20.038125] Call Trace:
[   20.038125]  [] dump_stack+0x16/0x18
[   20.038125]  [] __schedule_bug+0x5d/0x6f
[   20.038125]  [] __schedule+0x45/0x55f
[   20.038125]  [] ? vprintk_emit+0x367/0x3a4
[   20.038125]  [] ? vprintk_emit+0x38b/0x3a4
[   20.038125]  [] ? trace_hardirqs_off+0xb/0xd
[   20.038125]  [] ? printk+0x38/0x3a
[   20.038125]  [] schedule+0x5d/0x5f
[   20.038125]  [] do_exit+0xcc/0x75d
[   20.038125]  [] ? kmsg_dump+0x184/0x191
[   20.038125]  [] ? kmsg_dump+0x1c/0x191
[   20.038125]  [] oops_end+0x7e/0x83
[   20.038125]  [] no_context+0x1ba/0x1c2
[   20.038125]  [] __bad_area_nosemaphore+0x137/0x13f
[   20.038125]  [] ? pte_offset_kernel+0x13/0x2a
[   20.038125]  [] ? spurious_fault+0x75/0xd5
[   20.038125]  [] bad_area_nosemaphore+0x12/0x14

Thanks,
Fengguang
--
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: [FMC] BUG: scheduling while atomic: swapper/1/0x10000002

[Jet Chen]

On 04/09/2014 01:08 PM, Alessandro Rubini wrote:
> Hello.
> Thank you for the report.
> 
> I'm at a conference and I fear I won't be able to test myself in the
> next days, but I think this is already fixed (it is part of
> the "misc_register" call path, so it's the same problem).
> 
> The fix is commit v3.11-rc2-11-g783c2fb
> 
>783c2fb FMC: fix locking in sample chardev driver
> 
> This commit, however, is not part of v3.11 and I think this is why you
> are finding the problem in the v3.10..v3.11 interval.
> 
> thank you again
> /alessandro
> 

I find commit 783c2fb FMC: fix locking in sample chardev driver. I will help to 
test it.
--
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: [FMC] BUG: scheduling while atomic: swapper/1/0x10000002

[Alessandro Rubini]

Hello.
Thank you for the report.

I'm at a conference and I fear I won't be able to test myself in the
next days, but I think this is already fixed (it is part of
the "misc_register" call path, so it's the same problem).

The fix is commit v3.11-rc2-11-g783c2fb

   783c2fb FMC: fix locking in sample chardev driver

This commit, however, is not part of v3.11 and I think this is why you
are finding the problem in the v3.10..v3.11 interval.

thank you again
/alessandro
--
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/6 V2] perf, sort: Add physid sorting based on mmap2 data

[Namhyung Kim]

On Mon, 24 Mar 2014 16:57:18 -0400, Don Zickus wrote:
> In order for the c2c tool to work correctly, it needs to properly
> sort all the records on uniquely identifiable data addresses.  These
> unique addresses are converted from virtual addresses provided by the
> hardware into a kernel address using an mmap2 record as the decoder.
>
> Once a unique address is converted, we can sort on them based on
> various rules.  Then it becomes clear which address are overlapping
> with each other across mmap regions or pid spaces.
>
> This patch just creates the rules and inserts the records into a
> sort entry for safe keeping until later patches process them.
>
> The general sorting rule is:
>
> o group cpumodes together
> o if (nonzero major/minor number - ie mmap'd areas)
>   o sort on major, minor, inode, inode generation numbers
> o else if cpumode is not kernel
>   o sort on pid
> o sort on data addresses
>
> I also hacked in the concept of 'color'.  The purpose of that bit is to
> provides hints later when processing these records that indicate a new unique
> address has been encountered.  Because later processing only checks the data
> addresses, there can be a theoretical scenario that similar sequential data
> addresses (when walking the rbtree) could be misinterpreted as overlapping
> when in fact they are not.
>
> Sample output: (perf report --stdio --physid-mode)
>
>   OverheadData AddressSource AddressCommand:  Pid 
>Tid Major  Minor  Inode  Inode Gen
>     ..   
> . . .  . ... .
> 18.93%  [k] 0xc900139c40b0  [k] igb_update_stats kworker/0:1:  
> 257   257 0  0   0 0
>  7.63%  [k] 0x88082e6cf0a8  [k] watchdog_timer_fnswapper:
> 0 0 0  0   0 0
>  1.86%  [k] 0x88042ef94700  [k] _raw_spin_lock   swapper:
> 0 0 0  0   0 0
>  1.77%  [k] 0x8804278afa50  [k] __switch_to  swapper:
> 0 0 0  0   0 0
>
> V4: add manpage entry in perf-report
>
> V3: split out the sorting into unique entries.  This makes it look
>   far less ugly
> create a new 'physid mode' to group all the sorting rules together
>   (mimics the mem-mode)

What is 'physid' then?  I guess you meant physical id but it seems
unique id or unique map id looks like a better fit IMHO.

>
> Signed-off-by: Don Zickus 
> ---
>  tools/perf/Documentation/perf-report.txt |  23 +++
>  tools/perf/builtin-report.c  |  20 ++-
>  tools/perf/util/hist.c   |  27 ++-
>  tools/perf/util/hist.h   |   8 +
>  tools/perf/util/sort.c   | 294 
> +++
>  tools/perf/util/sort.h   |  13 ++
>  6 files changed, 381 insertions(+), 4 deletions(-)
>
> diff --git a/tools/perf/Documentation/perf-report.txt 
> b/tools/perf/Documentation/perf-report.txt
> index 8eab8a4..01391b0 100644
> --- a/tools/perf/Documentation/perf-report.txt
> +++ b/tools/perf/Documentation/perf-report.txt
> @@ -95,6 +95,23 @@ OPTIONS
>   And default sort keys are changed to comm, dso_from, symbol_from, dso_to
>   and symbol_to, see '--branch-stack'.
>  
> + If --physid-mode option is used, following sort keys are also
> + available:
> + daddr, iaddr, pid, tid, major, minor, inode, inode_gen.
> +
> + - daddr: data address (sorted based on major, minor, inode and inode
> + generation numbers if shared, otherwise pid)

By "if shared", did you mean "for shared file mapping"?


> + - iaddr: instruction address
> + - pid: command and pid of the task
> + - tid: tid of the task
> + - major: major number of mapped location (0 if not mapped)
> + - minor: minor number of mapped location (0 if not mapped)
> + - inode: inode number of mapped location (0 if not mapped)
> + - inode_gen: inode generation number of mapped location (0 if not 
> mapped)

s/if not mapped/if not file-mapped/ ?

> +
> + And default sort keys are changed to daddr, iaddr, pid, tid, major,
> + minor, inode and inode_gen, see '--physid-mode'.
> +
>  -p::
>  --parent=::
>  A regex filter to identify parent. The parent is a caller of this
> @@ -223,6 +240,12 @@ OPTIONS
>   branch stacks and it will automatically switch to the branch view mode,
>   unless --no-branch-stack is used.
>  
> +--physid-mode::
> + Use the data addresses sampled using perf record -d and combine them
> + with the mmap'd area region where they are located.  This helps identify
> + which data addresses collide with similar addresses in another process
> + space.  See --sort for output choices.
> +
>  --objdump=::
>  Path to objdump binary.
>  
> diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
> index c87412b..093f5ad 100644
> --- a/tools/perf/builti

Re: [PATCH 1/2] usb: ehci-exynos: Return immediately from suspend if ehci_suspend fails

[Jingoo Han]

On Wednesday, April 09, 2014 1:01 PM, Vivek Gautam wrote:
> 
> Patch 'b8efdaf USB: EHCI: add check for wakeup/suspend race'
> adds a check for possible race between suspend and wakeup interrupt,
> and thereby it returns -EBUSY as error code if there's a wakeup
> interrupt.
> So the platform host controller should not proceed further with
> its suspend callback, rather should return immediately to avoid
> powering down the essential things, like phy.
> 
> Signed-off-by: Vivek Gautam 
> Cc: Alan Stern 
> Cc: Jingoo Han 

Acked-by: Jingoo Han 

Best regards,
Jingoo Han

> ---
> 
> Based on 'usb-next' branch of Greg's usb tree.
> 
>  drivers/usb/host/ehci-exynos.c |4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
> index d1d8c47..a4550eb 100644
> --- a/drivers/usb/host/ehci-exynos.c
> +++ b/drivers/usb/host/ehci-exynos.c
> @@ -212,6 +212,8 @@ static int exynos_ehci_suspend(struct device *dev)
>   int rc;
> 
>   rc = ehci_suspend(hcd, do_wakeup);
> + if (rc)
> + return rc;
> 
>   if (exynos_ehci->otg)
>   exynos_ehci->otg->set_host(exynos_ehci->otg, &hcd->self);
> @@ -221,7 +223,7 @@ static int exynos_ehci_suspend(struct device *dev)
> 
>   clk_disable_unprepare(exynos_ehci->clk);
> 
> - return rc;
> + return 0;
>  }
> 
>  static int exynos_ehci_resume(struct device *dev)
> --
> 1.7.10.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/

[BUG] kernel BUG at /.../block/cfq-iosched.c:3145!

[Benjamin Herrenschmidt]

Hi folks !

While testing a branch of fixes before I send it to Linus, which
happens to be based on 18a1a7a1d862ae0794a0179473d08a414dd49234,
I hit this:

kernel BUG at /home/benh/linux-powerpc-test/block/cfq-iosched.c:3145!
cpu 0x3c: Vector: 700 (Program Check) at [c03ca69bb190]
pc: c033b05c: .cfq_dispatch_requests+0x90/0x99c
lr: c033b038: .cfq_dispatch_requests+0x6c/0x99c
sp: c03ca69bb410
   msr: 90029032
  current = 0xc03ca63d32a0
  paca= 0xcffef000   softe: 0irq_happened: 0x01
pid   = 3487, comm = smartd
kernel BUG at /home/benh/linux-powerpc-test/block/cfq-iosched.c:3145!
enter ? for help
[c03ca69bb4c0] c032000c .elv_drain_elevator+0x70/0xc8
[c03ca69bb540] c0320140 .__elv_add_request+0xdc/0x27c
[c03ca69bb5e0] c03286f8 .blk_execute_rq_nowait+0xc0/0xf8
[c03ca69bb670] c03287ec .blk_execute_rq+0xbc/0xe8
[c03ca69bb810] c0332350 .sg_io+0x218/0x39c
[c03ca69bb930] c0332c3c .scsi_cmd_ioctl+0x270/0x4ac
[c03ca69bba70] c05d559c .sd_ioctl+0xa4/0xd8
[c03ca69bbb20] c032eb1c .__blkdev_driver_ioctl+0x34/0x54
[c03ca69bbb90] c032f83c .blkdev_ioctl+0x7b8/0x850
[c03ca69bbc40] c018d6e0 .block_ioctl+0x4c/0x60
[c03ca69bbcb0] c01691cc .do_vfs_ioctl+0x5cc/0x670
[c03ca69bbd90] c01692b4 .SyS_ioctl+0x44/0x70
[c03ca69bbe30] c000a024 syscall_exit+0x0/0x98
--- Exception: c00 (System Call) at 3fffb5240ee0

The storage driver is our usual IBM "IPR".

Is that a known issue ?

Cheers,
Ben.
 


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

Re: [clocksource] INFO: possible irq lock inversion dependency detected

[Jet Chen]

On 04/09/2014 12:40 PM, Viresh Kumar wrote:

On 9 April 2014 10:04, Jet Chen  wrote:

How did you got this in cc list ?


"abd38155f8293923de5953cc063f9e2d7ecb3f04.1396679170.git.viresh.ku...@linaro.org"





I got it from the patch you sent to me before. attach it again.
Apologizes if it's improper to cc this list.


There is no list like this :), its just the message id number
generated by git while
sending my patch.


Oh, I see. I'm supposed to in-reply-to that message id. I guess I just simple "reply 
all" so that my email client put it in TO list.
--
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 RESEND] ARM: spear: add __init to spear_clocksource_init()

[Viresh Kumar]

On Wed, Apr 9, 2014 at 4:04 AM, Alex Elder  wrote:
> I get a build warning because spear_clocksource_init() calls
> clocksource_mmio_init(), but it doesn't have an __init annotation.
> Fix that.
>
> Signed-off-by: Alex Elder 
> ---
>  arch/arm/mach-spear/time.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-spear/time.c b/arch/arm/mach-spear/time.c
> index 218ba5b..c4d0931 100644
> --- a/arch/arm/mach-spear/time.c
> +++ b/arch/arm/mach-spear/time.c
> @@ -71,7 +71,7 @@ static void clockevent_set_mode(enum clock_event_mode mode,
>  static int clockevent_next_event(unsigned long evt,
>  struct clock_event_device *clk_event_dev);
>
> -static void spear_clocksource_init(void)
> +static void __init spear_clocksource_init(void)
>  {
> u32 tick_rate;
> u16 val;

Acked-by: Viresh Kumar 
--
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: [clocksource] INFO: possible irq lock inversion dependency detected

[Viresh Kumar]

On 9 April 2014 10:04, Jet Chen  wrote:
>> How did you got this in cc list ?
>>
>>
>> "abd38155f8293923de5953cc063f9e2d7ecb3f04.1396679170.git.viresh.ku...@linaro.org"
>>
>> 
>>
>
> I got it from the patch you sent to me before. attach it again.
> Apologizes if it's improper to cc this list.

There is no list like this :), its just the message id number
generated by git while
sending my patch.
--
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: [clocksource] INFO: possible irq lock inversion dependency detected

[Jet Chen]

On 04/09/2014 12:25 PM, Viresh Kumar wrote:

On 9 April 2014 06:51, Jet Chen  wrote:

spin_lock_irqsave() does fix this issue.

Tested-by: Jet Chen 


Thanks a lot :)



Welcome.


How did you got this in cc list ?

"abd38155f8293923de5953cc063f9e2d7ecb3f04.1396679170.git.viresh.ku...@linaro.org"




I got it from the patch you sent to me before. attach it again.
Apologizes if it's improper to cc this list.

>From abd38155f8293923de5953cc063f9e2d7ecb3f04 Mon Sep 17 00:00:00 2001
Message-Id: 
From: Viresh Kumar 
Date: Sat, 5 Apr 2014 11:43:25 +0530
Subject: [PATCH] clocksource: register cpu notifier to remove timer from
 dying CPU

clocksource core is using add_timer_on() to run clocksource_watchdog() on all
CPUs one by one. But when a core is brought down, clocksource core doesn't
remove this timer from the dying CPU. And in this case timer core gives this
(Gives this only with unmerged code, anyway in the current code as well timer
core is migrating a pinned timer to other CPUs, which is also wrong:
http://www.gossamer-threads.com/lists/linux/kernel/1898117)

migrate_timer_list: can't migrate pinned timer: 81f06a60,
timer->function: 810d7010,deactivating it Modules linked in:

CPU: 0 PID: 1932 Comm: 01-cpu-hotplug Not tainted 3.14.0-rc1-00088-gab3c4fd #4
Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
 0009 88001d407c38 817237bd 88001d407c80
 88001d407c70 8106a1dd 0010 81f06a60
 88001e04d040 81e3d4c0 88001e04d030 88001d407cd0
Call Trace:
 [] dump_stack+0x4d/0x66
 [] warn_slowpath_common+0x7d/0xa0
 [] warn_slowpath_fmt+0x4c/0x50
 [] ? __internal_add_timer+0x113/0x130
 [] ? clocksource_watchdog_kthread+0x40/0x40
 [] migrate_timer_list+0xdb/0xf0
 [] timer_cpu_notify+0xfc/0x1f0
 [] notifier_call_chain+0x4c/0x70
 [] __raw_notifier_call_chain+0xe/0x10
 [] cpu_notify+0x23/0x50
 [] cpu_notify_nofail+0xe/0x20
 [] _cpu_down+0x1ad/0x2e0
 [] cpu_down+0x34/0x50
 [] cpu_subsys_offline+0x14/0x20
 [] device_offline+0x95/0xc0
 [] online_store+0x40/0x90
 [] dev_attr_store+0x18/0x30
 [] sysfs_kf_write+0x3d/0x50

This patch tries to fix this by registering cpu notifiers from clocksource core,
only when we start clocksource-watchdog. And if on the CPU_DEAD notification it
is found that dying CPU was the CPU on which this timer is queued on, then it is
removed from that CPU and queued to next CPU.

Reported-by: Jet Chen 
Reported-by: Fengguang Wu 
Signed-off-by: Viresh Kumar 
---
 kernel/time/clocksource.c | 64 +++
 1 file changed, 53 insertions(+), 11 deletions(-)

diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c
index ba3e502..9e96853 100644
--- a/kernel/time/clocksource.c
+++ b/kernel/time/clocksource.c
@@ -23,16 +23,21 @@
  *   o Allow clocksource drivers to be unregistered
  */
 
+#include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include  /* for spin_unlock_irq() using preempt_count() m68k */
 #include 
 #include 
 
 #include "tick-internal.h"
 
+/* Tracks next CPU to queue watchdog timer on */
+static int timer_cpu;
+
 void timecounter_init(struct timecounter *tc,
 		  const struct cyclecounter *cc,
 		  u64 start_tstamp)
@@ -246,12 +251,25 @@ void clocksource_mark_unstable(struct clocksource *cs)
 	spin_unlock_irqrestore(&watchdog_lock, flags);
 }
 
+void queue_timer_on_next_cpu(void)
+{
+	/*
+	 * Cycle through CPUs to check if the CPUs stay synchronized to each
+	 * other.
+	 */
+	timer_cpu = cpumask_next(timer_cpu, cpu_online_mask);
+	if (timer_cpu >= nr_cpu_ids)
+		timer_cpu = cpumask_first(cpu_online_mask);
+	watchdog_timer.expires = jiffies + WATCHDOG_INTERVAL;
+	add_timer_on(&watchdog_timer, timer_cpu);
+}
+
 static void clocksource_watchdog(unsigned long data)
 {
 	struct clocksource *cs;
 	cycle_t csnow, wdnow;
 	int64_t wd_nsec, cs_nsec;
-	int next_cpu, reset_pending;
+	int reset_pending;
 
 	spin_lock(&watchdog_lock);
 	if (!watchdog_running)
@@ -336,27 +354,50 @@ static void clocksource_watchdog(unsigned long data)
 	if (reset_pending)
 		atomic_dec(&watchdog_reset_pending);
 
-	/*
-	 * Cycle through CPUs to check if the CPUs stay synchronized
-	 * to each other.
-	 */
-	next_cpu = cpumask_next(raw_smp_processor_id(), cpu_online_mask);
-	if (next_cpu >= nr_cpu_ids)
-		next_cpu = cpumask_first(cpu_online_mask);
-	watchdog_timer.expires += WATCHDOG_INTERVAL;
-	add_timer_on(&watchdog_timer, next_cpu);
+	queue_timer_on_next_cpu();
 out:
 	spin_unlock(&watchdog_lock);
 }
 
+static int clocksource_cpu_notify(struct notifier_block *self,
+unsigned long action, void *hcpu)
+{
+	long cpu = (long)hcpu;
+
+	spin_lock(&watchdog_lock);
+	if (!watchdog_running)
+		goto notify_out;
+
+	switch (action) {
+	case CPU_DEAD:
+	case CPU_DEAD_FROZEN:
+		if (cpu != timer_cpu)
+			break;
+		del_timer(&watchdog_timer);
+		queue_timer_on_next_cpu();
+		break;
+	}
+
+notify_out:
+	spin_unlock(&watchdog_lock);
+	return NOTIFY_OK;
+}
+
+static struct 

[PATCH V2] clocksource: register cpu notifier to remove timer from dying CPU

[Viresh Kumar]

clocksource core is using add_timer_on() to run clocksource_watchdog() on all
CPUs one by one. But when a core is brought down, clocksource core doesn't
remove this timer from the dying CPU. And in this case timer core gives this
(Gives this only with unmerged code, anyway in the current code as well timer
core is migrating a pinned timer to other CPUs, which is also wrong:
http://www.gossamer-threads.com/lists/linux/kernel/1898117)

migrate_timer_list: can't migrate pinned timer: 81f06a60,
timer->function: 810d7010,deactivating it Modules linked in:

CPU: 0 PID: 1932 Comm: 01-cpu-hotplug Not tainted 3.14.0-rc1-00088-gab3c4fd #4
Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
 0009 88001d407c38 817237bd 88001d407c80
 88001d407c70 8106a1dd 0010 81f06a60
 88001e04d040 81e3d4c0 88001e04d030 88001d407cd0
Call Trace:
 [] dump_stack+0x4d/0x66
 [] warn_slowpath_common+0x7d/0xa0
 [] warn_slowpath_fmt+0x4c/0x50
 [] ? __internal_add_timer+0x113/0x130
 [] ? clocksource_watchdog_kthread+0x40/0x40
 [] migrate_timer_list+0xdb/0xf0
 [] timer_cpu_notify+0xfc/0x1f0
 [] notifier_call_chain+0x4c/0x70
 [] __raw_notifier_call_chain+0xe/0x10
 [] cpu_notify+0x23/0x50
 [] cpu_notify_nofail+0xe/0x20
 [] _cpu_down+0x1ad/0x2e0
 [] cpu_down+0x34/0x50
 [] cpu_subsys_offline+0x14/0x20
 [] device_offline+0x95/0xc0
 [] online_store+0x40/0x90
 [] dev_attr_store+0x18/0x30
 [] sysfs_kf_write+0x3d/0x50

This patch tries to fix this by registering cpu notifiers from clocksource core,
only when we start clocksource-watchdog. And if on the CPU_DEAD notification it
is found that dying CPU was the CPU on which this timer is queued on, then it is
removed from that CPU and queued to next CPU.

Reported-and-tested-by: Jet Chen 
Reported-by: Fengguang Wu 
Signed-off-by: Viresh Kumar 
---
V1->V2:
- Moved 'static int timer_cpu' within #ifdef CONFIG_CLOCKSOURCE_WATCHDOG/endif
- replaced spin_lock with spin_lock_irqsave in clocksource_cpu_notify() as a bug
  is reported by Jet Chen with that.
- Tested again by Jet Chen (Thanks again :))

 kernel/time/clocksource.c | 65 +++
 1 file changed, 54 insertions(+), 11 deletions(-)

diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c
index ba3e502..d288f1f 100644
--- a/kernel/time/clocksource.c
+++ b/kernel/time/clocksource.c
@@ -23,10 +23,12 @@
  *   o Allow clocksource drivers to be unregistered
  */
 
+#include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include  /* for spin_unlock_irq() using preempt_count() m68k */
 #include 
 #include 
@@ -180,6 +182,9 @@ static char override_name[CS_NAME_LEN];
 static int finished_booting;
 
 #ifdef CONFIG_CLOCKSOURCE_WATCHDOG
+/* Tracks current CPU to queue watchdog timer on */
+static int timer_cpu;
+
 static void clocksource_watchdog_work(struct work_struct *work);
 static void clocksource_select(void);
 
@@ -246,12 +251,25 @@ void clocksource_mark_unstable(struct clocksource *cs)
spin_unlock_irqrestore(&watchdog_lock, flags);
 }
 
+static void queue_timer_on_next_cpu(void)
+{
+   /*
+* Cycle through CPUs to check if the CPUs stay synchronized to each
+* other.
+*/
+   timer_cpu = cpumask_next(timer_cpu, cpu_online_mask);
+   if (timer_cpu >= nr_cpu_ids)
+   timer_cpu = cpumask_first(cpu_online_mask);
+   watchdog_timer.expires = jiffies + WATCHDOG_INTERVAL;
+   add_timer_on(&watchdog_timer, timer_cpu);
+}
+
 static void clocksource_watchdog(unsigned long data)
 {
struct clocksource *cs;
cycle_t csnow, wdnow;
int64_t wd_nsec, cs_nsec;
-   int next_cpu, reset_pending;
+   int reset_pending;
 
spin_lock(&watchdog_lock);
if (!watchdog_running)
@@ -336,27 +354,51 @@ static void clocksource_watchdog(unsigned long data)
if (reset_pending)
atomic_dec(&watchdog_reset_pending);
 
-   /*
-* Cycle through CPUs to check if the CPUs stay synchronized
-* to each other.
-*/
-   next_cpu = cpumask_next(raw_smp_processor_id(), cpu_online_mask);
-   if (next_cpu >= nr_cpu_ids)
-   next_cpu = cpumask_first(cpu_online_mask);
-   watchdog_timer.expires += WATCHDOG_INTERVAL;
-   add_timer_on(&watchdog_timer, next_cpu);
+   queue_timer_on_next_cpu();
 out:
spin_unlock(&watchdog_lock);
 }
 
+static int clocksource_cpu_notify(struct notifier_block *self,
+   unsigned long action, void *hcpu)
+{
+   long cpu = (long)hcpu;
+   unsigned long flags;
+
+   spin_lock_irqsave(&watchdog_lock, flags);
+   if (!watchdog_running)
+   goto notify_out;
+
+   switch (action) {
+   case CPU_DEAD:
+   case CPU_DEAD_FROZEN:
+   if (cpu != timer_cpu)
+   break;
+   del_timer(&watchdog_timer);
+   queue_timer_on_next_cpu();

Re: [PATCH 1/3] w1: fix netlink refcnt leak on error path

[David Fries]

This patch is a bug fix, and I see from the mailing list I'm not the
only one to run into this bug, so it would be nice for this patch to
make it into this merge window.  I didn't tag this one for stable
because it doesn't apply cleanly due to previous changes that did make
it into the merge window.  Let me know if I should rewrite it for
stable and which kernel version.

The other two patches are more feature based changes.

On Tue, Apr 08, 2014 at 10:37:07PM -0500, David Fries wrote:
> If the message type is W1_MASTER_CMD or W1_SLAVE_CMD, then a reference
> is taken when searching for the slave or master device.  If there
> isn't any following data m->len (mlen is a copy) is 0 and packing up
> the message for later execution is skipped leaving nothing to
> decrement the reference counts.
> 
> Way back when, m->len was checked before the search that increments the
> reference count, but W1_LIST_MASTERS has no additional data, the check
> was moved in 9be62e0b2fadaf5ff causing this bug.
> 
> This change reorders to put the check before the reference count is
> incremented avoiding the problem.
> 
> Signed-off-by: David Fries 
> Acked-by: Evgeniy Polyakov 

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

Re: [PATCH] cpufreq: highbank: fix ARM_HIGHBANK_CPUFREQ dependency warning

[Viresh Kumar]

On 9 April 2014 08:04, Kefeng Wang  wrote:
> When make ARCH=arm multi_v7_defconfig, we get the following warnings:
>
> warning: (ARM_HIGHBANK_CPUFREQ) selects GENERIC_CPUFREQ_CPU0 which has
> unmet direct dependencies (ARCH_HAS_CPUFREQ && CPU_FREQ && HAVE_CLK
> && REGULATOR && OF && THERMAL && CPU_THERMAL)
>
> To fix this, make ARM_HIGHBANK_CPUFREQ depend on ARCH_HAS_CPUFREQ and
> REGULATOR instead of selecting them, PM_OPP will be selected by 
> ARCH_HAS_CPUFREQ.
>
> Signed-off-by: Kefeng Wang 
> ---
>  drivers/cpufreq/Kconfig.arm | 6 +-
>  1 file changed, 1 insertion(+), 5 deletions(-)

Acked-by: Viresh Kumar 
--
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: [clocksource] INFO: possible irq lock inversion dependency detected

[Viresh Kumar]

On 9 April 2014 06:51, Jet Chen  wrote:
> spin_lock_irqsave() does fix this issue.
>
> Tested-by: Jet Chen 

Thanks a lot :)

How did you got this in cc list ?

"abd38155f8293923de5953cc063f9e2d7ecb3f04.1396679170.git.viresh.ku...@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: [Ocfs2-devel] [PATCH 1/1] OCFS2: Remove NULL assignments on static

[Fabian Frederick]

On Wed, 09 Apr 2014 08:53:14 +0800
Wengang  wrote:

> Hi Fabian,
> 
> What's the badness if we do the assignments?
> 
> thanks,
> wengang

Hi Wengang,

Nothing wrong but AFAICS redundant.

Regards,
Fabian

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

USB: OMAP: questions on patch "Implement runtime idling and remote wakeup for OMAP EHCI controller"

[Chao Xu]

Hi,

I have two questions about this patch series. Any help is appreciated.
1. in the cover letter(https://lkml.org/lkml/2013/7/10/355), it states
"the series implements suspend/resume for the OMAP EHCI host
controller during runtime idle". I don't understand when is the EHCI
host controller "runtime idle"? Does "runtime idle" refers to when all
attached USB devices are suspended? or does it refer to whenever there
is no tx/rx ongoing in the EHCI host controller?

2. I think the purpose of the patch is to allow the USB power domain
(namely, L3INIT power domain) to enter low power state. So assuming
the power domain is now in RETENTION state, will the EHCI host be able
to detect remote wakeup in this case? i.e. will the ULPI DATA0, DATA1
and DATA3 reflect the Linestate and Interrupt when the L3INIT power
domain is in RETENTION? Put it in another way, when the power domain
in is a low power state defined in OMAP spec, is the USB host and PHY
in  "low power mode" defined in USB spec?

Thank you!




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

[PATCH 2/2] usb: ehci-platform: Return immediately from suspend if ehci_suspend fails

[Vivek Gautam]

Patch 'b8efdaf USB: EHCI: add check for wakeup/suspend race'
adds a check for possible race between suspend and wakeup interrupt,
and thereby it returns -EBUSY as error code if there's a wakeup
interrupt.
So the platform host controller should not proceed further with
its suspend callback, rather should return immediately to avoid
powering down the essential things, like phy.

Signed-off-by: Vivek Gautam 
Cc: Alan Stern 
Cc: Hauke Mehrtens 
Cc: Hans de Goede 
---

Based on 'usb-next' branch of Greg's usb tree.

 drivers/usb/host/ehci-platform.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/host/ehci-platform.c b/drivers/usb/host/ehci-platform.c
index b3a0e11..60d3d1a 100644
--- a/drivers/usb/host/ehci-platform.c
+++ b/drivers/usb/host/ehci-platform.c
@@ -303,11 +303,13 @@ static int ehci_platform_suspend(struct device *dev)
int ret;
 
ret = ehci_suspend(hcd, do_wakeup);
+   if (ret)
+   return ret;
 
if (pdata->power_suspend)
pdata->power_suspend(pdev);
 
-   return ret;
+   return 0;
 }
 
 static int ehci_platform_resume(struct device *dev)
-- 
1.7.10.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/

[PATCH 1/2] usb: ehci-exynos: Return immediately from suspend if ehci_suspend fails

[Vivek Gautam]

Patch 'b8efdaf USB: EHCI: add check for wakeup/suspend race'
adds a check for possible race between suspend and wakeup interrupt,
and thereby it returns -EBUSY as error code if there's a wakeup
interrupt.
So the platform host controller should not proceed further with
its suspend callback, rather should return immediately to avoid
powering down the essential things, like phy.

Signed-off-by: Vivek Gautam 
Cc: Alan Stern 
Cc: Jingoo Han 
---

Based on 'usb-next' branch of Greg's usb tree.

 drivers/usb/host/ehci-exynos.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
index d1d8c47..a4550eb 100644
--- a/drivers/usb/host/ehci-exynos.c
+++ b/drivers/usb/host/ehci-exynos.c
@@ -212,6 +212,8 @@ static int exynos_ehci_suspend(struct device *dev)
int rc;
 
rc = ehci_suspend(hcd, do_wakeup);
+   if (rc)
+   return rc;
 
if (exynos_ehci->otg)
exynos_ehci->otg->set_host(exynos_ehci->otg, &hcd->self);
@@ -221,7 +223,7 @@ static int exynos_ehci_suspend(struct device *dev)
 
clk_disable_unprepare(exynos_ehci->clk);
 
-   return rc;
+   return 0;
 }
 
 static int exynos_ehci_resume(struct device *dev)
-- 
1.7.10.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/

[PATCH] sched/cpupri: fix cpupri_find() for high priority tasks

[Mike Galbraith]

Hi Steven,

Seems c92211d9b7727 introduced a buglet.

--snip--

Bail on task_pri >= MAX_RT_PRIO excludes userspace prio 98 and 99 tasks,
which map to 100 and 101 respectively.

A user reported that given two SCHED_RR tasks, one hog, one light, the light
task may be stacked on top of the hog iff prio >= 98, latency hit follows.

Signed-off-by: Mike Galbraith 
Cc: 
Fixes: c92211d9b7727 sched/cpupri: Remove the vec->lock
---
 kernel/sched/cpupri.c |3 ---
 1 file changed, 3 deletions(-)

--- a/kernel/sched/cpupri.c
+++ b/kernel/sched/cpupri.c
@@ -70,9 +70,6 @@ int cpupri_find(struct cpupri *cp, struc
int idx = 0;
int task_pri = convert_prio(p->prio);
 
-   if (task_pri >= MAX_RT_PRIO)
-   return 0;
-
for (idx = 0; idx < task_pri; idx++) {
struct cpupri_vec *vec  = &cp->pri_to_cpu[idx];
int skip = 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: [Intel-gfx] i915 DVI resolution regression (3.13.7+)

[Dave Airlie]

On Tue, Apr 8, 2014 at 5:32 PM, Daniel J Blueman  wrote:
> On 8 April 2014 15:14, Jani Nikula  wrote:
>> On Tue, 08 Apr 2014, Daniel J Blueman  wrote:
>>> Ville et al,
>>>
>>> It looks like commit e3ea8fa6beaf55fee64bf816f3b8a80ad733b2c2 (or
>>> another commit in 3.13.7) broke modes which require DVI-D dual-link,
>>> eg 2560x1440 with my panel.
>>>
>>> I don't see these modelines in 3.13.7 or later (eg 3.14):
>>>
>>> [ 5.582] (II) intel(0): Modeline "2560x1440"x60.0  312.25  2560
>>> 2752 3024 3488  1440 1443 1448 1493 -hsync +vsync (89.5 kHz eP)
>>> [ 5.582] (II) intel(0): Modeline "2560x1440"x60.0  312.25  2560
>>> 2752 3024 3488  1440 1443 1448 1493 -hsync +vsync (89.5 kHz eP)
>>> [ 5.582] (II) intel(0): Modeline "1920x1200"x59.9  193.25  1920
>>> 2056 2256 2592  1200 1203 1209 1245 -hsync +vsync (74.6 kHz e)
>>>
>>> My monitor is a Dell U2713HM; mobo uses an H87 chipset with i5-4670.
>>
>> By allowing those modes we regressed setups which were not capable of
>> displaying them. So you've got an HDMI->DVI converter?
>>
>> https://bugzilla.kernel.org/show_bug.cgi?id=72961
>
> I am using a dual-link DVI-D to DVI-D cable to this monitor, since I
> previously couldn't get 2560x1440 via HDMI.

Intel hw has dual-link DVI-D? I'm not sure I've ever seen that, is
this SDVO device or plain DVI-D?

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/

[PATCH 3/3] w1: optional bundling of netlink kernel replies

[David Fries]

Applications can submit a set of commands in one packet to the kernel,
and in some cases it is required such as reading the temperature
sensor results.  This adds an option W1_CN_BUNDLE to the flags of
cn_msg to request the kernel to reply in one packet for efficiency.

The cn_msg flags now check for unknown flag values and return an error
if one is seen.  See "Proper handling of unknown flags in system
calls" http://lwn.net/Articles/588444/

This corrects the ack values returned as per the protocol standard,
namely the original ack for status messages and seq + 1 for all others
such as the data returned from a read.

Some of the common variable names have been standardized as follows.
struct cn_msg *cn
struct w1_netlink_msg *msg
struct w1_netlink_cmd *cmd
struct w1_master *dev

When an argument and a function scope variable would collide, add req_
to the argument.

Signed-off-by: David Fries 
Acked-by: Evgeniy Polyakov 
---
 Documentation/connector/connector.txt |2 +-
 Documentation/w1/w1.generic   |2 +-
 Documentation/w1/w1.netlink   |   13 +-
 drivers/w1/w1.h   |8 -
 drivers/w1/w1_netlink.c   |  649 -
 drivers/w1/w1_netlink.h   |   36 ++
 6 files changed, 447 insertions(+), 263 deletions(-)

diff --git a/Documentation/connector/connector.txt 
b/Documentation/connector/connector.txt
index e56abdb..f6215f9 100644
--- a/Documentation/connector/connector.txt
+++ b/Documentation/connector/connector.txt
@@ -118,7 +118,7 @@ acknowledge number MUST be the same + 1.
 If we receive a message and its sequence number is not equal to one we
 are expecting, then it is a new message.  If we receive a message and
 its sequence number is the same as one we are expecting, but its
-acknowledge is not equal to the acknowledge number in the original
+acknowledge is not equal to the sequence number in the original
 message + 1, then it is a new message.
 
 Obviously, the protocol header contains the above id.
diff --git a/Documentation/w1/w1.generic b/Documentation/w1/w1.generic
index a31c5a2..b2033c6 100644
--- a/Documentation/w1/w1.generic
+++ b/Documentation/w1/w1.generic
@@ -82,7 +82,7 @@ driver - (standard) symlink to the w1 driver
 w1_master_add  - Manually register a slave device
 w1_master_attempts - the number of times a search was attempted
 w1_master_max_slave_count
-   - the maximum slaves that may be attached to a master
+   - maximum number of slaves to search for at a time
 w1_master_name - the name of the device (w1_bus_masterX)
 w1_master_pullup   - 5V strong pullup 0 enabled, 1 disabled
 w1_master_remove   - Manually remove a slave device
diff --git a/Documentation/w1/w1.netlink b/Documentation/w1/w1.netlink
index 927a52c..ef27271 100644
--- a/Documentation/w1/w1.netlink
+++ b/Documentation/w1/w1.netlink
@@ -30,7 +30,7 @@ Protocol.
W1_SLAVE_CMD
userspace command for slave device
(read/write/touch)
-   __u8 res- reserved
+   __u8 status - error indication from kernel
__u16 len   - size of data attached to this header data
union {
__u8 id[8];  - slave unique device id
@@ -44,10 +44,14 @@ Protocol.
__u8 cmd- command opcode.
W1_CMD_READ - read command
W1_CMD_WRITE- write command
-   W1_CMD_TOUCH- touch command
-   (write and sample data back to userspace)
W1_CMD_SEARCH   - search command
W1_CMD_ALARM_SEARCH - alarm search command
+   W1_CMD_TOUCH- touch command
+   (write and sample data back to userspace)
+   W1_CMD_RESET- send bus reset
+   W1_CMD_SLAVE_ADD- add slave to kernel list
+   W1_CMD_SLAVE_REMOVE - remove slave from kernel list
+   W1_CMD_LIST_SLAVES  - get slaves list from kernel
__u8 res- reserved
__u16 len   - length of data for this command
For read command data must be allocated like for write command
@@ -87,8 +91,7 @@ format:
id0 ... idN
 
Each message is at most 4k in size, so if number of master devices
-   exceeds this, it will be split into several messages,
-   cn.seq will be increased for each one.
+   exceeds this, it will be split into several messages.
 
 W1 search and alarm search commands.
 request:
diff --git a/drivers/w1/w1.h b/drivers/w1/w1.h
index 734dab7..56a49ba 100644
--- a/drivers/w1/w1.h
+++ b/drivers/w1/w1.h
@@ -203,7 +203,6 @@ enum w1_master_flags {
  * @search_id: allows continuing a search
  * @refcnt:reference count
  * @priv:  private

[PATCH 1/3] w1: fix netlink refcnt leak on error path

[David Fries]

If the message type is W1_MASTER_CMD or W1_SLAVE_CMD, then a reference
is taken when searching for the slave or master device.  If there
isn't any following data m->len (mlen is a copy) is 0 and packing up
the message for later execution is skipped leaving nothing to
decrement the reference counts.

Way back when, m->len was checked before the search that increments the
reference count, but W1_LIST_MASTERS has no additional data, the check
was moved in 9be62e0b2fadaf5ff causing this bug.

This change reorders to put the check before the reference count is
incremented avoiding the problem.

Signed-off-by: David Fries 
Acked-by: Evgeniy Polyakov 
---
 drivers/w1/w1_netlink.c |   44 ++--
 1 file changed, 26 insertions(+), 18 deletions(-)

diff --git a/drivers/w1/w1_netlink.c b/drivers/w1/w1_netlink.c
index 5234964..a02704a 100644
--- a/drivers/w1/w1_netlink.c
+++ b/drivers/w1/w1_netlink.c
@@ -300,12 +300,6 @@ static int w1_process_command_root(struct cn_msg *msg,
struct w1_netlink_msg *w;
u32 *id;
 
-   if (mcmd->type != W1_LIST_MASTERS) {
-   printk(KERN_NOTICE "%s: msg: %x.%x, wrong type: %u, len: %u.\n",
-   __func__, msg->id.idx, msg->id.val, mcmd->type, 
mcmd->len);
-   return -EPROTO;
-   }
-
cn = kmalloc(PAGE_SIZE, GFP_KERNEL);
if (!cn)
return -ENOMEM;
@@ -441,6 +435,9 @@ static void w1_process_cb(struct w1_master *dev, struct 
w1_async_cmd *async_cmd)
w1_netlink_send_error(&node->block->msg, node->m, cmd,
node->block->portid, err);
 
+   /* ref taken in w1_search_slave or w1_search_master_id when building
+* the block
+*/
if (sl)
w1_unref_slave(sl);
else
@@ -503,30 +500,42 @@ static void w1_cn_callback(struct cn_msg *msg, struct 
netlink_skb_parms *nsp)
 
msg_len = msg->len;
while (msg_len && !err) {
-   struct w1_reg_num id;
-   u16 mlen = m->len;
 
dev = NULL;
sl = NULL;
 
-   memcpy(&id, m->id.id, sizeof(id));
-#if 0
-   printk("%s: %02x.%012llx.%02x: type=%02x, len=%u.\n",
-   __func__, id.family, (unsigned long long)id.id, 
id.crc, m->type, m->len);
-#endif
if (m->len + sizeof(struct w1_netlink_msg) > msg_len) {
err = -E2BIG;
break;
}
 
+   /* execute on this thread, no need to process later */
+   if (m->type == W1_LIST_MASTERS) {
+   err = w1_process_command_root(msg, m, nsp->portid);
+   goto out_cont;
+   }
+
+   /* All following message types require additional data,
+* check here before references are taken.
+*/
+   if (!m->len) {
+   err = -EPROTO;
+   goto out_cont;
+   }
+
+   /* both search calls take reference counts */
if (m->type == W1_MASTER_CMD) {
dev = w1_search_master_id(m->id.mst.id);
} else if (m->type == W1_SLAVE_CMD) {
-   sl = w1_search_slave(&id);
+   sl = w1_search_slave((struct w1_reg_num *)m->id.id);
if (sl)
dev = sl->master;
} else {
-   err = w1_process_command_root(msg, m, nsp->portid);
+   printk(KERN_NOTICE
+   "%s: msg: %x.%x, wrong type: %u, len: %u.\n",
+   __func__, msg->id.idx, msg->id.val,
+   m->type, m->len);
+   err = -EPROTO;
goto out_cont;
}
 
@@ -536,8 +545,6 @@ static void w1_cn_callback(struct cn_msg *msg, struct 
netlink_skb_parms *nsp)
}
 
err = 0;
-   if (!mlen)
-   goto out_cont;
 
atomic_inc(&block->refcnt);
node->async.cb = w1_process_cb;
@@ -557,7 +564,8 @@ out_cont:
if (err)
w1_netlink_send_error(msg, m, NULL, nsp->portid, err);
msg_len -= sizeof(struct w1_netlink_msg) + m->len;
-   m = (struct w1_netlink_msg *)(((u8 *)m) + sizeof(struct 
w1_netlink_msg) + m->len);
+   m = (struct w1_netlink_msg *)(((u8 *)m) +
+   sizeof(struct w1_netlink_msg) + m->len);
 
/*
 * Let's allow requests for nonexisting devices.
-- 
1.7.10.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/

[PATCH 2/3] connector: allow multiple messages to be sent in one packet

[David Fries]

This increases the amount of bundling to reduce the number of packets
sent.  For the one wire use there can be multiple struct
w1_netlink_cmd in a struct w1_netlink_msg and multiple of those in
struct cn_msg, and with this change multiple of those in a struct
nlmsghdr, and at each level the len identifies there being multiple of
the next.

Signed-off-by: David Fries 
Acked-by: Evgeniy Polyakov 
---
 Documentation/connector/connector.txt |   13 ++---
 drivers/connector/connector.c |   17 +++--
 include/linux/connector.h |1 +
 3 files changed, 26 insertions(+), 5 deletions(-)

diff --git a/Documentation/connector/connector.txt 
b/Documentation/connector/connector.txt
index e5c5f5e..e56abdb 100644
--- a/Documentation/connector/connector.txt
+++ b/Documentation/connector/connector.txt
@@ -24,7 +24,8 @@ netlink based networking for inter-process communication in a 
significantly
 easier way:
 
 int cn_add_callback(struct cb_id *id, char *name, void (*callback) (struct 
cn_msg *, struct netlink_skb_parms *));
-void cn_netlink_send(struct cn_msg *msg, u32 __group, int gfp_mask);
+void cn_netlink_send_multi(struct cn_msg *msg, u16 len, u32 portid, u32 
__group, int gfp_mask);
+void cn_netlink_send(struct cn_msg *msg, u32 portid, u32 __group, int 
gfp_mask);
 
 struct cb_id
 {
@@ -71,15 +72,21 @@ void cn_del_callback(struct cb_id *id);
  struct cb_id *id  - unique connector's user identifier.
 
 
-int cn_netlink_send(struct cn_msg *msg, u32 __groups, int gfp_mask);
+int cn_netlink_send_multi(struct cn_msg *msg, u16 len, u32 portid, u32 
__groups, int gfp_mask);
+int cn_netlink_send(struct cn_msg *msg, u32 portid, u32 __groups, int 
gfp_mask);
 
  Sends message to the specified groups.  It can be safely called from
  softirq context, but may silently fail under strong memory pressure.
  If there are no listeners for given group -ESRCH can be returned.
 
  struct cn_msg *   - message header(with attached data).
+ u16 len   - for *_multi multiple cn_msg messages can be 
sent
+ u32 port  - destination port.
+ If non-zero the message will be sent to the
+ given port, which should be set to the
+ original sender.
  u32 __group   - destination group.
- If __group is zero, then appropriate group 
will
+ If port and __group is zero, then appropriate 
group will
  be searched through all registered connector 
users,
  and message will be delivered to the group 
which was
  created for user with the same ID as in msg.
diff --git a/drivers/connector/connector.c b/drivers/connector/connector.c
index b14f1d3..f612d68 100644
--- a/drivers/connector/connector.c
+++ b/drivers/connector/connector.c
@@ -43,6 +43,8 @@ static struct cn_dev cdev;
 static int cn_already_initialized;
 
 /*
+ * Sends mult (multiple) cn_msg at a time.
+ *
  * msg->seq and msg->ack are used to determine message genealogy.
  * When someone sends message it puts there locally unique sequence
  * and random acknowledge numbers.  Sequence number may be copied into
@@ -62,10 +64,13 @@ static int cn_already_initialized;
  * the acknowledgement number in the original message + 1, then it is
  * a new message.
  *
+ * If msg->len != len, then additional cn_msg messages are expected following
+ * the first msg.
+ *
  * The message is sent to, the portid if given, the group if given, both if
  * both, or if both are zero then the group is looked up and sent there.
  */
-int cn_netlink_send(struct cn_msg *msg, u32 portid, u32 __group,
+int cn_netlink_send_mult(struct cn_msg *msg, u16 len, u32 portid, u32 __group,
gfp_t gfp_mask)
 {
struct cn_callback_entry *__cbq;
@@ -98,7 +103,7 @@ int cn_netlink_send(struct cn_msg *msg, u32 portid, u32 
__group,
if (!portid && !netlink_has_listeners(dev->nls, group))
return -ESRCH;
 
-   size = sizeof(*msg) + msg->len;
+   size = sizeof(*msg) + len;
 
skb = nlmsg_new(size, gfp_mask);
if (!skb)
@@ -121,6 +126,14 @@ int cn_netlink_send(struct cn_msg *msg, u32 portid, u32 
__group,
 gfp_mask);
return netlink_unicast(dev->nls, skb, portid, !(gfp_mask&__GFP_WAIT));
 }
+EXPORT_SYMBOL_GPL(cn_netlink_send_mult);
+
+/* same as cn_netlink_send_mult except msg->len is used for len */
+int cn_netlink_send(struct cn_msg *msg, u32 portid, u32 __group,
+   gfp_t gfp_mask)
+{
+   return cn_netlink_send_mult(msg, msg->len, portid, __group, gfp_mask);
+}
 EXPORT_SYMBOL_GPL(cn_netlink_send);
 
 /*
diff --git a/include/linux/connector.h b/include/linux/connector.h
index be9c4747..f8fe863 100644
--- a/include/linux/connector.h
+++ b/include/linux/connector.h
@@ -7

[PATCH 0/3] w1: fixes and bundling replies

[David Fries]

A program can bundle a sequence of commands in one netlink packet but
the kernel was having to reply in many different packets, this adds a
flag W1_CN_BUNDLE in the cn_msg.flags to allow the kernel to bundle
the replies in to one message.  This is opt in to avoid breaking
programs that aren't expecting additional messages.

Netlink connector now has a new call cn_netlink_send_multi, which
allow sending multiple cn_msg structures in a nlmsghdr structure.

I tested with my client program that will bundle up 14 temperature
sensor conversions, then after a delay, bundle up another set of
commands to read all 14 with the bundle bit set.  I also tested with a
two year old version of the software that sends requests two one slave
at a time (bundling only the write/read to get the data out), and
doesn't have code to read the bundling the this patch adds.  Both
operate correctly running at the same time.

 Documentation/connector/connector.txt |   15 +-
 Documentation/w1/w1.generic   |2 +-
 Documentation/w1/w1.netlink   |   13 +-
 drivers/connector/connector.c |   17 +-
 drivers/w1/w1.h   |8 -
 drivers/w1/w1_netlink.c   |  673 -
 drivers/w1/w1_netlink.h   |   36 ++
 include/linux/connector.h |1 +
 8 files changed, 489 insertions(+), 276 deletions(-)

[PATCH 1/3] w1: fix netlink refcnt leak on error path
[PATCH 2/3] connector: allow multiple messages to be sent in one
[PATCH 3/3] w1: optional bundling of netlink kernel replies
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC] bpf tracing filters API proposal. Was: [RFC PATCH 00/28] ktap: A lightweight dynamic tracing tool for Linux

[Alexei Starovoitov]

On Tue, Apr 8, 2014 at 2:08 AM, Peter Zijlstra  wrote:
> On Tue, Apr 08, 2014 at 04:40:36PM +0900, Masami Hiramatsu wrote:
>> (2014/04/07 22:55), Peter Zijlstra wrote:
>> > On Wed, Apr 02, 2014 at 09:42:03AM +0200, Ingo Molnar wrote:
>> >> I'd suggest using C syntax instead initially, because that's what the
>> >> kernel is using.
>> >>
>> >> The overwhelming majority of people probing the kernel are
>> >> programmers, so there's no point in inventing new syntax, we should
>> >> reuse existing syntax!
>> >
>> > Yes please, keep it C, I forever forget all other syntaxes. While I have
>> > in the past known other languages, I never use them frequently enough to
>> > remember them. And there's nothing more frustrating than having to fight
>> > a tool/language when you just want to get work done.
>>
>> Why wouldn't you write a kernel module in C directly? :)
>> It seems that all what you need is not a tracing language nor a bytecode
>> engine, but an well organized tracing APIs(library?) for writing a kernel
>> module for tracing...
>
> Most my kernels are CONFIG_MODULE=n :-) Also, I never can remember how
> to do modules.
>
> That said; what I currently do it hack the kernel with debug bits and
> pieces and run that, which is effectively the same. Its just that its
> impossible to save/share these hacks in any sane fashion.

seconded.
Fo debugging I have similar setup:
few ko template dirs that I copy into new dir, then tweak, insmod, dmesg.
Process is tedious, since one have to think through every line
of the code before doing insmod.
Similar slow process to explore unfamiliar kernel territory:
add some conditional printks and stackdumps,
think through, recompile, reboot.
What I would like to see is something like:

perf run file.c

where file.c contains my debugging code and looks as close as
possible to normal kernel code:

attach("net:netif_receive_skb")
void my_filter(struct bpf_context *ctx)
{
char devname[4] = "lo";
struct net_device *dev;
struct sk_buff *skb = 0;

skb = (struct sk_buff *)ctx->arg1;
dev = bpf_load_pointer(&skb->dev);
if (bpf_memcmp(dev->name, devname, 2) == 0) {
char fmt[] = "skb %p dev %p \n";
bpf_trace_printk(fmt, sizeof(fmt), (long)skb, (long)dev, 0);
}
}

and I don't need to think hard while writing it, since whatever wrong
memory accesses I do, it shouldn't crash the kernel.

above is a working example, but it needs obvious improvements:
- trace_printk(), memcmp() need to be able to accept 'char *'
  in a normal way
- bpf_load_pointer() can be either a macro or whole bpf program
  can be a no-fault zone, so we can have C like:
  if (strcmp(skb->dev->name, "lo") == 0)

'perf' would run C->bpf compiler and orchestrate attaching
bpf programs to events and printing back results.

Answering Jovi's point about "is supported" vs "will be supported":
it is true.
December patches are obviously obsolete and every building
block will get through its own feedback/rewrite cycles.

For example:
- In december I've been using simplified obj_file format that
llvm was generating and kernel was parsing while loading.
- Last week I mentioned that probably makes sense to
use standard elf. It's actually less code in llvm backend
to output elf then custom obj_file
- today I'm thinking that kernel shouldn't be dealing with
  either elf or custom obj_file at all

kernel API for bpf loading should be simpler.
we already have sk_unattached_filter_create().
we can expose it to userspace and add:
sk_filter_associate_to_event()
Then earlier "one bpf program = one event" misunderstanding
wouldn't have happened.
Userspace can decide what syntax to use to associate
tracing filters to events.
llvm compiler should not care. It just compiles C into elf
with function bodies being ibpf instructions.
Then perf interprets this elf file in userspace and calls
sk_unattached_filter_create() N times and
sk_filter_associate_to_event() M times.
Then waits for user input, tears down things and prints tracebuf.

Similar basic interface I'm thinking to use for bpf tables.
Probably makes sense to drop 'bpf' prefix, since they're just
hash tables. Little to do with bpf.
Have a netlink API from user into kernel:
- create hash table (num_of_entries, key_size, value_size, id)
- dump table via netlink
- add/remove key/value pair
Some kernel module may use it to transfer the data between
kernel and userspace.
This can be a generic kernel/user data sharing facility.

Also let bpf programs do 'table_lookup/update', so that
filters can store interesting data.

To summarize,
proposed new user->kernel API via netlink or debugfs is:
- sk_unattached_filter_create(bpf prog)
- sk_filter_associate_to_event(bpf_prog_id, event)
- hash table create/dump/add/remove
That's it.

event creation, tracebuf facilities are reused as is.

ibpf interpreter, ibpf jits, ibpf verifier are reused across
socket filtering, seccomp, tracing filters.

perf would call llvm compile

Re: [PATCH 4/6] perf, sort: Add physid sorting based on mmap2 data

[Don Zickus]

On Mon, Mar 24, 2014 at 03:34:34PM -0400, Don Zickus wrote:
> In order for the c2c tool to work correctly, it needs to properly
> sort all the records on uniquely identifiable data addresses.  These
> unique addresses are converted from virtual addresses provided by the
> hardware into a kernel address using an mmap2 record as the decoder.
> 
> Once a unique address is converted, we can sort on them based on
> various rules.  Then it becomes clear which address are overlapping
> with each other across mmap regions or pid spaces.

I am finishing up another way to sort this data that might make more sense
then the approach in this patch.  Hopefully tomorrow I can do that.

Cheers,
Don
> 
> This patch just creates the rules and inserts the records into a
> sort entry for safe keeping until later patches process them.
> 
> The general sorting rule is:
> 
> o group cpumodes together
> o if (nonzero major/minor number - ie mmap'd areas)
>   o sort on major, minor, inode, inode generation numbers
> o else if cpumode is not kernel
>   o sort on pid
> o sort on data addresses
> 
> I also hacked in the concept of 'color'.  The purpose of that bit is to
> provides hints later when processing these records that indicate a new unique
> address has been encountered.  Because later processing only checks the data
> addresses, there can be a theoretical scenario that similar sequential data
> addresses (when walking the rbtree) could be misinterpreted as overlapping
> when in fact they are not.
> 
> Sample output: (perf report --stdio --physid-mode)
> 
> 18.93%  [k] 0xc900139c40b0  [k] igb_update_stats kworker/0:1:  
> 257   257  0  0   0  0
>  7.63%  [k] 0x88082e6cf0a8  [k] watchdog_timer_fnswapper:
> 0 0  0  0   0  0
>  1.86%  [k] 0x88042ef94700  [k] _raw_spin_lock   swapper:
> 0 0  0  0   0  0
>  1.77%  [k] 0x8804278afa50  [k] __switch_to  swapper:
> 0 0  0  0   0  0
> 
> V3: split out the sorting into unique entries.  This makes it look
>   far less ugly
> create a new 'physid mode' to group all the sorting rules together
>   (mimics the mem-mode)
> 
> Signed-off-by: Don Zickus 
> ---
>  tools/perf/builtin-report.c |  20 ++-
>  tools/perf/util/hist.c  |  27 +++-
>  tools/perf/util/hist.h  |   8 ++
>  tools/perf/util/sort.c  | 294 
> 
>  tools/perf/util/sort.h  |  13 ++
>  5 files changed, 358 insertions(+), 4 deletions(-)
> 
> diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
> index c87412b..093f5ad 100644
> --- a/tools/perf/builtin-report.c
> +++ b/tools/perf/builtin-report.c
> @@ -49,6 +49,7 @@ struct report {
>   boolshow_threads;
>   boolinverted_callchain;
>   boolmem_mode;
> + boolphysid_mode;
>   boolheader;
>   boolheader_only;
>   int max_stack;
> @@ -241,7 +242,7 @@ static int process_sample_event(struct perf_tool *tool,
>   ret = report__add_branch_hist_entry(rep, &al, sample, evsel);
>   if (ret < 0)
>   pr_debug("problem adding lbr entry, skipping event\n");
> - } else if (rep->mem_mode == 1) {
> + } else if ((rep->mem_mode == 1) || (rep->physid_mode)) {
>   ret = report__add_mem_hist_entry(rep, &al, sample, evsel);
>   if (ret < 0)
>   pr_debug("problem adding mem entry, skipping event\n");
> @@ -746,6 +747,7 @@ int cmd_report(int argc, const char **argv, const char 
> *prefix __maybe_unused)
>   OPT_BOOLEAN(0, "demangle", &symbol_conf.demangle,
>   "Disable symbol demangling"),
>   OPT_BOOLEAN(0, "mem-mode", &report.mem_mode, "mem access profile"),
> + OPT_BOOLEAN(0, "physid-mode", &report.physid_mode, "physid access 
> profile"),
>   OPT_CALLBACK(0, "percent-limit", &report, "percent",
>"Don't show entries under that percent", 
> parse_percent_limit),
>   OPT_END()
> @@ -817,6 +819,22 @@ repeat:
>   sort_order = 
> "local_weight,mem,sym,dso,symbol_daddr,dso_daddr,snoop,tlb,locked";
>   }
>  
> + if (report.physid_mode) {
> + if ((sort__mode == SORT_MODE__BRANCH) ||
> + (sort__mode == SORT_MODE__MEMORY)) {
> + pr_err("branch or memory and physid mode 
> incompatible\n");
> + goto error;
> + }
> + sort__mode = SORT_MODE__PHYSID;
> +
> + /*
> +  * if no sort_order is provided, then specify
> +  * branch-mode specific order
> +  */
> + if (sort_order == default_sort_order)
> + sort_order = 
> "daddr,iaddr,pid,tid,major,minor,inode,inode_gen";
> + }
> +
>   if (se

Re: [PATCH 3/3] ie31200_edac: Add driver

[Jason Baron]

On 04/08/2014 06:34 PM, Luck, Tony wrote:
>>> Btw, this driver is polling, AFAICT. Doesn't e3-12xx support the CMCI
>>> interrupt which you can feed into this driver directly and thus not need
>>> the polling at all?
>> On the system with the ce and ue events that I'm testing on, I don't see
>> 'MCE' nudge above 0, in /proc/interrupts. So I think that implies that
>> we are not getting any CMCI there?
> CMCI will bump up the "THR" (Threshold) entries in /proc/interrupts.

Ok, so on the system with ue and ce events (as reported by driver
and confirmed with a memory scanner), "THR" is 0 across
all cpus, and I see no machine checks in the logs...

>> So if possible maybe we can confirm with Intel whether we expect an MCE
>> for memory errors...
> MCG_CAP bit 10 tells you whether a given processor implements CMCI.
> If that is set - then MCi_CTL2 bit 30 indicates whether a given bank
> supports it (Linux tries to set this bit, if it sticks, then it knows that 
> CMCI
> is supported - Linux also assigns ownership of the bank to the first cpu
> to successfully set it (since a bank may be shared by multiple threads/cores
> on a package).
>
> Consumed uncorrectable errors should generate a machine check. Which
> on the E3-12xx series will be a fatal machine check: MCi_STATUS.PCC=1
>
> -Tony
>

Hmmm...as I said, I'm not getting any machine checks with ue errors. I've
got a fairly old kernel on the system atm, I will try loading a newer kernel,
to see if that makes any difference...

Thanks,

-Jason

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

[GIT PULL] MMC updates for 3.15-rc1

[Chris Ball]

Hi Linus,

Please pull from:

  git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc.git 
tags/mmc-updates-for-3.15-rc1

to receive the MMC merge for 3.15.  These patches have been tested in
linux-next, and there are currently no conflicts.  There's a MAINTAINERS
update to add Ulf Hansson as MMC co-maintainer.  Thanks.
  
The following changes since commit b28a960c42fcd9cfc987441fa6d1c1a471f0f9ed:

  Linux 3.14-rc2 (2014-02-09 18:15:47 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc.git 
tags/mmc-updates-for-3.15-rc1

for you to fetch changes up to c67480173f72e883235dd0ad09d90156c8f87600:

  mmc: sdhci-acpi: Intel SDIO has broken card detect (2014-04-07 21:27:14 -0400)


MMC highlights for 3.15:

Core:
 - CONFIG_MMC_UNSAFE_RESUME=y is now default behavior.
 - DT bindings for SDHCI UHS, eMMC HS200, high-speed DDR, at 1.8/1.2V.
 - Add GPIO descriptor based slot-gpio card detect API.

Drivers:
 - dw_mmc: Refactor SOCFPGA support as a variant inside dw_mmc-pltfm.c.
 - mmci: Support HW busy detection on ux500.
 - omap: Support MMC_ERASE.
 - omap_hsmmc: Support MMC_PM_KEEP_POWER, MMC_PM_WAKE_SDIO_IRQ, (a)cmd23.
 - rtsx: Support pre-req/post-req async.
 - sdhci: Add support for Realtek RTS5250 controllers.
 - sdhci-acpi: Add support for 80860F16, fix 80860F14/SDIO card detect.
 - sdhci-msm: Add new driver for Qualcomm SDHCI chipset support.
 - sdhci-pxav3: Add support for Marvell Armada 380 and 385 SoCs.


Adrian Hunter (7):
  mmc: slot-gpio: Record GPIO descriptors instead of GPIO numbers
  mmc: slot-gpio: Split out CD IRQ request into a separate function
  mmc: slot-gpio: Add GPIO descriptor based CD GPIO API
  mmc: sdhci-acpi: Fix broken card detect for ACPI HID 80860F14
  mmc: sdhci-acpi: Add device id 80860F16
  mmc: sdhci: Allow for irq being shared
  mmc: sdhci-acpi: Intel SDIO has broken card detect

Arend van Spriel (1):
  sdhci: only reprogram retuning timer when flag is set

Balaji T K (14):
  mmc: omap_hsmmc: use devm_regulator API
  mmc: omap_hsmmc: handle vcc and vcc_aux independently
  regulator: add pbias regulator support
  mmc: omap_hsmmc: adapt hsmmc to use pbias regulator
  ARM: dts: add pbias dt node
  ARM: OMAP: enable SYSCON and REGULATOR_PBIAS in omap2plus_defconfig
  mmc: omap_hsmmc: remove pbias workaround
  mmc: omap_hsmmc: fix return error code for of_get_hsmmc_pdata
  mmc: omap_hsmmc: remove redundant reset done
  mmc: omap_hsmmc: save clock rate to use in interrupt context
  mmc: omap_hsmmc: fix request done for sbc error case
  mmc: omap_hsmmc: split dma setup
  mmc: omap_hsmmc: add cmd23 support
  mmc: omap_hsmmc: add autocmd23 support

Chris Ball (1):
  Revert "dts: socfpga: Add support for SD/MMC on the SOCFPGA platform"

Christian Daudt (1):
  mmc: rename ARCH_BCM to ARCH_BCM_MOBILE

Dan Carpenter (1):
  mmc: omap_hsmmc: remove a duplicative test

Daniel Mack (1):
  mmc: omap_hsmmc: support more DT properties

Dinh Nguyen (3):
  mmc: dw_mmc-socfpga: Remove the SOCFPGA specific platform for dw_mmc
  mmc: dw_mmc: Add support for SOCFPGA's platform specific implementation
  dts: socfpga: Add support for SD/MMC on the SOCFPGA platform

Felipe Balbi (1):
  mmc: dw_mmc: fix possible build error

Georgi Djakov (3):
  mmc: sdhci-msm: Qualcomm SDHCI binding documentation
  mmc: sdhci-msm: Initial support for Qualcomm chipsets
  mmc: sdhci-msm: Add platform_execute_tuning implementation

Jaehoon Chung (1):
  mmc: core: Add DT bindings for eMMC HS200 1.8/1.2V

Jarkko Nikula (7):
  mmc: omap: Fix NULL pointer dereference due uninitialized cover_tasklet
  mmc: omap: Convert to devm_kzalloc
  mmc: omap: Remove duplicate host->irq assignment
  mmc: omap: Remove mem_res field from struct mmc_omap_host
  mmc: omap: Convert to devm_ioremap_resource
  mmc: omap: Remove always set use_dma flag from struct mmc_omap_host
  mmc: omap: Add erase capability

Kuninori Morimoto (5):
  mmc: sdhi: tidyup sh_mobile_sdhi_of_match position
  mmc: sdhi: update sh_mobile_sdhi_of_data for r8a7778
  mmc: sdhi: update sh_mobile_sdhi_of_data for r8a7779
  mmc: sdhi: update sh_mobile_sdhi_of_data for r8a7790
  mmc: sdhi: update sh_mobile_sdhi_of_data for r8a7791

Marcin Wojtas (1):
  mmc: sdhci-pxav3: add support for the Armada 38x SDHCI controller

Micky Ching (4):
  mmc: sdhci: add support for realtek rts5250
  mmc: rtsx: fix card poweroff bug
  mmc: rtsx: modify phase searching method for tuning
  mmc: rtsx: add support for pre_req and post_req

Nishanth Menon (2):
  mmc: omap_hsmmc: Add support for quirky omap3 hsmmc controller
  ARM: dts: omap3-ldp: fix mmc configuration

Russell King (6):
  mmc: sdhci-bcm-kona: fix 

[PATCH RT 0/2] rwsem-rt: Make rwsem rt closer to mainline

[Steven Rostedt]

Looking at mainline's down_read() I noticed that reader locks of rwsems
are not made to nest. In fact, they should not. Although, it may seem
fine if a down_read() nests as multiple readers can have the lock,
rwsems are fair locks. That is, if a writer were to block on a rwsem
while readers have the lock, a new reader will also block. If a reader
were to try to take the lock again while a writer was waiting, it
would block, and cause a deadlock as it has the lock its trying
to grab and wont let it go as the writer is waiting.

I also found that the rt_mutex_init() is identical in the two places
it is defined in rtmutex.h.

Steven Rostedt (Red Hat) (2):
  rwsem-rt: Do not allow readers to nest
  rtmutex: Remove duplicate rt_mutex_init()


 include/linux/rtmutex.h  | 12 +++-
 include/linux/rwsem_rt.h |  1 -
 kernel/rt.c  | 37 -
 3 files changed, 11 insertions(+), 39 deletions(-)
--
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 RT 2/2] rtmutex: Remove duplicate rt_mutex_init()

[Steven Rostedt]

From: "Steven Rostedt (Red Hat)" 

The rt_mutex_init() macro is the same whether or not
CONFIG_DEBUG_RT_MUTEX is set. Remove the duplicate.

Signed-off-by: Steven Rostedt 
---
 include/linux/rtmutex.h | 12 +++-
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/include/linux/rtmutex.h b/include/linux/rtmutex.h
index fa18682..f7e79e8 100644
--- a/include/linux/rtmutex.h
+++ b/include/linux/rtmutex.h
@@ -62,25 +62,19 @@ struct hrtimer_sleeper;
 # define __DEBUG_RT_MUTEX_INITIALIZER(mutexname) \
, .name = #mutexname, .file = __FILE__, .line = __LINE__
 
-# define rt_mutex_init(mutex)  \
-   do {\
-   raw_spin_lock_init(&(mutex)->wait_lock);\
-   __rt_mutex_init(mutex, #mutex); \
-   } while (0)
-
  extern void rt_mutex_debug_task_free(struct task_struct *tsk);
 #else
 # define __DEBUG_RT_MUTEX_INITIALIZER(mutexname)
 
+# define rt_mutex_debug_task_free(t)   do { } while (0)
+#endif
+
 # define rt_mutex_init(mutex)  \
do {\
raw_spin_lock_init(&(mutex)->wait_lock);\
__rt_mutex_init(mutex, #mutex); \
} while (0)
 
-# define rt_mutex_debug_task_free(t)   do { } while (0)
-#endif
-
 #define __RT_MUTEX_INITIALIZER_PLAIN(mutexname) \
.wait_lock = __RAW_SPIN_LOCK_UNLOCKED(mutexname.wait_lock) \
, .wait_list = PLIST_HEAD_INIT(mutexname.wait_list) \
-- 
1.8.5.3


--
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 RT 1/2] rwsem-rt: Do not allow readers to nest

[Steven Rostedt]

From: "Steven Rostedt (Red Hat)" 

The readers of mainline rwsems are not allowed to nest, the rwsems in the
PREEMPT_RT kernel should not nest either.

Signed-off-by: Steven Rostedt 
---
 include/linux/rwsem_rt.h |  1 -
 kernel/rt.c  | 37 -
 2 files changed, 8 insertions(+), 30 deletions(-)

diff --git a/include/linux/rwsem_rt.h b/include/linux/rwsem_rt.h
index e94d945..a81151c 100644
--- a/include/linux/rwsem_rt.h
+++ b/include/linux/rwsem_rt.h
@@ -20,7 +20,6 @@
 
 struct rw_semaphore {
struct rt_mutex lock;
-   int read_depth;
 #ifdef CONFIG_DEBUG_LOCK_ALLOC
struct lockdep_map  dep_map;
 #endif
diff --git a/kernel/rt.c b/kernel/rt.c
index 5d17727..bb72347 100644
--- a/kernel/rt.c
+++ b/kernel/rt.c
@@ -316,10 +316,8 @@ EXPORT_SYMBOL(rt_up_write);
 
 void  rt_up_read(struct rw_semaphore *rwsem)
 {
-   if (--rwsem->read_depth == 0) {
-   rwsem_release(&rwsem->dep_map, 1, _RET_IP_);
-   rt_mutex_unlock(&rwsem->lock);
-   }
+   rwsem_release(&rwsem->dep_map, 1, _RET_IP_);
+   rt_mutex_unlock(&rwsem->lock);
 }
 EXPORT_SYMBOL(rt_up_read);
 
@@ -330,7 +328,6 @@ EXPORT_SYMBOL(rt_up_read);
 void  rt_downgrade_write(struct rw_semaphore *rwsem)
 {
BUG_ON(rt_mutex_owner(&rwsem->lock) != current);
-   rwsem->read_depth = 1;
 }
 EXPORT_SYMBOL(rt_downgrade_write);
 
@@ -367,37 +364,20 @@ void rt_down_write_nested_lock(struct rw_semaphore *rwsem,
 
 int  rt_down_read_trylock(struct rw_semaphore *rwsem)
 {
-   struct rt_mutex *lock = &rwsem->lock;
-   int ret = 1;
-
-   /*
-* recursive read locks succeed when current owns the rwsem,
-* but not when read_depth == 0 which means that the rwsem is
-* write locked.
-*/
-   if (rt_mutex_owner(lock) != current) {
-   ret = rt_mutex_trylock(&rwsem->lock);
-   if (ret)
-   rwsem_acquire(&rwsem->dep_map, 0, 1, _RET_IP_);
-   } else if (!rwsem->read_depth) {
-   ret = 0;
-   }
+   int ret;
 
+   ret = rt_mutex_trylock(&rwsem->lock);
if (ret)
-   rwsem->read_depth++;
+   rwsem_acquire(&rwsem->dep_map, 0, 1, _RET_IP_);
+
return ret;
 }
 EXPORT_SYMBOL(rt_down_read_trylock);
 
 static void __rt_down_read(struct rw_semaphore *rwsem, int subclass)
 {
-   struct rt_mutex *lock = &rwsem->lock;
-
-   if (rt_mutex_owner(lock) != current) {
-   rwsem_acquire(&rwsem->dep_map, subclass, 0, _RET_IP_);
-   rt_mutex_lock(&rwsem->lock);
-   }
-   rwsem->read_depth++;
+   rwsem_acquire(&rwsem->dep_map, subclass, 0, _RET_IP_);
+   rt_mutex_lock(&rwsem->lock);
 }
 
 void  rt_down_read(struct rw_semaphore *rwsem)
@@ -422,7 +402,6 @@ void  __rt_rwsem_init(struct rw_semaphore *rwsem, const 
char *name,
debug_check_no_locks_freed((void *)rwsem, sizeof(*rwsem));
lockdep_init_map(&rwsem->dep_map, name, key, 0);
 #endif
-   rwsem->read_depth = 0;
rwsem->lock.save_state = 0;
 }
 EXPORT_SYMBOL(__rt_rwsem_init);
-- 
1.8.5.3


--
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: driver skip pci_set_master, fix it? No.

[Benjamin Herrenschmidt]

On Tue, 2014-04-08 at 17:18 -0400, Mark Lord wrote:
> > I assume you're talking about the one added by cf3e1feba7f9 ("PCI:
> > Workaround missing pci_set_master in pci drivers"), but as far as I
> > can tell, it only calls pci_set_master() for *bridge* devices.  What
> > am I missing?  Is pci_set_master() being called for your endpoint?
> > What path is that?
> 
> Yes, it is being called during execution of the _probe() function in my 
> driver,
> as evidenced by the annoying (and wrong) message it produces.
> 
> Next time I've got the hardware at hand, I'll put a "dump_stack()" into there
> to see the exact calling path.

Note that one of the reason we want to do it early on bridges is that without 
it,
we may also not get the PCIe error messages.

Cheers,
Ben.


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

Re: [Intel-gfx] i915 DVI resolution regression (3.13.7+)

[Daniel J Blueman]

Ville et al,

On 8 April 2014 16:02, Daniel Vetter  wrote:
> On Tue, Apr 8, 2014 at 9:32 AM, Daniel J Blueman  wrote:
>> I am using a dual-link DVI-D to DVI-D cable to this monitor, since I
>> previously couldn't get 2560x1440 via HDMI.
>>
>> If it isn't this commit, then it may be another commit in 3.13.7,
>> albeit it feels less likely.
>
> Before we go on a wild goose chase, can you please confirm your
> suspicion with a revert?

I built stock 3.13.7 to reproduce the issue (Ubuntu mainline config);
I reverted e3ea8fa6beaf55fee64bf816f3b8a80ad733b2c2 and rebuilt, and
don't see the issue. It's probably an idea if you have a panel that
requires dual-link DVI on the automated test matrix if not already.

Anyway, glad to have helped.

Thanks,
  Daniel
-- 
Daniel J Blueman
--
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/

linux-next: manual merge of the userns tree with Linus' tree

[Stephen Rothwell]

Hi Eric,

Today's linux-next merge of the userns tree got a conflict in
fs/namespace.c between commits  from Linus' tree and commits from the
userns tree.

I fixed it up (I used the conflict resolution that your sent to Linus -
see below) and can carry the fix as necessary (no action is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc fs/namespace.c
index 2ffc5a2905d4,52f4174e294c..
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@@ -665,13 -632,47 +666,47 @@@ struct vfsmount *lookup_mnt(struct pat
return m;
  }
  
- static struct mountpoint *new_mountpoint(struct dentry *dentry)
+ /*
+  * __is_local_mountpoint - Test to see if dentry is a mountpoint in the
+  * current mount namespace.
+  *
+  * The common case is dentries are not mountpoints at all and that
+  * test is handled inline.  For the slow case when we are actually
+  * dealing with a mountpoint of some kind, walk through all of the
+  * mounts in the current mount namespace and test to see if the dentry
+  * is a mountpoint.
+  *
+  * The mount_hashtable is not usable in the context because we
+  * need to identify all mounts that may be in the current mount
+  * namespace not just a mount that happens to have some specified
+  * parent mount.
+  */
+ bool __is_local_mountpoint(struct dentry *dentry)
+ {
+   struct mnt_namespace *ns = current->nsproxy->mnt_ns;
+   struct mount *mnt;
+   bool is_covered = false;
+ 
+   if (!d_mountpoint(dentry))
+   goto out;
+ 
+   down_read(&namespace_sem);
+   list_for_each_entry(mnt, &ns->list, mnt_list) {
+   is_covered = (mnt->mnt_mountpoint == dentry);
+   if (is_covered)
+   break;
+   }
+   up_read(&namespace_sem);
+ out:
+   return is_covered;
+ }
+ 
+ static struct mountpoint *lookup_mountpoint(struct dentry *dentry)
  {
 -  struct list_head *chain = mountpoint_hashtable + hash(NULL, dentry);
 +  struct hlist_head *chain = mp_hash(dentry);
struct mountpoint *mp;
-   int ret;
  
 -  list_for_each_entry(mp, chain, m_hash) {
 +  hlist_for_each_entry(mp, chain, m_hash) {
if (mp->m_dentry == dentry) {
/* might be worth a WARN_ON() */
if (d_unlinked(dentry))
@@@ -680,6 -681,14 +715,14 @@@
return mp;
}
}
+   return NULL;
+ }
+ 
+ static struct mountpoint *new_mountpoint(struct dentry *dentry)
+ {
 -  struct list_head *chain = mountpoint_hashtable + hash(NULL, dentry);
++  struct hlist_head *chain = mp_hash(dentry);
+   struct mountpoint *mp;
+   int ret;
  
mp = kmalloc(sizeof(struct mountpoint), GFP_KERNEL);
if (!mp)
@@@ -693,7 -702,8 +736,8 @@@
  
mp->m_dentry = dentry;
mp->m_count = 1;
 -  list_add(&mp->m_hash, chain);
 +  hlist_add_head(&mp->m_hash, chain);
+   INIT_LIST_HEAD(&mp->m_list);
return mp;
  }
  
@@@ -746,7 -757,8 +791,8 @@@ static void detach_mnt(struct mount *mn
mnt->mnt_parent = mnt;
mnt->mnt_mountpoint = mnt->mnt.mnt_root;
list_del_init(&mnt->mnt_child);
 -  list_del_init(&mnt->mnt_hash);
 +  hlist_del_init_rcu(&mnt->mnt_hash);
+   list_del_init(&mnt->mnt_mp_list);
put_mountpoint(mnt->mnt_mp);
mnt->mnt_mp = NULL;
  }



pgpJw7vBLHTVG.pgp
Description: PGP signature

hpsa driver bug crack kernel down!

[Baoquan He]

Hi,

The kernel is 3.14.0+ which is pulled just now. 


[   18.402695] systemd[1]: Set hostname to
.
[   18.408456] random: systemd urandom read with 70 bits of entropy
available
[   18md[1]: Expecting device
dev-mapper-rhel_hp\x2d\x2dsl4545g7\x2d\x2d01\x2droot.device...
 Expecting device
dev-mapper-rhel_hp\x2d\x2dsl4545g7\...droot.device...
[   18.860704] systemd[1]: Starting -.slice.
[  OK  ] Created slice -.slice.
[   18.866030] systemd[1]: Created slice -.slice.
[   18.869466] systemd[1]: Starting System Slice.
[  OK  ] Created slice System Sl   18.939116] systemd[1]: Created
slice System Slice.
[   18.976213] systemd[1]: Starting Slices.
[  OK  ] Reached target Slices.
[   18.981154] systemd[1]: Reached target Slices.
[   18.984183] systemd[1]: Starting Timers.
[  OK  ] Reached target Timers.
[   18.989161] systemd[1]: Reached target Timers.
[   18.992004] systemd[1]: Starting Journal Socket.
[  OK  ] Listening on Journal Socket.
[   18.997174] systemd[1]: Listening on Journal Socket.
[   19.000702] systemd[1]: Starting dracut cmdline hook...
 Starting dracut cmdline hook...
[   19.006697] systemd[1]: Started Load KernModules.
[   19.110408] systemd[1]: Starting Setup Virtual Console...
 Starting Setup Virtual Console...
[   19.116652] systemd[1]: Starting Journal Service...
 Starting Journal Service...
[  OK  ] Started Journal Service.
[   19.127172] systemd[1]: Started Journal Service.
[  OK  ] Listening on udev Kernel Socket.
[   19.141504] systemd-journald[281]: Vac[  OK  ] Listening on udev
Control Socket.
[  OK  ] Reached target Sockets.
 Starting Create list of required static device nodes...rrent
kernel...
 Starting Apply Kernel Variables...
[  OK  ] Reached target Swap.
[  OK  ] Reached target Local File Systems.
[  OK  ] Started dracut cmdline hook.
[  OK  ] Started Setup Virtual Console.
[  OK  ] Started Apply Kernel Variables.
[  OK  ] Started Create list of required static device nodes ...current
kernel.
 Starting Create static device nodes in /dev...
 Starting dracut pre-udev hook...
[  OK  ] Started Create static device nodes in /dev.
[   20.247819] device-mapper: uevent: version 1.0.3
[   20.251101] device-mapper: ioctl: 4.27.0-ioctl (2013-10-30)
initialised: dm-de...@redhat.com
[  OK  ] Started dracut pre-udev hook.
 Starting udev Kernel Device Manager...
[   20.322923] systemd-udevd[335]: starting version 208
[  OK  ] Started udev Kernel Device Manager.
 Starting udev Coldplug all Devices...
 Mounting Configuration File System...
[  OK  ] Mounted Configuration File System.
[  OK  ] Started udev Coldplug all Devices.
 Starting dracut initqueue hook...
[  OK  ][1] HP HPSA Driver (v 3.4.4-1)
[   20.832850] hpsa :05:00.0: can't disable ASPM; OS doesn't have
ASPM control
 Reached target System Initialization.
[   20.875178] ACPI: PCI Interrupt Link [I0C0] enabled at IRQ 36
[   20.909000] hpsa :05:00.0: MSIX
[   20.911586] hpsa :05:00.0: Logical aborts not supported
 [   20.916004] [drm] Initialized drm 1.1.0 20060810
[   20.936139] hpsa :05:00.0: hpsa0: <0x323b> at IRQ 73 using DAC
[   20.956967] BUG: unable to handle kernel NULL pointer dereference at
(null)
[   20.956997] IP: []
hpsa_enter_performant_mode+0x4ff/0x580 [hpsa]
[   20.957003] PGD 0 
[   20.957012] Oops: 0002 [#1] SMP 
[   20.957035] Modules linked in: drm(+) libata hpsa(+) i2c_core
dm_mirror dm_region_hash dm_log dm_mod
[   20.957046] CPU: 10 PID: 341 Comm: systemd-udevd Not tainted 3.14.0+
#28
[   20.957049] Hardware name: HP ProLiant SL4545 G7/, BIOS A31
12/08/2012
[   20.957055] task: 880824191b40 ti: 88082309c000 task.ti:
88082309c000
[   20.957078] RIP: 0010:[]  []
hpsa_enter_performant_mode+0x4ff/0x580 [hpsa]
[   20.957083] RSP: 0018:88082309da18  EFLAGS: 00010297
[   20.957088] RAX:  RBX: 7c000167 RCX:
0004
[   20.957091] RDX: 

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

linux-next: manual merge of the userns tree with Linus' tree

[Stephen Rothwell]

Hi Eric,

Today's linux-next merge of the userns tree got a conflict in fs/namei.c
between commits from Linus' tree and commits 3dd905eaa258 ("vfs: Don't
allow overwriting mounts in the current mount namespace") and
f43d102a391d ("vfs: Lazily remove mounts on unlinked files and
directories") from the userns tree.

I fixed it up (I used the conflict resolution that you sent to Linus -
see below) and can carry the fix as necessary (no action is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc fs/namei.c
index 88339f59efb5,384fcc6a5606..
--- a/fs/namei.c
+++ b/fs/namei.c
@@@ -4082,33 -4045,17 +4085,33 @@@ int vfs_rename(struct inode *old_dir, s
if (error)
return error;
  
 +  old_name = fsnotify_oldname_init(old_dentry->d_name.name);
dget(new_dentry);
 -  lock_two_nondirectories(source, target);
 +  if (!is_dir || (flags & RENAME_EXCHANGE))
 +  lock_two_nondirectories(source, target);
 +  else if (target)
 +  mutex_lock(&target->i_mutex);
  
error = -EBUSY;
-   if (d_mountpoint(old_dentry) || d_mountpoint(new_dentry))
+   if (is_local_mountpoint(old_dentry) || is_local_mountpoint(new_dentry))
goto out;
  
 -  error = try_break_deleg(source, delegated_inode);
 -  if (error)
 -  goto out;
 -  if (target) {
 +  if (max_links && new_dir != old_dir) {
 +  error = -EMLINK;
 +  if (is_dir && !new_is_dir && new_dir->i_nlink >= max_links)
 +  goto out;
 +  if ((flags & RENAME_EXCHANGE) && !is_dir && new_is_dir &&
 +  old_dir->i_nlink >= max_links)
 +  goto out;
 +  }
 +  if (is_dir && !(flags & RENAME_EXCHANGE) && target)
 +  shrink_dcache_parent(new_dentry);
 +  if (!is_dir) {
 +  error = try_break_deleg(source, delegated_inode);
 +  if (error)
 +  goto out;
 +  }
 +  if (target && !new_is_dir) {
error = try_break_deleg(target, delegated_inode);
if (error)
goto out;
@@@ -4123,31 -4064,73 +4126,32 @@@
if (error)
goto out;
  
 -  if (target) {
 +  if (!(flags & RENAME_EXCHANGE) && target) {
 +  if (is_dir)
 +  target->i_flags |= S_DEAD;
dont_mount(new_dentry);
+   detach_mounts(new_dentry);
}
 -  if (!(old_dir->i_sb->s_type->fs_flags & FS_RENAME_DOES_D_MOVE))
 -  d_move(old_dentry, new_dentry);
 +  if (!(old_dir->i_sb->s_type->fs_flags & FS_RENAME_DOES_D_MOVE)) {
 +  if (!(flags & RENAME_EXCHANGE))
 +  d_move(old_dentry, new_dentry);
 +  else
 +  d_exchange(old_dentry, new_dentry);
 +  }
  out:
 -  unlock_two_nondirectories(source, target);
 +  if (!is_dir || (flags & RENAME_EXCHANGE))
 +  unlock_two_nondirectories(source, target);
 +  else if (target)
 +  mutex_unlock(&target->i_mutex);
dput(new_dentry);
 -  return error;
 -}
 -
 -/**
 - * vfs_rename - rename a filesystem object
 - * @old_dir:  parent of source
 - * @old_dentry:   source
 - * @new_dir:  parent of destination
 - * @new_dentry:   destination
 - * @delegated_inode: returns an inode needing a delegation break
 - *
 - * The caller must hold multiple mutexes--see lock_rename()).
 - *
 - * If vfs_rename discovers a delegation in need of breaking at either
 - * the source or destination, it will return -EWOULDBLOCK and return a
 - * reference to the inode in delegated_inode.  The caller should then
 - * break the delegation and retry.  Because breaking a delegation may
 - * take a long time, the caller should drop all locks before doing
 - * so.
 - *
 - * Alternatively, a caller may pass NULL for delegated_inode.  This may
 - * be appropriate for callers that expect the underlying filesystem not
 - * to be NFS exported.
 - */
 -int vfs_rename(struct inode *old_dir, struct dentry *old_dentry,
 - struct inode *new_dir, struct dentry *new_dentry,
 - struct inode **delegated_inode)
 -{
 -  int error;
 -  int is_dir = d_is_directory(old_dentry) || d_is_autodir(old_dentry);
 -  const unsigned char *old_name;
 -
 -  if (old_dentry->d_inode == new_dentry->d_inode)
 -  return 0;
 - 
 -  error = may_delete(old_dir, old_dentry, is_dir);
 -  if (error)
 -  return error;
 -
 -  if (!new_dentry->d_inode)
 -  error = may_create(new_dir, new_dentry);
 -  else
 -  error = may_delete(new_dir, new_dentry, is_dir);
 -  if (error)
 -  return error;
 -
 -  if (!old_dir->i_op->rename)
 -  return -EPERM;
 -
 -  old_name = fsnotify_oldname_init(old_dentry->d_name.name);
 -
 -  if (is_dir)
 -

linux-next: manual merge of the userns tree with Linus' tree

[Stephen Rothwell]

Hi Eric,

Today's linux-next merge of the userns tree got a conflict in fs/dcache.c
between commit da1ce0670c14 ("vfs: add cross-rename") from Linus' tree
and commit f43d102a391d ("vfs: Lazily remove mounts on unlinked files and
directories") from the userns tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).  This matches the conflict resolution you sent to Linus.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc fs/dcache.c
index 40707d88a945,5b78bd98649c..
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@@ -2701,10 -2631,8 +2663,8 @@@ static struct dentry *__d_unalias(struc
goto out_err;
m2 = &alias->d_parent->d_inode->i_mutex;
  out_unalias:
-   if (likely(!d_mountpoint(alias))) {
-   __d_move(alias, dentry, false);
-   ret = alias;
-   }
 -  __d_move(alias, dentry);
++  __d_move(alias, dentry, false);
+   ret = alias;
  out_err:
spin_unlock(&inode->i_lock);
if (m2)


pgpVnxLJHQy6P.pgp
Description: PGP signature

Re: [GIT PULL] Detaching mounts on unlink for 3.15-rc1

[Al Viro]

On Wed, Apr 09, 2014 at 03:30:27AM +0100, Al Viro wrote:

> > When renaming or unlinking directory entries that are not mountpoints
> > no additional locks are taken so no performance differences can result,
> > and my benchmark reflected that.
> 
> It also means that d_invalidate() now might trigger fs shutdown.  Which
> has bloody huge stack footprint, for obvious reasons.  And d_invalidate()
> can be called with pretty deep stack - walk into wrong dentry while
> resolving a deeply nested symlink and there you go...

PS: I thought I actually replied with that point back a month or so ago,
but having checked sent-mail...  Looks like I had not.  My deep apologies.

FWIW, I think that overall this thing is a good idea, provided that we can
live with semantics changes.  The implementation is too optimistic, though -
at the very least, we want this work done upon namespace_unlock() held
back until we are not too deep in stack.  task_work_add() fodder, perhaps?
--
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] cpufreq: highbank: fix ARM_HIGHBANK_CPUFREQ dependency warning

[Kefeng Wang]

When make ARCH=arm multi_v7_defconfig, we get the following warnings:

warning: (ARM_HIGHBANK_CPUFREQ) selects GENERIC_CPUFREQ_CPU0 which has
unmet direct dependencies (ARCH_HAS_CPUFREQ && CPU_FREQ && HAVE_CLK
&& REGULATOR && OF && THERMAL && CPU_THERMAL)

To fix this, make ARM_HIGHBANK_CPUFREQ depend on ARCH_HAS_CPUFREQ and
REGULATOR instead of selecting them, PM_OPP will be selected by 
ARCH_HAS_CPUFREQ.

Signed-off-by: Kefeng Wang 
---
 drivers/cpufreq/Kconfig.arm | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 1e2b9db..30dfaef 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -92,11 +92,7 @@ config ARM_EXYNOS_CPU_FREQ_BOOST_SW
 
 config ARM_HIGHBANK_CPUFREQ
tristate "Calxeda Highbank-based"
-   depends on ARCH_HIGHBANK
-   select GENERIC_CPUFREQ_CPU0
-   select PM_OPP
-   select REGULATOR
-
+   depends on ARCH_HIGHBANK && GENERIC_CPUFREQ_CPU0 && REGULATOR
default m
help
  This adds the CPUFreq driver for Calxeda Highbank SoC
-- 
1.8.2.2


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

Re: [PATCH 3/6] Revert "perf: Disable PERF_RECORD_MMAP2 support"

[Namhyung Kim]

On Mon, 24 Mar 2014 15:34:33 -0400, Don Zickus wrote:
> This reverts commit 3090ffb5a2515990182f3f55b0688a7817325488.

It seems if you exchange the order of patch 2 and 3 it'd be less
confusing  ;-p

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

Re: [GIT PULL] Detaching mounts on unlink for 3.15-rc1

[Al Viro]

On Tue, Apr 08, 2014 at 05:21:32PM -0700, Eric W. Biederman wrote:

> This set of changes has been reviewed and been sitting idle for the last
> 6 weeks.  In that time the vfs has slightly shifted under me the new
> version of rename and the mount hash list becoming a hlist.  None of
> those changes has caused changed the code in ways to invalidate these
> changes, but small conflicts do result and I have attached my conflict
> resolution at the end of this email in case it helps.
> 
> To recap these changes allow a file or a directory that is a mount point
> in one mount namespace to be unlinked/rmdired elsewhere where it is not
> a mount point (either a remote filesystem or another mount namespace).
> As has been agreed during review semantics when only a single mount
> namespace exists remain unchanged.
> 
> This removes a long standing need to lie to the vfs when a mount point
> has been removed behind it's back.  This also removes a DOS attack where
> an unprivileged user could prevent root from renaming or deleting files
> and directories by using them as mountpoints in another mount namespace.
> 
> This change also fixes a few cases where because we were not lying to
> the vfs we could leak mount points.
> 
> When renaming or unlinking directory entries that are not mountpoints
> no additional locks are taken so no performance differences can result,
> and my benchmark reflected that.

It also means that d_invalidate() now might trigger fs shutdown.  Which
has bloody huge stack footprint, for obvious reasons.  And d_invalidate()
can be called with pretty deep stack - walk into wrong dentry while
resolving a deeply nested symlink and there you go...
--
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] iommu/vt-d: fix memory leakage caused by commit ea8ea46

[Jiang Liu]

Commit ea8ea46 "iommu/vt-d: Clean up and fix page table clear/free
behaviour" introduces possible leakage of DMA page tables due to:
for (pte = page_address(pg); !first_pte_in_page(pte); pte++) {
if (dma_pte_present(pte) && !dma_pte_superpage(pte))
freelist = dma_pte_list_pagetables(domain, level - 1,
   pte, freelist);
}

For the first pte in a page, first_pte_in_page(pte) will always be true,
thus dma_pte_list_pagetables() will never be called and leak DMA page
tables if level is bigger than 1.

Signed-off-by: Jiang Liu 
---
 drivers/iommu/intel-iommu.c |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 69fa7da..13dc231 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -1009,11 +1009,13 @@ static struct page *dma_pte_list_pagetables(struct 
dmar_domain *domain,
if (level == 1)
return freelist;
 
-   for (pte = page_address(pg); !first_pte_in_page(pte); pte++) {
+   pte = page_address(pg);
+   do {
if (dma_pte_present(pte) && !dma_pte_superpage(pte))
freelist = dma_pte_list_pagetables(domain, level - 1,
   pte, freelist);
-   }
+   pte++;
+   } while (!first_pte_in_page(pte));
 
return freelist;
 }
-- 
1.7.10.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 2/6] perf: Update mmap2 interface with protection and flag bits

[Namhyung Kim]

On Wed, 09 Apr 2014 11:17:44 +0900, Namhyung Kim wrote:
> So you need to synthesize a PERF_RECORD_MMAP2 event then.  The
> mmap_event and mmap2_event shares same fields util ->pgoff only.  So
> copying to mmap.filename will overwrite other bits in mmap2.

Oops, missed patch 3/3 already does it.  Sorry for noise.

Thanks,
Namhyung
--
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] futex: avoid race between requeue and wake

[Davidlohr Bueso]

Adding Thomas to the thread.

Sorry for the late reply, I was out running errands all day just to get
home to find this futex jewel in my inbox.

On Tue, 2014-04-08 at 15:30 -0700, Linus Torvalds wrote:
> On Tue, Apr 8, 2014 at 2:02 PM, Jan Stancek  wrote:
> >
> > I ran reproducer with following change on s390x system, where this
> > can be reproduced usually within seconds:
> >
> > diff --git a/kernel/futex.c b/kernel/futex.c
> > index 67dacaf..9150ffd 100644
> > --- a/kernel/futex.c
> > +++ b/kernel/futex.c
> > @@ -1095,6 +1095,7 @@ static int unlock_futex_pi(u32 __user *uaddr, u32 
> > uval)
> >  static inline void
> >  double_lock_hb(struct futex_hash_bucket *hb1, struct futex_hash_bucket 
> > *hb2)
> >  {
> > +   hb_waiters_inc(hb2);
> > if (hb1 <= hb2) {
> > spin_lock(&hb1->lock);
> > if (hb1 < hb2)
> > @@ -,6 +1112,7 @@ double_unlock_hb(struct futex_hash_bucket *hb1, 
> > struct futex_hash_bucket *hb2)
> > spin_unlock(&hb1->lock);
> > if (hb1 != hb2)
> > spin_unlock(&hb2->lock);
> > +   hb_waiters_dec(hb2);
> >  }
> >
> >  /*
> >
> > Reproducer is running without failures over an hour now and
> > made ~1.4 million iterations.
> 
> Ok, that's encouraging. That is the smallest patch I could come up
> with, but as mentioned, it's not optimal. We only need it for
> futex_requeue(), but if we do it there we'd have to handle all the
> different error cases (there's only one call to double_lock_hb(), but
> due to the error cases there's four calls to double_unlock_hb().

For consistency and mental sanity, I definitely prefer this alternative
to adding back the spin_is_locked check.

Linus, from what I see from your approach in always adding and
decrementing the hb->waiters count in futex_requeue right before the
whole double_[un]lock_hb() calls, we're basically saying "lets not do
this pending waiters optimization" for futex requeuing, right?
Which is fine, requeing isn't really that used or performance critical
in many cases. But I say it since the legitimate accounting for is done
in requeue_futex(), which can obviously be bogus as we increment *after*
taking the hb->lock. Just want to make sure we're on the same page here.

> 
> I'm not sure how much we care. The simple patch basically adds two
> (unnecessary) atomics to the futex_wake_op() path. I don't know how
> critical that path is - not as critical as the regular "futex_wake()",
> I'd expect, but I guess pthread_cond_signal() is the main user.

Agreed, since the issue occurs because we're requeuing *waiters*, lets
keep it inside the requeueing only. In the case of futex_wake_op() it
doesn't matter as we don't need to account for them. It's more code, but
that's it. I'd rather add error house keeping than add more unnecessary
logic to other paths of futexes.

> 
> So I'll have to leave this decision to the futex people. But the
> attached slightly more complex patch *may* be the better one.
> 
> May I bother you to test this one too? I really think that
> futex_requeue() is the only user that should need this, so doing it
> there rather than in double_[un]lock_hb() should be slightly more
> optimal, but who knows what I've missed. We clearly *all* missed this
> race back when the ordering rules were documented..

Yep, it's quite an obvious thing we overlooked here, and not even arch
specific... I'm surprised that the requeueing path isn't stressed more
often, and while the race window is quite small (I'm still running Jan's
program in a loop and cannot trigger it on my x86-64 80 core box), it
should have been seen earlier by some program/benchmark.

Thanks,
Davidlohr


--
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/6] perf: Update mmap2 interface with protection and flag bits

[Namhyung Kim]

On Mon, 24 Mar 2014 15:34:32 -0400, Don Zickus wrote:
> The kernel piece passes more info now.  Update the perf tool to reflect
> that and adjust the synthesized maps to play along.
>
> Signed-off-by: Don Zickus 
> ---
>  tools/perf/util/event.c   | 23 +--
>  tools/perf/util/event.h   |  2 ++
>  tools/perf/util/machine.c |  4 +++-
>  tools/perf/util/map.c |  4 +++-
>  tools/perf/util/map.h |  4 +++-
>  5 files changed, 32 insertions(+), 5 deletions(-)
>
> diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
> index 9d12aa6..6b8646c 100644
> --- a/tools/perf/util/event.c
> +++ b/tools/perf/util/event.c
> @@ -1,4 +1,5 @@
>  #include 
> +#include 
>  #include "event.h"
>  #include "debug.h"
>  #include "hist.h"
> @@ -212,6 +213,21 @@ int perf_event__synthesize_mmap_events(struct perf_tool 
> *tool,
>   else
>   event->header.misc = PERF_RECORD_MISC_GUEST_USER;
>  
> + /* map protection and flags bits */
> + event->mmap2.prot = 0;
> + event->mmap2.flags = 0;
> + if (prot[0] == 'r')
> + event->mmap2.prot |= PROT_READ;
> + if (prot[1] == 'w')
> + event->mmap2.prot |= PROT_WRITE;
> + if (prot[2] == 'x')
> + event->mmap2.prot |= PROT_EXEC;
> +
> + if (prot[3] == 's')
> + event->mmap2.flags |= MAP_SHARED;
> + else
> + event->mmap2.flags |= MAP_PRIVATE;
> +

So you need to synthesize a PERF_RECORD_MMAP2 event then.  The
mmap_event and mmap2_event shares same fields util ->pgoff only.  So
copying to mmap.filename will overwrite other bits in mmap2.

Thanks,
Namhyung
--
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 RESEND] usb: ohci-exynos: Remove locks for 'ohci' in suspend callback

[Jingoo Han]

On Tuesday, April 08, 2014 11:41 PM, Vivek Gautam wrote:
> 
> Patch : 14982e3 USB: OHCI: Properly handle ohci-exynos suspend
> has already removed 'ohci_hcd' settings from exynos glue layer
> as a part of streamlining the ohci controller's suspend.
> So we don't need the locks for 'ohci_hcd' anymore.

Right, this spin_lock/unlock is unnecessary, because it is
already used in ohci_suspend().

Acked-by: Jingoo Han 

Best regards,
Jingoo Han

> 
> Signed-off-by: Vivek Gautam 
> Cc: Manjunath Goudar 
> Cc: Alan Stern 
> ---
>  drivers/usb/host/ohci-exynos.c |6 --
>  1 file changed, 6 deletions(-)
> 
> diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
> index 68588d8..9cf80cb 100644
> --- a/drivers/usb/host/ohci-exynos.c
> +++ b/drivers/usb/host/ohci-exynos.c
> @@ -190,17 +190,13 @@ static int exynos_ohci_suspend(struct device *dev)
>  {
>   struct usb_hcd *hcd = dev_get_drvdata(dev);
>   struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
> - struct ohci_hcd *ohci = hcd_to_ohci(hcd);
>   struct platform_device *pdev = to_platform_device(dev);
>   bool do_wakeup = device_may_wakeup(dev);
> - unsigned long flags;
>   int rc = ohci_suspend(hcd, do_wakeup);
> 
>   if (rc)
>   return rc;
> 
> - spin_lock_irqsave(&ohci->lock, flags);
> -
>   if (exynos_ohci->otg)
>   exynos_ohci->otg->set_host(exynos_ohci->otg, &hcd->self);
> 
> @@ -208,8 +204,6 @@ static int exynos_ohci_suspend(struct device *dev)
> 
>   clk_disable_unprepare(exynos_ohci->clk);
> 
> - spin_unlock_irqrestore(&ohci->lock, flags);
> -
>   return 0;
>  }
> 
> --
> 1.7.10.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 07/15 V3] perf, c2c: Add in sort on physid

[Don Zickus]

On Wed, Apr 09, 2014 at 10:30:56AM +0900, Namhyung Kim wrote:
> On Tue, 8 Apr 2014 10:17:58 -0400, Don Zickus wrote:
> > On Tue, Apr 08, 2014 at 04:56:25PM +0900, Namhyung Kim wrote:
> >> On Mon, 24 Mar 2014 15:36:58 -0400, Don Zickus wrote:
> >> > +static int perf_c2c__init(struct perf_c2c *c2c)
> >> > +{
> >> > +sort__mode = SORT_MODE__PHYSID;
> >> > +sort__wants_unique = 1;
> >> > +sort_order = "daddr,iaddr,pid,tid";
> >> 
> >> Where are the SORT_MODE__PHYSID, sort__wants_unique and "daddr", "iaddr"
> >> sort keys defined?
> >
> > In a previous patchset that enables the mmap2 interface.
> 
> Ah, missed that.. will look at it soon.
> 
> >
> >> 
> >> Also, more importantly, I think the sort order should contain at least
> >> "mem" and "snoop" keys to group samples based on the exact hitm
> >> information.
> >
> > I can look into it, but after iaddr, pid and tid, sorting on snoop doesn't
> > really change anything if I recall.  The hitms are scattered across iaddr.
> 
> But it doesn't guarantee that all hitms are scattered, right?  Also if
> it's the case I guess adding more sort keys are not harmful since they
> don't even have a chance to test.
> 
> I think you can check hist_entry->stat.nr_events always being 1.
> 
> >
> >> 
> >> In my understanding, if two samples are captured at exactly same
> >> position with a same data access but different hitm info, they cannot be
> >> classified and just use the hitm info of first entry.
> >
> > Why?  If the first hitm access was local and the second one remote,
> > doesn't that indicate the accessed data is being pulled onto different
> > nodes?
> 
> But "hist_entry" won't have the information after calling
> __hists__add__entry() called unless it has 'mem' and 'snoop' sort keys.
> Since two samples have same daddr, iaddr, pid and tid, it'd think those
> two samples are same and then add stats of second one to the first and
> finally discard the second.  So first one will have a double weight for
> the local hitm case only.
> 
> This is the case what I worry about.  Am I missing something?

My patch 6/6 of the enable mmap2 support. :-)  It specifically forces all
the data to remain separate to avoid this issue.  We couldn't have the
data merged because it messed up our stats.

Cheers,
Don
--
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] driver core: platform: add device binding path 'driver_override'

[Kim Phillips]

Needed by platform device drivers, such as the vfio-platform driver [1],
in order to bypass the existing OF, ACPI, id_table and name string matches,
and successfully be able to be bound to any device, like so:

echo vfio-platform > /sys/bus/platform/devices/fff51000.ethernet/driver_override
echo fff51000.ethernet > 
/sys/bus/platform/devices/fff51000.ethernet/driver/unbind
echo fff51000.ethernet > /sys/bus/platform/drivers_probe

This mimics "PCI: Introduce new device binding path using
pci_dev.driver_override" [2], which is an interface enhancement
for more deterministic PCI device binding, e.g., when in the
presence of hotplug.

[1] http://lkml.iu.edu/hypermail/linux/kernel/1402.1/00177.html
[2] 
http://lists-archives.com/linux-kernel/28030441-pci-introduce-new-device-binding-path-using-pci_dev-driver_override.html

Suggested-by: Alex Williamson 
Signed-off-by: Kim Phillips 
---
changes since RFC:
- fixed message Subject to properly reflect a new platform device
patch (instead of leaving it as a reply to the PCI version)
- addressed Guenter Roeck's comment
- updated [2] with link to later (Apr.4th) revision of the PCI patch
- updated documentation to address Christoffer Dall's comments to
  previous version of [2]
- added a Suggested-by, and re-posted as a reply to the PCI patch,
  should they be applied together

 Documentation/ABI/testing/sysfs-bus-platform | 20 
 drivers/base/platform.c  | 46 
 include/linux/platform_device.h  |  1 +
 3 files changed, 67 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-platform

diff --git a/Documentation/ABI/testing/sysfs-bus-platform 
b/Documentation/ABI/testing/sysfs-bus-platform
new file mode 100644
index 000..5172a61
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-platform
@@ -0,0 +1,20 @@
+What:  /sys/bus/platform/devices/.../driver_override
+Date:  April 2014
+Contact:   Kim Phillips 
+Description:
+   This file allows the driver for a device to be specified which
+   will override standard OF, ACPI, ID table, and name matching.
+   When specified, only a driver with a name matching the value
+   written to driver_override will have an opportunity to bind
+   to the device.  The override is specified by writing a string
+   to the driver_override file (echo vfio-platform > \
+   driver_override) and may be cleared with an empty string
+   (echo > driver_override).  This returns the device to standard
+   matching rules binding.  Writing to driver_override does not
+   automatically unbind the device from its current driver or make
+   any attempt to automatically load the specified driver.  If no
+   driver with a matching name is currently loaded in the kernel,
+   the device will not bind to any driver.  This also allows
+   devices to opt-out of driver binding using a driver_override
+   name such as "none".  Only a single driver may be specified in
+   the override, there is no support for parsing delimiters.
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index e714709..a0909cb 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "base.h"
 #include "power/power.h"
@@ -690,8 +691,49 @@ static ssize_t modalias_show(struct device *dev, struct 
device_attribute *a,
 }
 static DEVICE_ATTR_RO(modalias);
 
+static ssize_t driver_override_store(struct device *dev,
+struct device_attribute *attr,
+const char *buf, size_t count)
+{
+   struct platform_device *pdev = to_platform_device(dev);
+   char *driver_override, *old = pdev->driver_override, *cp;
+
+   if (count > PATH_MAX)
+   return -EINVAL;
+
+   driver_override = kstrndup(buf, count, GFP_KERNEL);
+   if (!driver_override)
+   return -ENOMEM;
+
+   cp = strchr(driver_override, '\n');
+   if (cp)
+   *cp = '\0';
+
+   if (strlen(driver_override)) {
+   pdev->driver_override = driver_override;
+   } else {
+   kfree(driver_override);
+   pdev->driver_override = NULL;
+   }
+
+   kfree(old);
+
+   return count;
+}
+
+static ssize_t driver_override_show(struct device *dev,
+   struct device_attribute *attr, char *buf)
+{
+   struct platform_device *pdev = to_platform_device(dev);
+
+   return sprintf(buf, "%s\n", pdev->driver_override);
+}
+static DEVICE_ATTR_RW(driver_override);
+
+
 static struct attribute *platform_dev_attrs[] = {
&dev_attr_modalias.attr,
+   &dev_attr_driver_override.attr,
NULL,
 };
 ATTRIBUTE_GROUPS(platform_dev);
@@ -747,6 +789,10

[PATCH] sym53c8xx_2: Set DID_REQUEUE return code when aborting squeue

[Mikulas Patocka]

[ the maintainer didn't respond, so I'm sending to Linus ]


This patch fixes I/O errors when the disk returns QUEUE FULL status.

When the controller encounters an error (including QUEUE FULL or BUSY status),
it aborts all not yet submitted requests in the function
sym_dequeue_from_squeue.

This function aborts them with DID_SOFT_ERROR.

If the disk has full tag queue, the request that caused the overflow is 
aborted with QUEUE FULL status (and the scsi midlayer properly retries it 
until it is accepted by the disk), but the sym53c8xx_2 driver aborts the 
following requests with DID_SOFT_ERROR --- for them, the midlayer does 
just a few retries and then signals the error up to sd.

The result is that disk returning QUEUE FULL causes request failures.

The error was reproduced on 53c895 with COMPAQ BD03685A24 disk (rebranded
ST336607LC) with command queue 48 or 64 tags. The disk has 64 tags, but
under some access patterns it return QUEUE FULL when there are less than
64 pending tags. The SCSI specification allows returning QUEUE FULL
anytime and it is up to the host to retry.

Signed-off-by: Mikulas Patocka 

---
 drivers/scsi/sym53c8xx_2/sym_hipd.c |4 
 1 file changed, 4 insertions(+)

Index: linux-2.6.36-rc5-fast/drivers/scsi/sym53c8xx_2/sym_hipd.c
===
--- linux-2.6.36-rc5-fast.orig/drivers/scsi/sym53c8xx_2/sym_hipd.c  
2010-09-27 10:25:59.0 +0200
+++ linux-2.6.36-rc5-fast/drivers/scsi/sym53c8xx_2/sym_hipd.c   2010-09-27 
10:26:27.0 +0200
@@ -3000,7 +3000,11 @@ sym_dequeue_from_squeue(struct sym_hcb *
if ((target == -1 || cp->target == target) &&
(lun== -1 || cp->lun== lun)&&
(task   == -1 || cp->tag== task)) {
+#ifdef SYM_OPT_HANDLE_DEVICE_QUEUEING
sym_set_cam_status(cp->cmd, DID_SOFT_ERROR);
+#else
+   sym_set_cam_status(cp->cmd, DID_REQUEUE);
+#endif
sym_remque(&cp->link_ccbq);
sym_insque_tail(&cp->link_ccbq, &np->comp_ccbq);
}
--
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] perf, tools, stat: Initialize statistics correctly

[Namhyung Kim]

On Tue, 25 Mar 2014 10:31:38 -0700, Andi Kleen wrote:
> From: Andi Kleen 
>
> perf stat did initialize the stats structure used to compute
> stddev etc. incorrectly. It merely zeroes it. But one member
> (min) needs to be set to a non zero value. This causes min
> to be not computed at all. Call init_stats() correctly.
>
> It doesn't matter for stat currently because it doesn't use
> min, but it's still better to do it correctly.
>
> The other users of statistics are already correct.

Acked-by: Namhyung Kim 

Thanks,
Namhyung
--
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 1/2] mm: move FAULT_AROUND_ORDER to arch/

[Madhavan Srinivasan]

On Friday 04 April 2014 11:20 PM, David Miller wrote:
> From: Dave Hansen 
> Date: Fri, 04 Apr 2014 09:18:43 -0700
> 
>> On 04/03/2014 11:27 PM, Madhavan Srinivasan wrote:
>>> This patch creates infrastructure to move the FAULT_AROUND_ORDER
>>> to arch/ using Kconfig. This will enable architecture maintainers
>>> to decide on suitable FAULT_AROUND_ORDER value based on
>>> performance data for that architecture. Patch also adds
>>> FAULT_AROUND_ORDER Kconfig element in arch/X86.
>>
>> Please don't do it this way.
>>
>> In mm/Kconfig, put
>>
>>  config FAULT_AROUND_ORDER
>>  int
>>  default 1234 if POWERPC
>>  default 4
>>
>> The way you have it now, every single architecture that needs to enable
>> this has to go put that in their Kconfig.  That's madness.  This way,
>> you only put it in one place, and folks only have to care if they want
>> to change the default to be something other than 4.
> 
> It looks more like it's necessary only to change the default, not
> to enable it.  Unless I read his patch wrong...
> 
Yes. With current patch, you only need to change the default by which
you enable it.

With regards
Maddy
> 

--
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 05/15 V3] perf, c2c: Rework setup code to prepare for features

[Don Zickus]

On Wed, Apr 09, 2014 at 10:12:32AM +0900, Namhyung Kim wrote:
> On Tue, 8 Apr 2014 10:11:07 -0400, Don Zickus wrote:
> > On Tue, Apr 08, 2014 at 04:41:29PM +0900, Namhyung Kim wrote:
> >> On Sat, 29 Mar 2014 18:10:18 +0100, Jiri Olsa wrote:
> >> > On Mon, Mar 24, 2014 at 03:36:56PM -0400, Don Zickus wrote:
> >> >
> >> > SNIP
> >> >
> >> >>  
> >> >>  static int perf_c2c__process_load_store(struct perf_c2c *c2c,
> >> >> +   struct addr_location *al,
> >> >> struct perf_sample *sample,
> >> >> -   struct addr_location *al)
> >> >> +   struct perf_evsel *evsel)
> >> >>  {
> >> >> -   if (c2c->raw_records)
> >> >> -   perf_sample__fprintf(sample, ' ', "raw input", al, 
> >> >> stdout);
> >> >> +   struct mem_info *mi;
> >> >> +
> >> >> +   mi = sample__resolve_mem(sample, al);
> >> >> +   if (!mi)
> >> >> +   return -ENOMEM;
> >> >
> >> > perhaps not directly related to this patchset, but I needed
> >> > attached patch to get resolved data in .bss (static), which
> >> > for some reason happened to be located in executable segment
> >> 
> >> Wasn't it a read-only/const data?
> >
> > I believe it had the 'x' bit set.  Or the kernel was not passing any
> > protection bits, so it defaulted to MAP_FUNCTION?
> 
> The perf treats a mapping as a data mapping (MAP_VARIABLE) by default if
> the 'x' bit is not set.  As Jiri said its a static data, I guessed it's
> a const data (set to 0?) and moved into .rodata section and then to the
> text segment.

Unfortunately, his patch will be needed eventually, if not for his reason,
I had a java JAR file example that was pulling data addresses out of a
shared memory region with the protection bits set to 'rwx' (in the
/proc//maps area).  I was losing lots of samples until I came up with
a more complicated hack.

I will try to dig up my example, so you can see, so it doesn't sound like
I am making this up. :-)

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

Re: [GIT] kbuild/lto changes for 3.15-rc1

[Andi Kleen]

On Tue, Apr 08, 2014 at 03:44:25PM -0700, Linus Torvalds wrote:
> On Tue, Apr 8, 2014 at 1:49 PM,   wrote:
> >
> > In addition to making the kernel smaller and such (I'll leave the
> > specific stats there to Andi), here's the key awesomeness of LTO that
> > you, personally, should find useful and compelling: LTO will eliminate
> > the need to add many lower-level Kconfig symbols to compile out bits of
> > the kernel.
> 
> Actually that, to me, is a negative right now.
> 
> Since there's no way we'll make LTO the default in the foreseeable
> future, people starting to use it like that is just a bad bad thing.
> 
> So really, the main advantage of LTO would be any actual optimizations
> it can do. And call me anal, but I want *numbers* for that before I
> merge it. Not handwaving. I'm not actually aware of how well - if at
> all - code generation actually improves.

Well it looks very different if you look at the generated code. gcc becomes
a lot more aggressive.

But as I said there's currently no significant performance improvement known,
so if your only goal is better performance this patch (as currently) 
known is not a big winner.  My suspicion is that's mostly because
the standard benchmarks we run are not too compiler sensitive.

However the users seem to care about the other benefits, like code size.

And there may well be loads that are compiler sensitive.
As Honza posted, for non kernel workloads LTO is known to have large benefits.

Besides at this point it's pretty much just some additions to the Makefiles.

-Andi

-- 
a...@linux.intel.com -- Speaking for myself only
--
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]pwm: add BCM2835 PWM driver

[Stephen Warren]

On 04/08/2014 05:02 PM, Tim Kryger wrote:
> On Thu, Apr 3, 2014 at 6:44 AM, Bart Tanghe  wrote:
>> need some recommendation
>> the memory mapped io registers of the bcm2835 pwm hardware are spreaded
>> over the memory mapped io
>> gpio config 0x2024 - clk config 0x201010A0 - pwm configuration 0x2020C000
>> to handle this, I've used the base address of the memory mapped io
>> so I can use positive offsets
> 
> So the registers for this PWM are located in three distinct memory regions?
...
>> +struct bcm2835_pwm_chip {
>> +   struct pwm_chip chip;
>> +   struct device *dev;
>> +   int channel;
>> +   void __iomem *mmio;
> 
> One pointer isn't going to be enough.  You need three.
> 
> I suggest renaming the first and adding two more:
> 
> void __iomem *base_pwm;
> void __iomem *base_clk;
> void __iomem *base_alt;

Sorry, I forgot about this patch. One comment here; the PWM driver can't
touch the clock or alt registers; those should be owned by the clock
driver, and the driver for whatever alt is (pinmux - don't recall what
it's touching there).
--
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 1/2] mm: move FAULT_AROUND_ORDER to arch/

[Madhavan Srinivasan]

On Friday 04 April 2014 09:48 PM, Dave Hansen wrote:
> On 04/03/2014 11:27 PM, Madhavan Srinivasan wrote:
>> This patch creates infrastructure to move the FAULT_AROUND_ORDER
>> to arch/ using Kconfig. This will enable architecture maintainers
>> to decide on suitable FAULT_AROUND_ORDER value based on
>> performance data for that architecture. Patch also adds
>> FAULT_AROUND_ORDER Kconfig element in arch/X86.
> 
> Please don't do it this way.
> 
> In mm/Kconfig, put
> 
>   config FAULT_AROUND_ORDER
>   int
>   default 1234 if POWERPC
>   default 4
> 
> The way you have it now, every single architecture that needs to enable
> this has to go put that in their Kconfig.  That's madness.  This way,

I though about it and decided not to do this way because, in future,
sub platforms of the architecture may decide to change the values. Also,
adding an if line for each architecture with different sub platforms
oring to it will look messy.

With regards
Maddy

> you only put it in one place, and folks only have to care if they want
> to change the default to be something other than 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 07/15 V3] perf, c2c: Add in sort on physid

[Namhyung Kim]

On Tue, 8 Apr 2014 10:17:58 -0400, Don Zickus wrote:
> On Tue, Apr 08, 2014 at 04:56:25PM +0900, Namhyung Kim wrote:
>> On Mon, 24 Mar 2014 15:36:58 -0400, Don Zickus wrote:
>> > +static int perf_c2c__init(struct perf_c2c *c2c)
>> > +{
>> > +  sort__mode = SORT_MODE__PHYSID;
>> > +  sort__wants_unique = 1;
>> > +  sort_order = "daddr,iaddr,pid,tid";
>> 
>> Where are the SORT_MODE__PHYSID, sort__wants_unique and "daddr", "iaddr"
>> sort keys defined?
>
> In a previous patchset that enables the mmap2 interface.

Ah, missed that.. will look at it soon.

>
>> 
>> Also, more importantly, I think the sort order should contain at least
>> "mem" and "snoop" keys to group samples based on the exact hitm
>> information.
>
> I can look into it, but after iaddr, pid and tid, sorting on snoop doesn't
> really change anything if I recall.  The hitms are scattered across iaddr.

But it doesn't guarantee that all hitms are scattered, right?  Also if
it's the case I guess adding more sort keys are not harmful since they
don't even have a chance to test.

I think you can check hist_entry->stat.nr_events always being 1.

>
>> 
>> In my understanding, if two samples are captured at exactly same
>> position with a same data access but different hitm info, they cannot be
>> classified and just use the hitm info of first entry.
>
> Why?  If the first hitm access was local and the second one remote,
> doesn't that indicate the accessed data is being pulled onto different
> nodes?

But "hist_entry" won't have the information after calling
__hists__add__entry() called unless it has 'mem' and 'snoop' sort keys.
Since two samples have same daddr, iaddr, pid and tid, it'd think those
two samples are same and then add stats of second one to the first and
finally discard the second.  So first one will have a double weight for
the local hitm case only.

This is the case what I worry about.  Am I missing something?

Thanks,
Namhyung
--
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 03/15 V3] perf c2c: Shared data analyser

[Andi Kleen]

Namhyung Kim  writes:
>
> Well, I'm not sure ;-)  Yes, the c2c is a complex tool which might
> deserve an own command, but the functionality is very similar and I
> guess there's something to share between them.

They work very differently.  I don't see a lot of potential
for sharing.

perf mem is basically just a way to annotate normal samples slightly
with addresses, while c2c is fundamentally address driven.

-Andi

-- 
a...@linux.intel.com -- Speaking for myself only
--
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] ARM: dts: msm: Add 8921 PMIC to ssbi bus

[Stephen Boyd]

Add the PMIC and the sub-devices that are currently supported in
the kernel to the DT.

Signed-off-by: Stephen Boyd 
---
 arch/arm/boot/dts/qcom-msm8960-cdp.dts | 16 +++
 arch/arm/boot/dts/qcom-msm8960.dtsi| 37 ++
 2 files changed, 53 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-msm8960-cdp.dts 
b/arch/arm/boot/dts/qcom-msm8960-cdp.dts
index a58fb88315f6..6f61c54a653e 100644
--- a/arch/arm/boot/dts/qcom-msm8960-cdp.dts
+++ b/arch/arm/boot/dts/qcom-msm8960-cdp.dts
@@ -1,6 +1,22 @@
+#include 
+
 #include "qcom-msm8960.dtsi"
 
 / {
model = "Qualcomm MSM8960 CDP";
compatible = "qcom,msm8960-cdp", "qcom,msm8960";
+
+};
+
+&pmicintc {
+   keypad@148 {
+   linux,keymap = <
+   MATRIX_KEY(0, 0, KEY_VOLUMEUP)
+   MATRIX_KEY(0, 1, KEY_VOLUMEDOWN)
+   MATRIX_KEY(0, 2, KEY_CAMERA_FOCUS)
+   MATRIX_KEY(0, 3, KEY_CAMERA)
+   >;
+   keypad,num-rows = <1>;
+   keypad,num-columns = <5>;
+   };
 };
diff --git a/arch/arm/boot/dts/qcom-msm8960.dtsi 
b/arch/arm/boot/dts/qcom-msm8960.dtsi
index 997b7b94e117..fb7d3beece6d 100644
--- a/arch/arm/boot/dts/qcom-msm8960.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8960.dtsi
@@ -124,6 +124,43 @@
compatible = "qcom,ssbi";
reg = <0x50 0x1000>;
qcom,controller-type = "pmic-arbiter";
+
+   pmicintc: pmic@0 {
+   compatible = "qcom,pm8921";
+   interrupt-parent = <&msmgpio>;
+   interrupts = <104 8>;
+   #interrupt-cells = <2>;
+   interrupt-controller;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   pwrkey@1c {
+   compatible = "qcom,pm8921-pwrkey";
+   reg = <0x1c>;
+   interrupt-parent = <&pmicintc>;
+   interrupts = <50 1>, <51 1>;
+   debounce = <15625>;
+   pull-up;
+   };
+
+   keypad@148 {
+   compatible = "qcom,pm8921-keypad";
+   reg = <0x148>;
+   interrupt-parent = <&pmicintc>;
+   interrupts = <74 1>, <75 1>;
+   debounce = <15>;
+   scan-delay = <32>;
+   row-hold = <91500>;
+   };
+
+   rtc@11d {
+   compatible = "qcom,pm8921-rtc";
+   interrupt-parent = <&pmicintc>;
+   interrupts = <39 1>;
+   reg = <0x11d>;
+   allow-set-time;
+   };
+   };
};
 
rng@1a50 {
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

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

[PATCH 2/2] ARM: dts: msm: Add 8058 PMIC to ssbi bus

[Stephen Boyd]

Add the PMIC and the sub-devices that are currently supported in
the kernel to the DT.

Signed-off-by: Stephen Boyd 
---
 arch/arm/boot/dts/qcom-msm8660-surf.dts | 30 +++
 arch/arm/boot/dts/qcom-msm8660.dtsi | 42 +
 2 files changed, 72 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-msm8660-surf.dts 
b/arch/arm/boot/dts/qcom-msm8660-surf.dts
index 169bad90dac9..a27eedff62d3 100644
--- a/arch/arm/boot/dts/qcom-msm8660-surf.dts
+++ b/arch/arm/boot/dts/qcom-msm8660-surf.dts
@@ -1,6 +1,36 @@
+#include 
+
 #include "qcom-msm8660.dtsi"
 
 / {
model = "Qualcomm MSM8660 SURF";
compatible = "qcom,msm8660-surf", "qcom,msm8660";
 };
+
+&pmicintc {
+   keypad@148 {
+   linux,keymap = <
+   MATRIX_KEY(0, 0, KEY_FN_F1)
+   MATRIX_KEY(0, 1, KEY_UP)
+   MATRIX_KEY(0, 2, KEY_LEFT)
+   MATRIX_KEY(0, 3, KEY_VOLUMEUP)
+   MATRIX_KEY(1, 0, KEY_FN_F2)
+   MATRIX_KEY(1, 1, KEY_RIGHT)
+   MATRIX_KEY(1, 2, KEY_DOWN)
+   MATRIX_KEY(1, 3, KEY_VOLUMEDOWN)
+   MATRIX_KEY(2, 3, KEY_ENTER)
+   MATRIX_KEY(4, 0, KEY_CAMERA_FOCUS)
+   MATRIX_KEY(4, 1, KEY_UP)
+   MATRIX_KEY(4, 2, KEY_LEFT)
+   MATRIX_KEY(4, 3, KEY_HOME)
+   MATRIX_KEY(4, 4, KEY_FN_F3)
+   MATRIX_KEY(5, 0, KEY_CAMERA)
+   MATRIX_KEY(5, 1, KEY_RIGHT)
+   MATRIX_KEY(5, 2, KEY_DOWN)
+   MATRIX_KEY(5, 3, KEY_BACK)
+   MATRIX_KEY(5, 4, KEY_MENU)
+   >;
+   keypad,num-rows = <6>;
+   keypad,num-columns = <5>;
+   };
+};
diff --git a/arch/arm/boot/dts/qcom-msm8660.dtsi 
b/arch/arm/boot/dts/qcom-msm8660.dtsi
index c52a9e964a44..985b4c16976a 100644
--- a/arch/arm/boot/dts/qcom-msm8660.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8660.dtsi
@@ -83,5 +83,47 @@
compatible = "qcom,ssbi";
reg = <0x50 0x1000>;
qcom,controller-type = "pmic-arbiter";
+
+   pmicintc: pmic@0 {
+   compatible = "qcom,pm8058";
+   interrupt-parent = <&msmgpio>;
+   interrupts = <88 8>;
+   #interrupt-cells = <2>;
+   interrupt-controller;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   pwrkey@1c {
+   compatible = "qcom,pm8058-pwrkey";
+   reg = <0x1c>;
+   interrupt-parent = <&pmicintc>;
+   interrupts = <50 1>, <51 1>;
+   debounce = <15625>;
+   pull-up;
+   };
+
+   keypad@148 {
+   compatible = "qcom,pm8058-keypad";
+   reg = <0x148>;
+   interrupt-parent = <&pmicintc>;
+   interrupts = <74 1>, <75 1>;
+   debounce = <15>;
+   scan-delay = <32>;
+   row-hold = <91500>;
+   };
+
+   rtc@11d {
+   compatible = "qcom,pm8058-rtc";
+   interrupt-parent = <&pmicintc>;
+   interrupts = <39 1>;
+   reg = <0x11d>;
+   allow-set-time;
+   };
+
+   vibrator@4a {
+   compatible = "qcom,pm8058-vib";
+   reg = <0x4a>;
+   };
+   };
};
 };
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

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

Grant Award!!!

[Ford Foundation]

Attention,

The Ford Foundation has awarded the sum of 1.5m USD as a Grant Donation to you 
please contacts Email: grantawa...@ford-foundation.org with your details.Thanks

Regards

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

Re: [GIT] kbuild/lto changes for 3.15-rc1

[Andi Kleen]

Thanks Honza. Just one comment:

> The runtime benefits are more visible on bigger, bloated and less
> optimized projects than on hand tuned video encoder implementation.
> I believe Kernel largely falls into hand tuned category despite its size.

In my experience there's a lot of badly tuned code in the kernel these days,
especially when you go outside the core code (i.e. into drivers/*)

Or code that used to be tuned, but isn't aftermore after several years
of feature additions and bug fixes. The kernel code quality is also quite 
varying.

So anything the compiler can do helps.

> I would be curious about the results on Kernel.

We saw some upsides in performance with some standard tests, but nothing 
too significant.

-Andi
--
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: [clocksource] INFO: possible irq lock inversion dependency detected

[Jet Chen]

On 04/08/2014 01:21 PM, Viresh Kumar wrote:

On 8 April 2014 09:29, Jet Chen  wrote:

(Sorry for previous bad format email)
Your patch on my testing branch in LKP system:
git://bee.sh.intel.com/git/tchen37/linux.git timer_debug3 got the below
dmesg.
FYI, I applied your patch on the top of commit
6378cb51af5f4743db0dcb3cbcf862eac5908754 - timer: don't migrate pinned
timers.


Hi Jet,

Thanks for your efforts. It looks like we must use spin_lock_irqsave() here.
And that's all we need to fix this issue..



spin_lock_irqsave() does fix this issue.

Tested-by: Jet Chen 


To get the right order in which patches must be applied (obviously with the
updates I have), please pick this branch:

git://git.linaro.org/people/viresh.kumar/linux.git isolate-cpusets

I hope this fixes the issues you were getting.



--
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 1/2] mm: move FAULT_AROUND_ORDER to arch/

[Madhavan Srinivasan]

On Friday 04 April 2014 06:47 PM, Kirill A. Shutemov wrote:
> On Fri, Apr 04, 2014 at 11:57:14AM +0530, Madhavan Srinivasan wrote:
>> Kirill A. Shutemov with faultaround patchset introduced
>> vm_ops->map_pages() for mapping easy accessible pages around
>> fault address in hope to reduce number of minor page faults.
>>
>> This patch creates infrastructure to move the FAULT_AROUND_ORDER
>> to arch/ using Kconfig. This will enable architecture maintainers
>> to decide on suitable FAULT_AROUND_ORDER value based on
>> performance data for that architecture. Patch also adds
>> FAULT_AROUND_ORDER Kconfig element in arch/X86.
>>
>> Signed-off-by: Madhavan Srinivasan 
>> ---
>>  arch/x86/Kconfig   |4 
>>  include/linux/mm.h |9 +
>>  mm/memory.c|   12 +---
>>  3 files changed, 18 insertions(+), 7 deletions(-)
>>
>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>> index 9c0a657..5833f22 100644
>> --- a/arch/x86/Kconfig
>> +++ b/arch/x86/Kconfig
>> @@ -1177,6 +1177,10 @@ config DIRECT_GBPAGES
>>support it. This can improve the kernel's performance a tiny bit by
>>reducing TLB pressure. If in doubt, say "Y".
>>  
>> +config FAULT_AROUND_ORDER
>> +int
>> +default "4"
>> +
>>  # Common NUMA Features
>>  config NUMA
>>  bool "Numa Memory Allocation and Scheduler Support"
>> diff --git a/include/linux/mm.h b/include/linux/mm.h
>> index 0bd4359..b93c1c3 100644
>> --- a/include/linux/mm.h
>> +++ b/include/linux/mm.h
>> @@ -26,6 +26,15 @@ struct file_ra_state;
>>  struct user_struct;
>>  struct writeback_control;
>>  
>> +/*
>> + * Fault around order is a control knob to decide the fault around pages.
>> + * Default value is set to 0UL (disabled), but the arch can override it as
>> + * desired.
>> + */
>> +#ifndef CONFIG_FAULT_AROUND_ORDER
>> +#define CONFIG_FAULT_AROUND_ORDER 0
>> +#endif
>> +
> 
> I don't think it should be in header file: nobody except mm/memory.c cares.
> Just put it instead '#define FAULT_AROUND_ORDER'.
> 

Ok. Will do this change.

>>  #ifndef CONFIG_NEED_MULTIPLE_NODES  /* Don't use mapnrs, do it properly */
>>  extern unsigned long max_mapnr;
>>  
>> diff --git a/mm/memory.c b/mm/memory.c
>> index b02c584..22a4a89 100644
>> --- a/mm/memory.c
>> +++ b/mm/memory.c
>> @@ -3358,10 +3358,8 @@ void do_set_pte(struct vm_area_struct *vma, unsigned 
>> long address,
>>  update_mmu_cache(vma, address, pte);
>>  }
>>  
>> -#define FAULT_AROUND_ORDER 4
>> -
>>  #ifdef CONFIG_DEBUG_FS
>> -static unsigned int fault_around_order = FAULT_AROUND_ORDER;
>> +static unsigned int fault_around_order = CONFIG_FAULT_AROUND_ORDER;
>>  
>>  static int fault_around_order_get(void *data, u64 *val)
>>  {
>> @@ -3371,7 +3369,7 @@ static int fault_around_order_get(void *data, u64 *val)
>>  
>>  static int fault_around_order_set(void *data, u64 val)
>>  {
>> -BUILD_BUG_ON((1UL << FAULT_AROUND_ORDER) > PTRS_PER_PTE);
>> +BUILD_BUG_ON((1UL << CONFIG_FAULT_AROUND_ORDER) > PTRS_PER_PTE);
>>  if (1UL << val > PTRS_PER_PTE)
>>  return -EINVAL;
>>  fault_around_order = val;
>> @@ -3406,14 +3404,14 @@ static inline unsigned long fault_around_pages(void)
>>  {
>>  unsigned long nr_pages;
>>  
>> -nr_pages = 1UL << FAULT_AROUND_ORDER;
>> +nr_pages = 1UL << CONFIG_FAULT_AROUND_ORDER;
>>  BUILD_BUG_ON(nr_pages > PTRS_PER_PTE);
>>  return nr_pages;
>>  }
>>  
>>  static inline unsigned long fault_around_mask(void)
>>  {
>> -return ~((1UL << (PAGE_SHIFT + FAULT_AROUND_ORDER)) - 1);
>> +return ~((1UL << (PAGE_SHIFT + CONFIG_FAULT_AROUND_ORDER)) - 1);
>>  }
>>  #endif
>>  
>> @@ -3471,7 +3469,7 @@ static int do_read_fault(struct mm_struct *mm, struct 
>> vm_area_struct *vma,
>>   * if page by the offset is not ready to be mapped (cold cache or
>>   * something).
>>   */
>> -if (vma->vm_ops->map_pages) {
>> +if ((vma->vm_ops->map_pages) && (fault_around_pages() > 1)) {
> 
>   if (vma->vm_ops->map_pages && fault_around_pages()) {
> 
For a fault around value of 0, fault_around_pages() will return 1 and
that is reason for checking it greater than 1. Also, using debug fs,
fault around value can be zeroed.

With regards
Maddy
>>  pte = pte_offset_map_lock(mm, pmd, address, &ptl);
>>  do_fault_around(vma, address, pte, pgoff, flags);
>>  if (!pte_same(*pte, orig_pte))
>> -- 
>> 1.7.10.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/
> 

--
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 05/15 V3] perf, c2c: Rework setup code to prepare for features

[Namhyung Kim]

On Tue, 8 Apr 2014 10:11:07 -0400, Don Zickus wrote:
> On Tue, Apr 08, 2014 at 04:41:29PM +0900, Namhyung Kim wrote:
>> On Sat, 29 Mar 2014 18:10:18 +0100, Jiri Olsa wrote:
>> > On Mon, Mar 24, 2014 at 03:36:56PM -0400, Don Zickus wrote:
>> >
>> > SNIP
>> >
>> >>  
>> >>  static int perf_c2c__process_load_store(struct perf_c2c *c2c,
>> >> + struct addr_location *al,
>> >>   struct perf_sample *sample,
>> >> - struct addr_location *al)
>> >> + struct perf_evsel *evsel)
>> >>  {
>> >> - if (c2c->raw_records)
>> >> - perf_sample__fprintf(sample, ' ', "raw input", al, stdout);
>> >> + struct mem_info *mi;
>> >> +
>> >> + mi = sample__resolve_mem(sample, al);
>> >> + if (!mi)
>> >> + return -ENOMEM;
>> >
>> > perhaps not directly related to this patchset, but I needed
>> > attached patch to get resolved data in .bss (static), which
>> > for some reason happened to be located in executable segment
>> 
>> Wasn't it a read-only/const data?
>
> I believe it had the 'x' bit set.  Or the kernel was not passing any
> protection bits, so it defaulted to MAP_FUNCTION?

The perf treats a mapping as a data mapping (MAP_VARIABLE) by default if
the 'x' bit is not set.  As Jiri said its a static data, I guessed it's
a const data (set to 0?) and moved into .rodata section and then to the
text segment.

Thanks,
Namhyung
--
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/

Bumping required kernels to 3.0 for Linux backports ?

[Luis R. Rodriguez]

Folks,

we have a age old dance of random parties, in particular the embedded
folks, ending up with random ancient kernels on embedded devices. I've
tried to carefully document a few ideas on why and how I believe we
can make automatic kernel backporting scale [0] and part of this will
be to try to bring consensus about a unified front to persuade users,
partners, customers, whatever, to be at least on a kernel listed as
supported on kernel.org. Today we backport down to the last 30
kernels, from 2.6.24 up to 3.14 and while this is manageable right now
I expect the number of supported drivers and features to keep
increasing (I've stopped counting). I am very aware of the reasons to
support a slew of old kernels, but its nothing but our own fault for
not educating enough about the importance on upgrading. I realize this
is an age old issue, but since I think we need scale backports and
wish to remove older kernels from it fast, I wanted to see if any
folks might have ideas on what can help here other than saying, 'if
you use Linux backports, your drivers will be automatically backported
and supported'.

To start off -- what's the *last* kernel you realistically need for
your users to use backports right now? Is it really 2.6.25? Would
anyone kick and scream if for the backports-3.15 release try take
things up to support only down to least 3.0 *right now* ?

[0] 
http://www.do-not-panic.com/2014/04/automatic-linux-kernel-backporting-with-coccinelle.html

  Luis
--
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 03/15 V3] perf c2c: Shared data analyser

[Namhyung Kim]

On Tue, 8 Apr 2014 10:22:26 -0400, Don Zickus wrote:
> On Tue, Apr 08, 2014 at 03:59:15PM +0900, Namhyung Kim wrote:
>> Hi Don,
>> 
>> On Mon, 24 Mar 2014 15:36:54 -0400, Don Zickus wrote:
>> > From: Arnaldo Carvalho de Melo 
>> >
>> > This is the start of a new perf tool that will collect information about
>> > memory accesses and analyse it to find things like hot cachelines, etc.
>> 
>> So why not integrating this into existing 'perf mem' command if it's all
>> about analyzing memory accesses?
>
> Our expectations were different.  We expeted to do system-wide analysis
> with loads and stores.  With 'perf mem' you didn't have the ability to
> anlayze both load and stores at the same time.

But it's very simple to change perf mem to work with the both IMHO.

>
> In all my private conversations with Stephane, Arnalado and Jiri, it was
> never brought up.  We had just assumed that is made more sense to keep it
> separate.

Well, I'm not sure ;-)  Yes, the c2c is a complex tool which might
deserve an own command, but the functionality is very similar and I
guess there's something to share between them.

Thanks,
Namhyung
--
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 v3 6/6] iio: Added ABI description for quaternion

[Srinivas Pandruvada]

Added documentation for reading quaternion components for 3D rotations.

Signed-off-by: Srinivas Pandruvada 
---
 Documentation/ABI/testing/sysfs-bus-iio | 9 +
 1 file changed, 9 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-bus-iio 
b/Documentation/ABI/testing/sysfs-bus-iio
index 6e02c50..d1cad9a 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio
+++ b/Documentation/ABI/testing/sysfs-bus-iio
@@ -891,3 +891,12 @@ Contact:   linux-...@vger.kernel.org
 Description:
This attribute is used to get/set the integration time in
seconds.
+
+What:  /sys/bus/iio/devices/iio:deviceX/in_rot_quaternion_raw
+KernelVersion: 3.15
+Contact:   linux-...@vger.kernel.org
+Description:
+   Raw value of quaternion components using a format
+   x y z w. Here x, y, and z component represents the axis about
+   which a rotation will occur and w component represents the
+   amount of rotation.
-- 
1.7.11.7

--
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 v3 5/6] iio: hid-sensors: Added device rotation support

[Srinivas Pandruvada]

Added usage id processing for device rotation. This uses IIO
interfaces for triggered buffer to present data to user
mode.This uses HID sensor framework for registering callback
events from the sensor hub.
Data is exported to user space in the form of quaternion rotation
format.

Signed-off-by: Srinivas Pandruvada 
---
 drivers/iio/orientation/Kconfig   |  12 +
 drivers/iio/orientation/Makefile  |   1 +
 drivers/iio/orientation/hid-sensor-rotation.c | 359 ++
 include/linux/hid-sensor-ids.h|   1 +
 4 files changed, 373 insertions(+)
 create mode 100644 drivers/iio/orientation/hid-sensor-rotation.c

diff --git a/drivers/iio/orientation/Kconfig b/drivers/iio/orientation/Kconfig
index 58c62c8..e3aa1e5 100644
--- a/drivers/iio/orientation/Kconfig
+++ b/drivers/iio/orientation/Kconfig
@@ -16,4 +16,16 @@ config HID_SENSOR_INCLINOMETER_3D
  Say yes here to build support for the HID SENSOR
  Inclinometer 3D.
 
+config HID_SENSOR_DEVICE_ROTATION
+   depends on HID_SENSOR_HUB
+   select IIO_BUFFER
+   select IIO_TRIGGERED_BUFFER
+   select HID_SENSOR_IIO_COMMON
+   select HID_SENSOR_IIO_TRIGGER
+   tristate "HID Device Rotation"
+   help
+ Say yes here to build support for the HID SENSOR
+ device rotation. The output of a device rotation sensor
+ is presented using quaternion format.
+
 endmenu
diff --git a/drivers/iio/orientation/Makefile b/drivers/iio/orientation/Makefile
index 2c97572..4734dab 100644
--- a/drivers/iio/orientation/Makefile
+++ b/drivers/iio/orientation/Makefile
@@ -4,3 +4,4 @@
 
 # When adding new entries keep the list in alphabetical order
 obj-$(CONFIG_HID_SENSOR_INCLINOMETER_3D) += hid-sensor-incl-3d.o
+obj-$(CONFIG_HID_SENSOR_DEVICE_ROTATION) += hid-sensor-rotation.o
diff --git a/drivers/iio/orientation/hid-sensor-rotation.c 
b/drivers/iio/orientation/hid-sensor-rotation.c
new file mode 100644
index 000..5c7d558
--- /dev/null
+++ b/drivers/iio/orientation/hid-sensor-rotation.c
@@ -0,0 +1,359 @@
+/*
+ * HID Sensors Driver
+ * Copyright (c) 2014, Intel Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "../common/hid-sensors/hid-sensor-trigger.h"
+
+struct dev_rot_state {
+   struct hid_sensor_hub_callbacks callbacks;
+   struct hid_sensor_common common_attributes;
+   struct hid_sensor_hub_attribute_info quaternion;
+   u32 sampled_vals[4];
+};
+
+/* Channel definitions */
+static const struct iio_chan_spec dev_rot_channels[] = {
+   {
+   .type = IIO_ROT,
+   .modified = 1,
+   .channel2 = IIO_MOD_QUATERNION,
+   .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
+   .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_OFFSET) |
+   BIT(IIO_CHAN_INFO_SAMP_FREQ) |
+   BIT(IIO_CHAN_INFO_HYSTERESIS) |
+   BIT(IIO_CHAN_INFO_RAW),
+   }
+};
+
+/* Adjust channel real bits based on report descriptor */
+static void dev_rot_adjust_channel_bit_mask(struct iio_chan_spec *chan,
+   int size)
+{
+   chan->scan_type.sign = 's';
+   /* Real storage bits will change based on the report desc. */
+   chan->scan_type.realbits = size * 8;
+   /* Maximum size of a sample to capture is u32 */
+   chan->scan_type.storagebits = sizeof(u32) * 8;
+   chan->scan_type.repeat = 4;
+}
+
+/* Channel read_raw handler */
+static int dev_rot_read_raw(struct iio_dev *indio_dev,
+   struct iio_chan_spec const *chan,
+   int size, int *vals, int *val_len,
+   long mask)
+{
+   struct dev_rot_state *rot_state = iio_priv(indio_dev);
+   int ret_type;
+   int i;
+
+   vals[0] = 0;
+   vals[1] = 0;
+
+   switch (mask) {
+   case IIO_CHAN_INFO_RAW:
+   if (size >= 4) {
+   for (i = 0; i < 4; ++i)
+   vals[i] = rot_state->sampled_vals[i];
+   ret_type = IIO_VAL_INT_MULTIPLE;
+   *val_len =  4;
+   } else
+   ret_type = -EINVAL;
+   break;
+   case IIO_CHAN_INFO_SCALE:
+   vals[0] = rot_state->quaternion.units;
+   ret_ty

Re: [Ocfs2-devel] [PATCH 1/1] OCFS2: Remove NULL assignments on static

[Wengang]

Hi Fabian,

What's the badness if we do the assignments?

thanks,
wengang

于 2014年04月09日 04:13, Fabian Frederick 写道:

static values are automatically initialized to NULL.

Cc: Andrew Morton 
Cc: ocfs2-de...@oss.oracle.com
Signed-off-by: Fabian Frederick 
---
  fs/ocfs2/cluster/tcp.c   | 2 +-
  fs/ocfs2/dlm/dlmdebug.c  | 2 +-
  fs/ocfs2/dlm/dlmlock.c   | 2 +-
  fs/ocfs2/dlm/dlmmaster.c | 6 +++---
  fs/ocfs2/stackglue.c | 2 +-
  fs/ocfs2/super.c | 4 ++--
  fs/ocfs2/uptodate.c  | 2 +-
  7 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/fs/ocfs2/cluster/tcp.c b/fs/ocfs2/cluster/tcp.c
index eb649d2..161fb1e 100644
--- a/fs/ocfs2/cluster/tcp.c
+++ b/fs/ocfs2/cluster/tcp.c
@@ -108,7 +108,7 @@ static struct rb_root o2net_handler_tree = RB_ROOT;
  static struct o2net_node o2net_nodes[O2NM_MAX_NODES];
  
  /* XXX someday we'll need better accounting */

-static struct socket *o2net_listen_sock = NULL;
+static struct socket *o2net_listen_sock;
  
  /*

   * listen work is only queued by the listening socket callbacks on the
diff --git a/fs/ocfs2/dlm/dlmdebug.c b/fs/ocfs2/dlm/dlmdebug.c
index e33cd7a..18f13c2 100644
--- a/fs/ocfs2/dlm/dlmdebug.c
+++ b/fs/ocfs2/dlm/dlmdebug.c
@@ -338,7 +338,7 @@ void dlm_print_one_mle(struct dlm_master_list_entry *mle)
  
  #ifdef CONFIG_DEBUG_FS
  
-static struct dentry *dlm_debugfs_root = NULL;

+static struct dentry *dlm_debugfs_root;
  
  #define DLM_DEBUGFS_DIR"o2dlm"

  #define DLM_DEBUGFS_DLM_STATE "dlm_state"
diff --git a/fs/ocfs2/dlm/dlmlock.c b/fs/ocfs2/dlm/dlmlock.c
index 5d32f75..66c2a49 100644
--- a/fs/ocfs2/dlm/dlmlock.c
+++ b/fs/ocfs2/dlm/dlmlock.c
@@ -52,7 +52,7 @@
  #define MLOG_MASK_PREFIX ML_DLM
  #include "cluster/masklog.h"
  
-static struct kmem_cache *dlm_lock_cache = NULL;

+static struct kmem_cache *dlm_lock_cache;
  
  static DEFINE_SPINLOCK(dlm_cookie_lock);

  static u64 dlm_next_cookie = 1;
diff --git a/fs/ocfs2/dlm/dlmmaster.c b/fs/ocfs2/dlm/dlmmaster.c
index af3f7aa..fd07ef9 100644
--- a/fs/ocfs2/dlm/dlmmaster.c
+++ b/fs/ocfs2/dlm/dlmmaster.c
@@ -82,9 +82,9 @@ static inline int dlm_mle_equal(struct dlm_ctxt *dlm,
return 1;
  }
  
-static struct kmem_cache *dlm_lockres_cache = NULL;

-static struct kmem_cache *dlm_lockname_cache = NULL;
-static struct kmem_cache *dlm_mle_cache = NULL;
+static struct kmem_cache *dlm_lockres_cache;
+static struct kmem_cache *dlm_lockname_cache;
+static struct kmem_cache *dlm_mle_cache;
  
  static void dlm_mle_release(struct kref *kref);

  static void dlm_init_mle(struct dlm_master_list_entry *mle,
diff --git a/fs/ocfs2/stackglue.c b/fs/ocfs2/stackglue.c
index 83f1a66..5d965e8 100644
--- a/fs/ocfs2/stackglue.c
+++ b/fs/ocfs2/stackglue.c
@@ -709,7 +709,7 @@ static struct ctl_table ocfs2_root_table[] = {
{ }
  };
  
-static struct ctl_table_header *ocfs2_table_header = NULL;

+static struct ctl_table_header *ocfs2_table_header;
  
  
  /*

diff --git a/fs/ocfs2/super.c b/fs/ocfs2/super.c
index a7cdd56..9027729 100644
--- a/fs/ocfs2/super.c
+++ b/fs/ocfs2/super.c
@@ -75,7 +75,7 @@
  
  #include "buffer_head_io.h"
  
-static struct kmem_cache *ocfs2_inode_cachep = NULL;

+static struct kmem_cache *ocfs2_inode_cachep;
  struct kmem_cache *ocfs2_dquot_cachep;
  struct kmem_cache *ocfs2_qf_chunk_cachep;
  
@@ -85,7 +85,7 @@ struct kmem_cache *ocfs2_qf_chunk_cachep;

   * workqueue and schedule on our own. */
  struct workqueue_struct *ocfs2_wq = NULL;
  
-static struct dentry *ocfs2_debugfs_root = NULL;

+static struct dentry *ocfs2_debugfs_root;
  
  MODULE_AUTHOR("Oracle");

  MODULE_LICENSE("GPL");
diff --git a/fs/ocfs2/uptodate.c b/fs/ocfs2/uptodate.c
index 52eaf33..82e17b0 100644
--- a/fs/ocfs2/uptodate.c
+++ b/fs/ocfs2/uptodate.c
@@ -67,7 +67,7 @@ struct ocfs2_meta_cache_item {
sector_tc_block;
  };
  
-static struct kmem_cache *ocfs2_uptodate_cachep = NULL;

+static struct kmem_cache *ocfs2_uptodate_cachep;
  
  u64 ocfs2_metadata_cache_owner(struct ocfs2_caching_info *ci)

  {


--
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 v3 3/6] IIO: core: Modify scan element type

[Srinivas Pandruvada]

The current scan element type uses the following format:
  [be|le]:[s|u]bits/storagebits[>>shift].
To specify multiple elements in this type, added a repeat value.
So new format is:
  [be|le]:[s|u]bits/storagebits{X[repeat]}[>>shift].
Here X is specifying how may times, real/storage bits are repeating.

When X is value is 0 or 1, then repeat value is not used in the format,
and it will be same as existing format.

Signed-off-by: Srinivas Pandruvada 
---
 drivers/iio/industrialio-buffer.c | 41 +--
 include/linux/iio/iio.h   |  9 +
 2 files changed, 44 insertions(+), 6 deletions(-)

diff --git a/drivers/iio/industrialio-buffer.c 
b/drivers/iio/industrialio-buffer.c
index e108f2a..afc81b5 100644
--- a/drivers/iio/industrialio-buffer.c
+++ b/drivers/iio/industrialio-buffer.c
@@ -150,7 +150,16 @@ static ssize_t iio_show_fixed_type(struct device *dev,
type = IIO_BE;
 #endif
}
-   return sprintf(buf, "%s:%c%d/%d>>%u\n",
+   if (this_attr->c->scan_type.repeat > 1)
+   return sprintf(buf, "%s:%c%d/%d{%d[repeat]}>>%u\n",
+  iio_endian_prefix[type],
+  this_attr->c->scan_type.sign,
+  this_attr->c->scan_type.realbits,
+  this_attr->c->scan_type.storagebits,
+  this_attr->c->scan_type.repeat,
+  this_attr->c->scan_type.shift);
+   else
+   return sprintf(buf, "%s:%c%d/%d>>%u\n",
   iio_endian_prefix[type],
   this_attr->c->scan_type.sign,
   this_attr->c->scan_type.realbits,
@@ -474,14 +483,22 @@ static int iio_compute_scan_bytes(struct iio_dev 
*indio_dev,
for_each_set_bit(i, mask,
 indio_dev->masklength) {
ch = iio_find_channel_from_si(indio_dev, i);
-   length = ch->scan_type.storagebits / 8;
+   if (ch->scan_type.repeat > 1)
+   length = ch->scan_type.storagebits / 8 *
+   ch->scan_type.repeat;
+   else
+   length = ch->scan_type.storagebits / 8;
bytes = ALIGN(bytes, length);
bytes += length;
}
if (timestamp) {
ch = iio_find_channel_from_si(indio_dev,
  indio_dev->scan_index_timestamp);
-   length = ch->scan_type.storagebits / 8;
+   if (ch->scan_type.repeat > 1)
+   length = ch->scan_type.storagebits / 8 *
+   ch->scan_type.repeat;
+   else
+   length = ch->scan_type.storagebits / 8;
bytes = ALIGN(bytes, length);
bytes += length;
}
@@ -957,7 +974,11 @@ static int iio_buffer_update_demux(struct iio_dev 
*indio_dev,
   indio_dev->masklength,
   in_ind + 1);
ch = iio_find_channel_from_si(indio_dev, in_ind);
-   length = ch->scan_type.storagebits/8;
+   if (ch->scan_type.repeat > 1)
+   length = ch->scan_type.storagebits / 8 *
+   ch->scan_type.repeat;
+   else
+   length = ch->scan_type.storagebits / 8;
/* Make sure we are aligned */
in_loc += length;
if (in_loc % length)
@@ -969,7 +990,11 @@ static int iio_buffer_update_demux(struct iio_dev 
*indio_dev,
goto error_clear_mux_table;
}
ch = iio_find_channel_from_si(indio_dev, in_ind);
-   length = ch->scan_type.storagebits/8;
+   if (ch->scan_type.repeat > 1)
+   length = ch->scan_type.storagebits / 8 *
+   ch->scan_type.repeat;
+   else
+   length = ch->scan_type.storagebits / 8;
if (out_loc % length)
out_loc += length - out_loc % length;
if (in_loc % length)
@@ -990,7 +1015,11 @@ static int iio_buffer_update_demux(struct iio_dev 
*indio_dev,
}
ch = iio_find_channel_from_si(indio_dev,
indio_dev->scan_index_timestamp);
-   length = ch->scan_type.storagebits/8;
+   if (ch->scan_type.repeat > 1)
+   length = ch->scan_type.storagebits / 8 *
+   ch->scan_type.repeat;
+   else
+   length = ch->scan_type.storagebits / 8;
if (out_loc % length)
out_loc += length - out_loc % length;
if (in_loc % length)
diff --git a/include/linux/iio/iio.h b

[Patch v3 4/6] IIO: core: Add quaternion modifier

[Srinivas Pandruvada]

Added quaternion in the list of supported modifiers.

Signed-off-by: Srinivas Pandruvada 
---
 drivers/iio/industrialio-core.c | 1 +
 include/linux/iio/types.h   | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index 3bd565c..1d907eb 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -84,6 +84,7 @@ static const char * const iio_modifier_names[] = {
[IIO_MOD_LIGHT_RED] = "red",
[IIO_MOD_LIGHT_GREEN] = "green",
[IIO_MOD_LIGHT_BLUE] = "blue",
+   [IIO_MOD_QUATERNION] = "quaternion",
 };
 
 /* relies on pairs of these shared then separate */
diff --git a/include/linux/iio/types.h b/include/linux/iio/types.h
index a13c224..4fdab2e 100644
--- a/include/linux/iio/types.h
+++ b/include/linux/iio/types.h
@@ -53,6 +53,7 @@ enum iio_modifier {
IIO_MOD_LIGHT_RED,
IIO_MOD_LIGHT_GREEN,
IIO_MOD_LIGHT_BLUE,
+   IIO_MOD_QUATERNION,
 };
 
 enum iio_event_type {
-- 
1.7.11.7

--
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 v3 1/6] devres: introduce API "devm_kmemdup

[Srinivas Pandruvada]

Introduce devm_kmemdup, which uses resource managed kmalloc.
There are several request from maintainers to add this instead
of using kmemdup.

Signed-off-by: Srinivas Pandruvada 
---
 Documentation/driver-model/devres.txt |  1 +
 drivers/base/devres.c | 21 +
 include/linux/device.h|  2 ++
 3 files changed, 24 insertions(+)

diff --git a/Documentation/driver-model/devres.txt 
b/Documentation/driver-model/devres.txt
index 4f7897e..4999518 100644
--- a/Documentation/driver-model/devres.txt
+++ b/Documentation/driver-model/devres.txt
@@ -236,6 +236,7 @@ certainly invest a bit more effort into libata core layer).
 MEM
   devm_kzalloc()
   devm_kfree()
+  devm_kmemdup()
 
 IIO
   devm_iio_device_alloc()
diff --git a/drivers/base/devres.c b/drivers/base/devres.c
index db4e264..d0914cb 100644
--- a/drivers/base/devres.c
+++ b/drivers/base/devres.c
@@ -831,3 +831,24 @@ void devm_kfree(struct device *dev, void *p)
WARN_ON(rc);
 }
 EXPORT_SYMBOL_GPL(devm_kfree);
+
+/**
+ * devm_kmemdup - Resource-managed kmemdup
+ * @dev: Device this memory belongs to
+ * @src: Memory region to duplicate
+ * @len: Memory region length
+ * @gfp: GFP mask to use
+ *
+ * Duplicate region of a memory using resource managed kmalloc
+ */
+void *devm_kmemdup(struct device *dev, const void *src, size_t len, gfp_t gfp)
+{
+   void *p;
+
+   p = devm_kmalloc(dev, len, gfp);
+   if (p)
+   memcpy(p, src, len);
+
+   return p;
+}
+EXPORT_SYMBOL_GPL(devm_kmemdup);
diff --git a/include/linux/device.h b/include/linux/device.h
index 233bbbe..0b3117a 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -629,6 +629,8 @@ static inline void *devm_kcalloc(struct device *dev,
 }
 extern void devm_kfree(struct device *dev, void *p);
 extern char *devm_kstrdup(struct device *dev, const char *s, gfp_t gfp);
+extern void *devm_kmemdup(struct device *dev, const void *src, size_t len,
+   gfp_t gfp);
 
 void __iomem *devm_ioremap_resource(struct device *dev, struct resource *res);
 void __iomem *devm_request_and_ioremap(struct device *dev,
-- 
1.7.11.7

--
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 v3 2/6] IIO: core: Introduce read_raw_multi

[Srinivas Pandruvada]

This callback is introduced to overcome some limitations of existing
read_raw callback. The functionality of both existing read_raw and
read_raw_multi is similar, both are used to request values from the
device. The current read_raw callback allows only two return values.
The new read_raw_multi allows returning multiple values. Instead of
passing just address of val and val2, it passes length and pointer
to values. Depending on the type and length of passed buffer, iio
client drivers can return multiple values.

Signed-off-by: Srinivas Pandruvada 
---
 drivers/iio/iio_core.h   |  2 +-
 drivers/iio/industrialio-core.c  | 65 ++--
 drivers/iio/industrialio-event.c |  6 ++--
 drivers/iio/inkern.c | 16 --
 include/linux/iio/iio.h  | 17 +++
 include/linux/iio/types.h|  1 +
 6 files changed, 80 insertions(+), 27 deletions(-)

diff --git a/drivers/iio/iio_core.h b/drivers/iio/iio_core.h
index f6db6af..30327ad 100644
--- a/drivers/iio/iio_core.h
+++ b/drivers/iio/iio_core.h
@@ -35,7 +35,7 @@ int __iio_add_chan_devattr(const char *postfix,
   struct list_head *attr_list);
 void iio_free_chan_devattr_list(struct list_head *attr_list);
 
-ssize_t iio_format_value(char *buf, unsigned int type, int val, int val2);
+ssize_t iio_format_value(char *buf, unsigned int type, int size, int *val);
 
 /* Event interface flags */
 #define IIO_BUSY_BIT_POS 1
diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index ede16aec..3bd565c 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -373,41 +373,53 @@ EXPORT_SYMBOL_GPL(iio_enum_write);
  * @buf: The buffer to which the formated value gets written
  * @type: One of the IIO_VAL_... constants. This decides how the val and val2
  *parameters are formatted.
- * @val: First part of the value, exact meaning depends on the type parameter.
- * @val2: Second part of the value, exact meaning depends on the type 
parameter.
+ * @vals: pointer to the values, exact meaning depends on the type parameter.
  */
-ssize_t iio_format_value(char *buf, unsigned int type, int val, int val2)
+ssize_t iio_format_value(char *buf, unsigned int type, int size, int *vals)
 {
unsigned long long tmp;
bool scale_db = false;
 
switch (type) {
case IIO_VAL_INT:
-   return sprintf(buf, "%d\n", val);
+   return sprintf(buf, "%d\n", vals[0]);
case IIO_VAL_INT_PLUS_MICRO_DB:
scale_db = true;
case IIO_VAL_INT_PLUS_MICRO:
-   if (val2 < 0)
-   return sprintf(buf, "-%ld.%06u%s\n", abs(val), -val2,
+   if (vals[1] < 0)
+   return sprintf(buf, "-%ld.%06u%s\n", abs(vals[0]),
+   -vals[1],
scale_db ? " dB" : "");
else
-   return sprintf(buf, "%d.%06u%s\n", val, val2,
+   return sprintf(buf, "%d.%06u%s\n", vals[0], vals[1],
scale_db ? " dB" : "");
case IIO_VAL_INT_PLUS_NANO:
-   if (val2 < 0)
-   return sprintf(buf, "-%ld.%09u\n", abs(val), -val2);
+   if (vals[1] < 0)
+   return sprintf(buf, "-%ld.%09u\n", abs(vals[0]),
+   -vals[1]);
else
-   return sprintf(buf, "%d.%09u\n", val, val2);
+   return sprintf(buf, "%d.%09u\n", vals[0], vals[1]);
case IIO_VAL_FRACTIONAL:
-   tmp = div_s64((s64)val * 10LL, val2);
-   val2 = do_div(tmp, 10LL);
-   val = tmp;
-   return sprintf(buf, "%d.%09u\n", val, val2);
+   tmp = div_s64((s64)vals[0] * 10LL, vals[1]);
+   vals[1] = do_div(tmp, 10LL);
+   vals[0] = tmp;
+   return sprintf(buf, "%d.%09u\n", vals[0], vals[1]);
case IIO_VAL_FRACTIONAL_LOG2:
-   tmp = (s64)val * 10LL >> val2;
-   val2 = do_div(tmp, 10LL);
-   val = tmp;
-   return sprintf(buf, "%d.%09u\n", val, val2);
+   tmp = (s64)vals[0] * 10LL >> vals[1];
+   vals[1] = do_div(tmp, 10LL);
+   vals[0] = tmp;
+   return sprintf(buf, "%d.%09u\n", vals[0], vals[1]);
+   case IIO_VAL_INT_MULTIPLE:
+   {
+   int i;
+   int len = 0;
+
+   for (i = 0; i < size; ++i)
+   len += sprintf(&buf[len], "%d ", vals[i]);
+   buf[len++] = '\n';
+   buf[len++] = '\0';
+   return len;
+   }
default:
return 0;
}
@@ -419,14 +431,23 @@ static ssize_t iio_read_channel_info(struct device *dev,
 {
struct i

[PATCH 2/2] Drivers: hv: vmbus: Implement per-CPU mapping of relid to channel

[K. Y. Srinivasan]

Currently the mapping of the relID to channel is done under the protection of a
single spin lock. Starting with ws2012, each channel is bound to a specific VCPU
in the guest. Use this binding to eliminate the spin lock by setting up
per-cpu state for mapping relId to the channel.

Signed-off-by: K. Y. Srinivasan 
Reviewed-by: Haiyang Zhang 
---
 drivers/hv/channel_mgmt.c |   41 -
 drivers/hv/connection.c   |   24 +++-
 drivers/hv/hv.c   |2 ++
 drivers/hv/hyperv_vmbus.h |5 +
 include/linux/hyperv.h|5 +
 5 files changed, 75 insertions(+), 2 deletions(-)

diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
index 6f7fdd9..6c8b032c 100644
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -149,6 +149,7 @@ static struct vmbus_channel *alloc_channel(void)
spin_lock_init(&channel->sc_lock);
 
INIT_LIST_HEAD(&channel->sc_list);
+   INIT_LIST_HEAD(&channel->percpu_list);
 
channel->controlwq = create_workqueue("hv_vmbus_ctl");
if (!channel->controlwq) {
@@ -188,7 +189,20 @@ static void free_channel(struct vmbus_channel *channel)
queue_work(vmbus_connection.work_queue, &channel->work);
 }
 
+static void percpu_channel_enq(void *arg)
+{
+   struct vmbus_channel *channel = arg;
+   int cpu = smp_processor_id();
+
+   list_add_tail(&channel->percpu_list, &hv_context.percpu_list[cpu]);
+}
 
+static void percpu_channel_deq(void *arg)
+{
+   struct vmbus_channel *channel = arg;
+
+   list_del(&channel->percpu_list);
+}
 
 /*
  * vmbus_process_rescind_offer -
@@ -210,6 +224,12 @@ static void vmbus_process_rescind_offer(struct work_struct 
*work)
msg.header.msgtype = CHANNELMSG_RELID_RELEASED;
vmbus_post_msg(&msg, sizeof(struct vmbus_channel_relid_released));
 
+   if (channel->target_cpu != smp_processor_id())
+   smp_call_function_single(channel->target_cpu,
+percpu_channel_deq, channel, true);
+   else
+   percpu_channel_deq(channel);
+
if (channel->primary_channel == NULL) {
spin_lock_irqsave(&vmbus_connection.channel_lock, flags);
list_del(&channel->listentry);
@@ -245,6 +265,7 @@ static void vmbus_process_offer(struct work_struct *work)
work);
struct vmbus_channel *channel;
bool fnew = true;
+   bool enq = false;
int ret;
unsigned long flags;
 
@@ -264,12 +285,22 @@ static void vmbus_process_offer(struct work_struct *work)
}
}
 
-   if (fnew)
+   if (fnew) {
list_add_tail(&newchannel->listentry,
  &vmbus_connection.chn_list);
+   enq = true;
+   }
 
spin_unlock_irqrestore(&vmbus_connection.channel_lock, flags);
 
+   if (enq) {
+   if (newchannel->target_cpu != smp_processor_id())
+   smp_call_function_single(newchannel->target_cpu,
+percpu_channel_enq,
+newchannel, true);
+   else
+   percpu_channel_enq(newchannel);
+   }
if (!fnew) {
/*
 * Check to see if this is a sub-channel.
@@ -282,6 +313,14 @@ static void vmbus_process_offer(struct work_struct *work)
spin_lock_irqsave(&channel->sc_lock, flags);
list_add_tail(&newchannel->sc_list, &channel->sc_list);
spin_unlock_irqrestore(&channel->sc_lock, flags);
+
+   if (newchannel->target_cpu != smp_processor_id())
+   smp_call_function_single(newchannel->target_cpu,
+percpu_channel_enq,
+newchannel, true);
+   else
+   percpu_channel_enq(newchannel);
+
newchannel->state = CHANNEL_OPEN_STATE;
if (channel->sc_creation_callback != NULL)
channel->sc_creation_callback(newchannel);
diff --git a/drivers/hv/connection.c b/drivers/hv/connection.c
index d484bad..3589236 100644
--- a/drivers/hv/connection.c
+++ b/drivers/hv/connection.c
@@ -231,6 +231,28 @@ cleanup:
return ret;
 }
 
+/*
+ * Map the given relid to the corresponding channel based on the
+ * per-cpu list of channels that have been affinitized to this CPU.
+ * This will be used in the channel callback path as we can do this
+ * mapping in a lock-free fashion.
+ */
+static struct vmbus_channel *pcpu_relid2channel(u32 relid)
+{
+   struct vmbus_channel *channel;
+   struct vmbus_channel *found_channel  = NULL;
+   int cpu = smp_processor_id();
+