Re: [PATCH] memcg: stop warning on memcg_propagate_kmem

[Michal Hocko]

On Sun 03-02-13 20:29:01, Hugh Dickins wrote:
> Whilst I run the risk of a flogging for disloyalty to the Lord of Sealand,
> I do have CONFIG_MEMCG=y CONFIG_MEMCG_KMEM not set, and grow tired of the
> "mm/memcontrol.c:4972:12: warning: `memcg_propagate_kmem' defined but not
> used [-Wunused-function]" seen in 3.8-rc: move the #ifdef outwards.
> 
> Signed-off-by: Hugh Dickins 

Acked-by: Michal Hocko 

Hmm, if you are not too tired then moving the function downwards to
where it is called (memcg_init_kmem) will reduce the number of ifdefs.
But this can wait for a bigger clean up which is getting due:
git grep "def.*CONFIG_MEMCG_KMEM" mm/memcontrol.c | wc -l
12

Thanks
> ---
> 
>  mm/memcontrol.c |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> --- 3.8-rc6/mm/memcontrol.c   2012-12-22 09:43:27.628015582 -0800
> +++ linux/mm/memcontrol.c 2013-02-02 16:56:06.188325771 -0800
> @@ -4969,6 +4969,7 @@ out:
>   return ret;
>  }
>  
> +#ifdef CONFIG_MEMCG_KMEM
>  static int memcg_propagate_kmem(struct mem_cgroup *memcg)
>  {
>   int ret = 0;
> @@ -4977,7 +4978,6 @@ static int memcg_propagate_kmem(struct m
>   goto out;
>  
>   memcg->kmem_account_flags = parent->kmem_account_flags;
> -#ifdef CONFIG_MEMCG_KMEM
>   /*
>* When that happen, we need to disable the static branch only on those
>* memcgs that enabled it. To achieve this, we would be forced to
> @@ -5003,10 +5003,10 @@ static int memcg_propagate_kmem(struct m
>   mutex_lock(_limit_mutex);
>   ret = memcg_update_cache_sizes(memcg);
>   mutex_unlock(_limit_mutex);
> -#endif
>  out:
>   return ret;
>  }
> +#endif /* CONFIG_MEMCG_KMEM */
>  
>  /*
>   * The user of this function is...

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

[PATCH 3/3] mfd: rtsx: support RTS5227

[Roger Tseng]

Support new model RTS5227.

Signed-off-by: Roger Tseng 
Reviewed-by: Wei WANG 
---
 drivers/mfd/Makefile |   2 +-
 drivers/mfd/rts5227.c| 234 +++
 drivers/mfd/rtsx_pcr.c   |   5 +
 drivers/mfd/rtsx_pcr.h   |   1 +
 include/linux/mfd/rtsx_pci.h |   5 +
 5 files changed, 246 insertions(+), 1 deletion(-)
 create mode 100644 drivers/mfd/rts5227.c

diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 8b977f8..b90409c 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -9,7 +9,7 @@ obj-$(CONFIG_MFD_88PM805)   += 88pm805.o 88pm80x.o
 obj-$(CONFIG_MFD_SM501)+= sm501.o
 obj-$(CONFIG_MFD_ASIC3)+= asic3.o tmio_core.o
 
-rtsx_pci-objs  := rtsx_pcr.o rts5209.o rts5229.o rtl8411.o
+rtsx_pci-objs  := rtsx_pcr.o rts5209.o rts5229.o rtl8411.o 
rts5227.o
 obj-$(CONFIG_MFD_RTSX_PCI) += rtsx_pci.o
 
 obj-$(CONFIG_HTC_EGPIO)+= htc-egpio.o
diff --git a/drivers/mfd/rts5227.c b/drivers/mfd/rts5227.c
new file mode 100644
index 000..fc831dc
--- /dev/null
+++ b/drivers/mfd/rts5227.c
@@ -0,0 +1,234 @@
+/* Driver for Realtek PCI-Express card reader
+ *
+ * Copyright(c) 2009 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 as published by the
+ * Free Software Foundation; either version 2, 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 .
+ *
+ * Author:
+ *   Wei WANG 
+ *   No. 450, Shenhu Road, Suzhou Industry Park, Suzhou, China
+ *
+ *   Roger Tseng 
+ *   No. 2, Innovation Road II, Hsinchu Science Park, Hsinchu 300, Taiwan
+ */
+
+#include 
+#include 
+#include 
+
+#include "rtsx_pcr.h"
+
+static int rts5227_extra_init_hw(struct rtsx_pcr *pcr)
+{
+   u16 cap;
+
+   rtsx_pci_init_cmd(pcr);
+
+   /* Configure GPIO as output */
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, GPIO_CTL, 0x02, 0x02);
+   /* Switch LDO3318 source from DV33 to card_3v3 */
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, LDO_PWR_SEL, 0x03, 0x00);
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, LDO_PWR_SEL, 0x03, 0x01);
+   /* LED shine disabled, set initial shine cycle period */
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, OLT_LED_CTL, 0x0F, 0x02);
+   /* Configure LTR */
+   pcie_capability_read_word(pcr->pci, PCI_EXP_DEVCTL2, );
+   if (cap & PCI_EXP_LTR_EN)
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, LTR_CTL, 0xFF, 0xA3);
+   /* Configure OBFF */
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, OBFF_CFG, 0x03, 0x03);
+   /* Configure force_clock_req
+* Maybe We should define 0xFF03 as some name
+*/
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, 0xFF03, 0x08, 0x08);
+   /* Correct driving */
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD,
+   SD30_CLK_DRIVE_SEL, 0xFF, 0x96);
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD,
+   SD30_CMD_DRIVE_SEL, 0xFF, 0x96);
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD,
+   SD30_DAT_DRIVE_SEL, 0xFF, 0x96);
+
+   return rtsx_pci_send_cmd(pcr, 100);
+}
+
+static int rts5227_optimize_phy(struct rtsx_pcr *pcr)
+{
+   /* Optimize RX sensitivity */
+   return rtsx_pci_write_phy_register(pcr, 0x00, 0xBA42);
+}
+
+static int rts5227_turn_on_led(struct rtsx_pcr *pcr)
+{
+   return rtsx_pci_write_register(pcr, GPIO_CTL, 0x02, 0x02);
+}
+
+static int rts5227_turn_off_led(struct rtsx_pcr *pcr)
+{
+   return rtsx_pci_write_register(pcr, GPIO_CTL, 0x02, 0x00);
+}
+
+static int rts5227_enable_auto_blink(struct rtsx_pcr *pcr)
+{
+   return rtsx_pci_write_register(pcr, OLT_LED_CTL, 0x08, 0x08);
+}
+
+static int rts5227_disable_auto_blink(struct rtsx_pcr *pcr)
+{
+   return rtsx_pci_write_register(pcr, OLT_LED_CTL, 0x08, 0x00);
+}
+
+static int rts5227_card_power_on(struct rtsx_pcr *pcr, int card)
+{
+   int err;
+
+   rtsx_pci_init_cmd(pcr);
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, CARD_PWR_CTL,
+   SD_POWER_MASK, SD_PARTIAL_POWER_ON);
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PWR_GATE_CTRL,
+   LDO3318_PWR_MASK, 0x02);
+   err = rtsx_pci_send_cmd(pcr, 100);
+   if (err < 0)
+   return err;
+
+   /* To avoid too large in-rush current */
+   udelay(150);
+
+   rtsx_pci_init_cmd(pcr);
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, CARD_PWR_CTL,
+   SD_POWER_MASK, SD_POWER_ON);
+   rtsx_pci_add_cmd(pcr, 

[PATCH 2/3] mfd: rtsx: implement driving adjustment to device-dependent callbacks

[Roger Tseng]

Implement different ways of selecting driving capability(a necessary adjustment
along with voltage change). It was origionally in device-independent
mmc/host/rtsx_pci_sdmmc.c. Moving it here to support devices which may have a
different way of adjustment.

Signed-off-by: Roger Tseng 
Reviewed-by: Wei WANG 
---
 drivers/mfd/rtl8411.c | 16 +---
 drivers/mfd/rts5209.c |  8 
 drivers/mfd/rts5229.c |  8 
 3 files changed, 29 insertions(+), 3 deletions(-)

diff --git a/drivers/mfd/rtl8411.c b/drivers/mfd/rtl8411.c
index 3d3b4ad..2a2d316 100644
--- a/drivers/mfd/rtl8411.c
+++ b/drivers/mfd/rtl8411.c
@@ -115,14 +115,24 @@ static int rtl8411_card_power_off(struct rtsx_pcr *pcr, 
int card)
 static int rtl8411_switch_output_voltage(struct rtsx_pcr *pcr, u8 voltage)
 {
u8 mask, val;
+   int err;
 
mask = (BPP_REG_TUNED18 << BPP_TUNED18_SHIFT_8411) | BPP_PAD_MASK;
-   if (voltage == OUTPUT_3V3)
+   if (voltage == OUTPUT_3V3) {
+   err = rtsx_pci_write_register(pcr,
+   SD30_DRIVE_SEL, 0x07, DRIVER_TYPE_D);
+   if (err < 0)
+   return err;
val = (BPP_ASIC_3V3 << BPP_TUNED18_SHIFT_8411) | BPP_PAD_3V3;
-   else if (voltage == OUTPUT_1V8)
+   } else if (voltage == OUTPUT_1V8) {
+   err = rtsx_pci_write_register(pcr,
+   SD30_DRIVE_SEL, 0x07, DRIVER_TYPE_B);
+   if (err < 0)
+   return err;
val = (BPP_ASIC_1V8 << BPP_TUNED18_SHIFT_8411) | BPP_PAD_1V8;
-   else
+   } else {
return -EINVAL;
+   }
 
return rtsx_pci_write_register(pcr, LDO_CTL, mask, val);
 }
diff --git a/drivers/mfd/rts5209.c b/drivers/mfd/rts5209.c
index 98fe0f3..ec78d9f 100644
--- a/drivers/mfd/rts5209.c
+++ b/drivers/mfd/rts5209.c
@@ -149,10 +149,18 @@ static int rts5209_switch_output_voltage(struct rtsx_pcr 
*pcr, u8 voltage)
int err;
 
if (voltage == OUTPUT_3V3) {
+   err = rtsx_pci_write_register(pcr,
+   SD30_DRIVE_SEL, 0x07, DRIVER_TYPE_D);
+   if (err < 0)
+   return err;
err = rtsx_pci_write_phy_register(pcr, 0x08, 0x4FC0 | 0x24);
if (err < 0)
return err;
} else if (voltage == OUTPUT_1V8) {
+   err = rtsx_pci_write_register(pcr,
+   SD30_DRIVE_SEL, 0x07, DRIVER_TYPE_B);
+   if (err < 0)
+   return err;
err = rtsx_pci_write_phy_register(pcr, 0x08, 0x4C40 | 0x24);
if (err < 0)
return err;
diff --git a/drivers/mfd/rts5229.c b/drivers/mfd/rts5229.c
index 29d889c..58af4db 100644
--- a/drivers/mfd/rts5229.c
+++ b/drivers/mfd/rts5229.c
@@ -119,10 +119,18 @@ static int rts5229_switch_output_voltage(struct rtsx_pcr 
*pcr, u8 voltage)
int err;
 
if (voltage == OUTPUT_3V3) {
+   err = rtsx_pci_write_register(pcr,
+   SD30_DRIVE_SEL, 0x07, DRIVER_TYPE_D);
+   if (err < 0)
+   return err;
err = rtsx_pci_write_phy_register(pcr, 0x08, 0x4FC0 | 0x24);
if (err < 0)
return err;
} else if (voltage == OUTPUT_1V8) {
+   err = rtsx_pci_write_register(pcr,
+   SD30_DRIVE_SEL, 0x07, DRIVER_TYPE_B);
+   if (err < 0)
+   return err;
err = rtsx_pci_write_phy_register(pcr, 0x08, 0x4C40 | 0x24);
if (err < 0)
return err;
-- 
1.7.12.1

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

[PATCH 0/3] rtsx: patchset for supporting new model RTS5227

[Roger Tseng]

The patchset makes necessary changes in mfd and mmc tree for supporting RTS5227
card reader.

Roger Tseng (3):
  MMC: rtsx: remove driving adjustment
  mfd: rtsx: implement driving adjustment to device-dependent callbacks
  mfd: rtsx: support RTS5227

 drivers/mfd/Makefile  |   2 +-
 drivers/mfd/rtl8411.c |  16 ++-
 drivers/mfd/rts5209.c |   8 ++
 drivers/mfd/rts5227.c | 234 ++
 drivers/mfd/rts5229.c |   8 ++
 drivers/mfd/rtsx_pcr.c|   5 +
 drivers/mfd/rtsx_pcr.h|   1 +
 drivers/mmc/host/rtsx_pci_sdmmc.c |   5 -
 include/linux/mfd/rtsx_pci.h  |   5 +
 9 files changed, 275 insertions(+), 9 deletions(-)
 create mode 100644 drivers/mfd/rts5227.c

-- 
1.7.12.1

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

[PATCH 1/3] MMC: rtsx: remove driving adjustment

[Roger Tseng]

Several new models of readers use different way to select driving
capability(a necessary adjustment along with voltage change). Removing this
from device-independent rtsx_pci_sdmmc module. It will be implemented in
device-depend calls encapsulated by rtsx_pci_switch_output_voltage().

Signed-off-by: Roger Tseng 
Reviewed-by: Wei WANG 
---
 drivers/mmc/host/rtsx_pci_sdmmc.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/mmc/host/rtsx_pci_sdmmc.c 
b/drivers/mmc/host/rtsx_pci_sdmmc.c
index f74b5ad..f93f100 100644
--- a/drivers/mmc/host/rtsx_pci_sdmmc.c
+++ b/drivers/mmc/host/rtsx_pci_sdmmc.c
@@ -1083,11 +1083,6 @@ static int sdmmc_switch_voltage(struct mmc_host *mmc, 
struct mmc_ios *ios)
voltage = OUTPUT_1V8;
 
if (voltage == OUTPUT_1V8) {
-   err = rtsx_pci_write_register(pcr,
-   SD30_DRIVE_SEL, 0x07, DRIVER_TYPE_B);
-   if (err < 0)
-   goto out;
-
err = sd_wait_voltage_stable_1(host);
if (err < 0)
goto out;
-- 
1.7.12.1

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

Re: [PATCH V7] kbuild: create a rule to run the pre-processor on *.dts files

[Srinivas KANDAGATLA]

On 01/02/13 19:25, Stephen Warren wrote:
> On 02/01/2013 10:27 AM, Stephen Warren wrote:
>> On 02/01/2013 09:51 AM, Rob Herring wrote:
>>> On 02/01/2013 03:01 AM, Srinivas KANDAGATLA wrote:
 Hi Stephen,
 Not sure if you have already noticed this but,
 I did try this patch on my 3.8, and it looks like the intermediate dts
 file replaces all instances of linux with 1 because of predefined macros
 in gcc.
 As a result
 linux,stdout-path = "/soc/stm-asc2";
 is changed to.
 1,stdout-path = "/soc/stm-asc2";

 On my version of compiler(gcc version 4.6.3) I have

 armv7-linux-gcc -E -dM - < /dev/null | grep -v _
 #define unix 1
 #define linux 1

 Which might be true with most compiler versions aswell.
 As we are using linux as prefix for some device tree properties it makes
 sense to undef the linux gcc define.
 Adding -Ulinux to cmd_dtc_cpp should fix it.

 -cmd_dtc_cpp = $(CPP) $(cpp_flags) -D__DTS__ -x assembler-with-cpp -o
 $(dtc-tmp) $< ; \
 +cmd_dtc_cpp = $(CPP) $(cpp_flags) -D__DTS__  -Ulinux -x
 assembler-with-cpp -o $(dtc-tmp) $< ; \
 $(objtree)/scripts/dtc/dtc -O dtb -o $@ -b 0 $(DTC_FLAGS) $(dtc-tmp)
>>> That's a hackish solution that seems fragile as well. Is there no way to
>>> turn off all built-in defines?
>> I'm pretty sure there is; I'll go find it.
> Hmmm. I can't actually find one.
There is another option(-undef) to turn of system-specific options and
keep standard macros like __ASSEMBLER__

|-undef||(|Do not predefine any system-specific or GCC-specific macros.
The standard predefined macros remain defined.
(http://gcc.gnu.org/onlinedocs/cpp/Standard-Predefined-Macros.html#Standard-Predefined-Macros))
This option also worked for me.

--srini

>
>> But we do want to keep some of the built-in defines. for example, -x
>> assembler-with-cpp turns on __ASSEMBLY__ or similar, which headers can
>> use to determine whether to only set up #defines, or also C-oriented
>> stuff like types/prototypes. So, at least that one would need to be
>> explicitly re-defined.
> I grep'd through the kernel's include/ and there are quite a few hits
> for some of the pre-define macros such as __linux__, __GNUC__,
> __STRICT_ANSI__, __KERNEL__, __arm__ (and presumably other arch macros),
> etc. I'd guess that an explicit blacklisting of -Dlinux and -Dunix might
> be the most manageable path. Thoughts?
> ___
> devicetree-discuss mailing list
> devicetree-disc...@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
>
>

--
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: Tree for Feb 4

[Stephen Rothwell]

Hi all,

Changes since 20130202:

The powerpc tree still had a build failure.

The nfsd tree still had its build failure so I used the version from
next-20130128.

The security tree gained a conflict against Linus' tree.

The tip tree lost its build failure.

The xen-two tree gained a build failure for which I applied a merge fix
patch.

The driver-core tree gained conflicts against the net-next tree.

The char-misc tree gained a conflict against the mfd tree.

The pinctrl tree gained a conflict against the battery tree.

The arm-soc tree gained a conflict against the mfd tree.

The signal tree gained a conflict against the mips tree.

The akpm tree gained a conflict against the tip tree and a build failure
for which I applied a merge fix patch.



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" as mentioned in the FAQ on the wiki
(see below).

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log files
in the Next directory.  Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the
final fixups (if any), it is also built with powerpc allnoconfig (32 and
64 bit), ppc44x_defconfig and allyesconfig (minus
CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc,
sparc64 and arm defconfig. These builds also have
CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and
CONFIG_DEBUG_INFO disabled when necessary.

Below is a summary of the state of the merge.

We are up to 213 trees (counting Linus' and 28 trees of patches pending
for Linus' tree), more are welcome (even if they are currently empty).
Thanks to those who have contributed, and to those who haven't, please do.

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ .  Thanks to Frank Seidel
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

$ git checkout master
$ git reset --hard stable
Merging origin/master (8b31849 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending)
Merging fixes/master (d287b87 Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs)
Merging kbuild-current/rc-fixes (02f3e53 Merge branch 'yem-kconfig-rc-fixes' of 
git://gitorious.org/linux-kconfig/linux-kconfig into kbuild/rc-fixes)
Merging arm-current/fixes (58b9f3b ARM: DMA mapping: fix bad atomic test)
Merging m68k-current/for-linus (91a420e xtensa: Provide dummy 
dma_mmap_coherent() and dma_get_sgtable())
Merging powerpc-merge/merge (689dfa8 powerpc: Max next_tb to prevent from 
replaying timer interrupt)
Merging sparc/master (04cef49 sparc: kernel/sbus.c: fix memory leakage)
Merging net/master (9665d5d packet: fix leakage of tx_ring memory)
Merging ipsec/master (6642f91 dm9601: support dm9620 variant)
Merging sound-current/for-linus (8058e14 Merge branch 'usb-audio-fix' of 
git://git.alsa-project.org/alsa-kprivate into for-linus)
Merging pci-current/for-linus (444ee9b PCI: remove depends on 
CONFIG_EXPERIMENTAL)
Merging wireless/master (8a7d7cb mwifiex: fix incomplete scan in case of IE 
parsing error)
Merging driver-core.current/driver-core-linus (7d1f9ae Linux 3.8-rc4)
Merging tty.current/tty-linus (949db15 Linux 3.8-rc5)
Merging usb.current/usb-linus (0ba3b2c USB: ftdi_sio: add Zolix FTDI PID)
Merging staging.current/staging-linus (949db15 Linux 3.8-rc5)
Merging char-misc.current/char-misc-linus (949db15 Linux 3.8-rc5)
Merging input-current/for-linus (9937c02 Input: wacom - fix wacom_set_report 
retry logic)
Merging md-current/for-linus (55ebbb5 DM-RAID: Fix RAID10's check for 
sufficient redundancy)
Merging audit-current/for-linus (c158a35 audit: no leading space in 
audit_log_d_path prefix)
Merging crypto-current/master (a2c0911 crypto: caam - Updated SEC-4.0 device 
tree binding for ERA information.)
Merging ide/master (9974e43 ide: fix generic_ide_suspend/resume Oops)
Merging dwmw2/master (084a0ec x86: add CONFIG_X86_MOVBE option)
CONFLICT (content): Merge conflict in arch/x86/Kconfig
Merging sh-current/sh-fixes-for-linus (4403310 SH: Convert out[bwl] macros to 
inline functions)
Merging irqdomain-current/irqdomain/merge (a0d271c Linux 3.6)
Merging devicetree-current/devicetree/merge (ab28698 of: define struct 

Re: [PATCH v7 4/4] zram: get rid of lockdep warning

[Ric Mason]

On Mon, 2013-02-04 at 08:46 +0900, Minchan Kim wrote:
> Lockdep complains about recursive deadlock of zram->init_lock.
> [1] made it false positive because we can't request IO to zram
> before setting disksize. Anyway, we should shut lockdep up to
> avoid many reporting from user.
> 
> [1] : zram: force disksize setting before using zram
> 
> Acked-by: Jerome Marchand 
> Signed-off-by: Minchan Kim 
> ---
>  drivers/staging/zram/zram_drv.c   |  189 
> +++--
>  drivers/staging/zram/zram_drv.h   |   12 ++-
>  drivers/staging/zram/zram_sysfs.c |   11 ++-
>  3 files changed, 116 insertions(+), 96 deletions(-)
> 
> diff --git a/drivers/staging/zram/zram_drv.c b/drivers/staging/zram/zram_drv.c
> index 85055c4..56e3203 100644
> --- a/drivers/staging/zram/zram_drv.c
> +++ b/drivers/staging/zram/zram_drv.c
> @@ -61,22 +61,22 @@ static void zram_stat64_inc(struct zram *zram, u64 *v)
>   zram_stat64_add(zram, v, 1);
>  }
>  
> -static int zram_test_flag(struct zram *zram, u32 index,
> +static int zram_test_flag(struct zram_meta *meta, u32 index,
>   enum zram_pageflags flag)
>  {
> - return zram->table[index].flags & BIT(flag);
> + return meta->table[index].flags & BIT(flag);
>  }
>  
> -static void zram_set_flag(struct zram *zram, u32 index,
> +static void zram_set_flag(struct zram_meta *meta, u32 index,
>   enum zram_pageflags flag)
>  {
> - zram->table[index].flags |= BIT(flag);
> + meta->table[index].flags |= BIT(flag);
>  }
>  
> -static void zram_clear_flag(struct zram *zram, u32 index,
> +static void zram_clear_flag(struct zram_meta *meta, u32 index,
>   enum zram_pageflags flag)
>  {
> - zram->table[index].flags &= ~BIT(flag);
> + meta->table[index].flags &= ~BIT(flag);
>  }
>  
>  static int page_zero_filled(void *ptr)
> @@ -96,16 +96,17 @@ static int page_zero_filled(void *ptr)
>  
>  static void zram_free_page(struct zram *zram, size_t index)
>  {
> - unsigned long handle = zram->table[index].handle;
> - u16 size = zram->table[index].size;
> + struct zram_meta *meta = zram->meta;
> + unsigned long handle = meta->table[index].handle;
> + u16 size = meta->table[index].size;
>  
>   if (unlikely(!handle)) {
>   /*
>* No memory is allocated for zero filled pages.
>* Simply clear zero page flag.
>*/
> - if (zram_test_flag(zram, index, ZRAM_ZERO)) {
> - zram_clear_flag(zram, index, ZRAM_ZERO);
> + if (zram_test_flag(meta, index, ZRAM_ZERO)) {
> + zram_clear_flag(meta, index, ZRAM_ZERO);
>   zram->stats.pages_zero--;
>   }
>   return;
> @@ -114,17 +115,17 @@ static void zram_free_page(struct zram *zram, size_t 
> index)
>   if (unlikely(size > max_zpage_size))
>   zram->stats.bad_compress--;
>  
> - zs_free(zram->mem_pool, handle);
> + zs_free(meta->mem_pool, handle);
>  
>   if (size <= PAGE_SIZE / 2)
>   zram->stats.good_compress--;
>  
>   zram_stat64_sub(zram, >stats.compr_size,
> - zram->table[index].size);
> + meta->table[index].size);
>   zram->stats.pages_stored--;
>  
> - zram->table[index].handle = 0;
> - zram->table[index].size = 0;
> + meta->table[index].handle = 0;
> + meta->table[index].size = 0;
>  }
>  
>  static void handle_zero_page(struct bio_vec *bvec)
> @@ -149,20 +150,21 @@ static int zram_decompress_page(struct zram *zram, char 
> *mem, u32 index)
>   int ret = LZO_E_OK;
>   size_t clen = PAGE_SIZE;
>   unsigned char *cmem;
> - unsigned long handle = zram->table[index].handle;
> + struct zram_meta *meta = zram->meta;
> + unsigned long handle = meta->table[index].handle;
>  
> - if (!handle || zram_test_flag(zram, index, ZRAM_ZERO)) {
> + if (!handle || zram_test_flag(meta, index, ZRAM_ZERO)) {
>   memset(mem, 0, PAGE_SIZE);
>   return 0;
>   }
>  
> - cmem = zs_map_object(zram->mem_pool, handle, ZS_MM_RO);
> - if (zram->table[index].size == PAGE_SIZE)
> + cmem = zs_map_object(meta->mem_pool, handle, ZS_MM_RO);
> + if (meta->table[index].size == PAGE_SIZE)
>   memcpy(mem, cmem, PAGE_SIZE);
>   else
> - ret = lzo1x_decompress_safe(cmem, zram->table[index].size,
> + ret = lzo1x_decompress_safe(cmem, meta->table[index].size,
>   mem, );
> - zs_unmap_object(zram->mem_pool, handle);
> + zs_unmap_object(meta->mem_pool, handle);
>  
>   /* Should NEVER happen. Return bio error if it does. */
>   if (unlikely(ret != LZO_E_OK)) {
> @@ -180,11 +182,11 @@ static int zram_bvec_read(struct zram *zram, struct 
> bio_vec *bvec,
>   int ret;
>   struct page *page;
>   unsigned char *user_mem, *uncmem = NULL;
> -
> 

Re: [PATCH v3] mtd: fix the wrong timeo for panic_nand_wait()

[Artem Bityutskiy]

On Wed, 2013-01-30 at 10:03 +0800, Huang Shijie wrote:
> The panic_nand_wait() expects the timeo in ms and not in jiffies.
> But in nand_wait(), the timeo for panic_nand_wait() is assigned with
> wrong value(jiffies + some delay). The timeo should be set like the
> panic_nand_write() does.
> 
> This patch passes timeo in ms to panic_nand_wait().
> And this patch also passes timeo in jiffies(converted by msecs_to_jiffies)
> to time_before() which makes the code more readable.
> 
> Signed-off-by: Huang Shijie 

Pushed to l2-mtd.git, thanks!

-- 
Best Regards,
Artem Bityutskiy


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

Re: [PATCH] memcg: stop warning on memcg_propagate_kmem

[Lord Glauber Costa of Sealand]

On 02/04/2013 08:29 AM, Hugh Dickins wrote:
> Whilst I run the risk of a flogging for disloyalty to the Lord of Sealand,
> I do have CONFIG_MEMCG=y CONFIG_MEMCG_KMEM not set, and grow tired of the
> "mm/memcontrol.c:4972:12: warning: `memcg_propagate_kmem' defined but not
> used [-Wunused-function]" seen in 3.8-rc: move the #ifdef outwards.
> 

Thanks my dear Hugh,

This is no disloyalty at all, and your braveness is indeed much appreciated.

My bad for letting that one slip

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

Re: [PATCH v7 2/4] zram: force disksize setting before using zram

[Ric Mason]

Hi Minchan,
On Mon, 2013-02-04 at 08:46 +0900, Minchan Kim wrote:
> Now zram document syas "set disksize is optional"
> but partly it's wrong. When you try to use zram firstly after
> booting, you must set disksize, otherwise zram can't work because
> zram gendisk's size is 0. But once you do it, you can use zram freely
> after reset because reset doesn't reset to zero paradoxically.
> So in this time, disksize setting is optional.:(
> It's inconsitent for user behavior and not straightforward.
> 
> This patch forces always setting disksize firstly before using zram.
> Yes. It changes current behavior so someone could complain when
> he upgrades zram. Apparently it could be a problem if zram is mainline
> but it still lives in staging so behavior could be changed for right
> way to go. Let them excuse.
> 
> Acked-by: Jerome Marchand 
> Acked-by: Nitin Gupta 
> Acked-by: Dan Magenheimer 
> Signed-off-by: Minchan Kim 
> ---
>  drivers/staging/zram/zram.txt |   27 ++--
>  drivers/staging/zram/zram_drv.c   |   51 
> +
>  drivers/staging/zram/zram_drv.h   |5 +---
>  drivers/staging/zram/zram_sysfs.c |6 +
>  4 files changed, 34 insertions(+), 55 deletions(-)
> 
> diff --git a/drivers/staging/zram/zram.txt b/drivers/staging/zram/zram.txt
> index 5f75d29..765d790 100644
> --- a/drivers/staging/zram/zram.txt
> +++ b/drivers/staging/zram/zram.txt
> @@ -23,17 +23,17 @@ Following shows a typical sequence of steps for using 
> zram.
>   This creates 4 devices: /dev/zram{0,1,2,3}
>   (num_devices parameter is optional. Default: 1)
>  
> -2) Set Disksize (Optional):
> - Set disk size by writing the value to sysfs node 'disksize'
> - (in bytes). If disksize is not given, default value of 25%
> - of RAM is used.
> -
> - # Initialize /dev/zram0 with 50MB disksize
> - echo $((50*1024*1024)) > /sys/block/zram0/disksize
> -
> - NOTE: disksize cannot be changed if the disk contains any
> - data. So, for such a disk, you need to issue 'reset' (see below)
> - before you can change its disksize.
> +2) Set Disksize
> +Set disk size by writing the value to sysfs node 'disksize'.
> +The value can be either in bytes or you can use mem suffixes.
> +Examples:
> +# Initialize /dev/zram0 with 50MB disksize
> +echo $((50*1024*1024)) > /sys/block/zram0/disksize
> +
> +# Using mem suffixes
> +echo 256K > /sys/block/zram0/disksize
> +echo 512M > /sys/block/zram0/disksize
> +echo 1G > /sys/block/zram0/disksize
>  
>  3) Activate:
>   mkswap /dev/zram0
> @@ -65,8 +65,9 @@ Following shows a typical sequence of steps for using zram.
>   echo 1 > /sys/block/zram0/reset
>   echo 1 > /sys/block/zram1/reset
>  
> - (This frees all the memory allocated for the given device).
> -
> + This frees all the memory allocated for the given device and
> + resets the disksize to zero. You must set the disksize again
> + before reusing the device.
>  
>  Please report any problems at:
>   - Mailing list: linux-mm-cc at laptop dot org
> diff --git a/drivers/staging/zram/zram_drv.c b/drivers/staging/zram/zram_drv.c
> index 262265e..1114cad 100644
> --- a/drivers/staging/zram/zram_drv.c
> +++ b/drivers/staging/zram/zram_drv.c
> @@ -94,34 +94,6 @@ static int page_zero_filled(void *ptr)
>   return 1;
>  }
>  
> -static void zram_set_disksize(struct zram *zram, size_t totalram_bytes)
> -{
> - if (!zram->disksize) {
> - pr_info(
> - "disk size not provided. You can use disksize_kb module "
> - "param to specify size.\nUsing default: (%u%% of RAM).\n",
> - default_disksize_perc_ram
> - );
> - zram->disksize = default_disksize_perc_ram *
> - (totalram_bytes / 100);
> - }
> -
> - if (zram->disksize > 2 * (totalram_bytes)) {
> - pr_info(
> - "There is little point creating a zram of greater than "
> - "twice the size of memory since we expect a 2:1 compression "
> - "ratio. Note that zram uses about 0.1%% of the size of "
> - "the disk when not in use so a huge zram is "
> - "wasteful.\n"
> - "\tMemory Size: %zu kB\n"
> - "\tSize you selected: %llu kB\n"
> - "Continuing anyway ...\n",
> - totalram_bytes >> 10, zram->disksize >> 10);
> - }
> -
> - zram->disksize &= PAGE_MASK;
> -}
> -
>  static void zram_free_page(struct zram *zram, size_t index)
>  {
>   unsigned long handle = zram->table[index].handle;
> @@ -497,6 +469,9 @@ void __zram_reset_device(struct zram *zram)
>  {
>   size_t index;
>  
> + if (!zram->init_done)
> + return;
> +
>   zram->init_done = 0;
>  
>   /* Free various per-device buffers */
> @@ -525,6 +500,7 @@ void __zram_reset_device(struct zram 

Re: [PATCH 1/8] perf tools: Add '.' as part of the event 'name' token

[Jiri Olsa]

On Sun, Feb 03, 2013 at 09:37:16PM +0100, Stephane Eranian wrote:
> On Tue, Jan 29, 2013 at 9:03 AM, Ingo Molnar  wrote:
> >
> > * Stephane Eranian  wrote:
> >
> >> On Mon, Jan 28, 2013 at 9:52 PM, Stephane Eranian  
> >> wrote:

SNIP

> Adding the option for users to link with libpfm4 was no big
> deal in my mind. You are opposed to that. That's your
> choice. I don't buy your arguments for this patch series
> and will continue to provide a patch to link perf and libpfm4
> for users who are interested.
> 
> I would have appreciated some discussion on this instead, once
> again, work was done behind closed door and thrown at my face.

Not sure why you think it was 'closed door'.. I needed some way to
access those events and sent RFC for it with you being on CC list.

> The worst being that as far I can see in the patches, no proper
> credits to libpfm4 contributors is even given for providing the raw
> information that allowed you to  build your event tables without too

Right, sorry for that.. I'll add it.

> much sweat! Building electronic event tables from vendor specs is
> a lot harder than it seems, but you may not know this.

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

[PATCH v2 1/3] fix mm: use long type for page counts in mm_populate() and get_user_pages()

[Michel Lespinasse]

Andrew suggested I make the nr_pages argument an unsigned long rather
than just a long. I was initially worried that nr_pages would be compared
with signed longs, but this isn't the case, so his suggestion is perfectly
valid.

Sending as a 'fix' change, to be collapsed with the original in -mm.

Signed-off-by: Michel Lespinasse 

---
 include/linux/hugetlb.h |  2 +-
 include/linux/mm.h  | 11 ++-
 mm/hugetlb.c|  8 
 mm/memory.c | 12 ++--
 mm/mlock.c  |  2 +-
 5 files changed, 18 insertions(+), 17 deletions(-)

diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index fc6ed17cfd17..eedc334fb6f5 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -45,7 +45,7 @@ int hugetlb_mempolicy_sysctl_handler(struct ctl_table *, int,
 int copy_hugetlb_page_range(struct mm_struct *, struct mm_struct *, struct 
vm_area_struct *);
 long follow_hugetlb_page(struct mm_struct *, struct vm_area_struct *,
 struct page **, struct vm_area_struct **,
-unsigned long *, long *, long, unsigned int flags);
+unsigned long *, unsigned long *, long, unsigned int);
 void unmap_hugepage_range(struct vm_area_struct *,
  unsigned long, unsigned long, struct page *);
 void __unmap_hugepage_range_final(struct mmu_gather *tlb,
diff --git a/include/linux/mm.h b/include/linux/mm.h
index d5716094f191..3d9fbcf9fa94 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1041,12 +1041,13 @@ extern int access_remote_vm(struct mm_struct *mm, 
unsigned long addr,
void *buf, int len, int write);
 
 long __get_user_pages(struct task_struct *tsk, struct mm_struct *mm,
- unsigned long start, long len, unsigned int foll_flags,
- struct page **pages, struct vm_area_struct **vmas,
- int *nonblocking);
+ unsigned long start, unsigned long nr_pages,
+ unsigned int foll_flags, struct page **pages,
+ struct vm_area_struct **vmas, int *nonblocking);
 long get_user_pages(struct task_struct *tsk, struct mm_struct *mm,
-   unsigned long start, long nr_pages, int write, int force,
-   struct page **pages, struct vm_area_struct **vmas);
+   unsigned long start, unsigned long nr_pages,
+   int write, int force, struct page **pages,
+   struct vm_area_struct **vmas);
 int get_user_pages_fast(unsigned long start, int nr_pages, int write,
struct page **pages);
 struct kvec;
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 4ad07221ce60..951873c8f57e 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -2926,12 +2926,12 @@ follow_huge_pud(struct mm_struct *mm, unsigned long 
address,
 
 long follow_hugetlb_page(struct mm_struct *mm, struct vm_area_struct *vma,
 struct page **pages, struct vm_area_struct **vmas,
-unsigned long *position, long *length, long i,
-unsigned int flags)
+unsigned long *position, unsigned long *nr_pages,
+long i, unsigned int flags)
 {
unsigned long pfn_offset;
unsigned long vaddr = *position;
-   long remainder = *length;
+   unsigned long remainder = *nr_pages;
struct hstate *h = hstate_vma(vma);
 
spin_lock(>page_table_lock);
@@ -3001,7 +3001,7 @@ same_page:
}
}
spin_unlock(>page_table_lock);
-   *length = remainder;
+   *nr_pages = remainder;
*position = vaddr;
 
return i ? i : -EFAULT;
diff --git a/mm/memory.c b/mm/memory.c
index 381b78c20d84..f0b6b2b798c4 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -1674,14 +1674,14 @@ static inline int stack_guard_page(struct 
vm_area_struct *vma, unsigned long add
  * you need some special @gup_flags.
  */
 long __get_user_pages(struct task_struct *tsk, struct mm_struct *mm,
-   unsigned long start, long nr_pages, unsigned int gup_flags,
-   struct page **pages, struct vm_area_struct **vmas,
-   int *nonblocking)
+   unsigned long start, unsigned long nr_pages,
+   unsigned int gup_flags, struct page **pages,
+   struct vm_area_struct **vmas, int *nonblocking)
 {
long i;
unsigned long vm_flags;
 
-   if (nr_pages <= 0)
+   if (!nr_pages)
return 0;
 
VM_BUG_ON(!!pages != !!(gup_flags & FOLL_GET));
@@ -1978,8 +1978,8 @@ int fixup_user_fault(struct task_struct *tsk, struct 
mm_struct *mm,
  * See also get_user_pages_fast, for performance critical applications.
  */
 long get_user_pages(struct task_struct *tsk, struct mm_struct *mm,
-   unsigned long start, long nr_pages, int write, int force,
-   struct page **pages, struct vm_area_struct 

[PATCH v2 0/3] fixes for large mm_populate() and munlock() operations

[Michel Lespinasse]

These 3 changes are to improve the handling of large mm_populate and
munlock operations. They apply on top of mmotm (in particular, they
depend on both my prior mm_populate work and Kirill's "thp: avoid
dumping huge zero page" change).

- Patch 1 fixes an integer overflow issue when populating 2^32 pages.
  The nr_pages argument to get_user_pages would overflow, resulting in 0
  pages being processed per iteration. I am proposing to simply convert
  the nr_pages argument to a long.

- Patch 2 accelerates populating regions with THP pages. get_user_pages()
  can increment the address by a huge page size in this case instead of
  a small page size, and avoid repeated mm->page_table_lock acquisitions.
  This fixes an issue reported by Roman Dubtsov where populating regions
  via mmap MAP_POPULATE was significantly slower than doing so by
  touching pages from userspace.

- Patch 3 is a similar acceleration for the munlock case. I would actually
  like to get Andrea's attention on this one, as I can't explain how
  munlock_vma_page() is safe against racing with split_huge_page().

Note that patches 1-2 are logically independent of patch 3, so if the
discussion of patch 3 takes too long I would ask Andrew to consider
merging patches 1-2 first.

Changes since v1:

- Andrew accepted patch 1 into his -mm tree but suggested the nr_pages
  argument type should actually be unsigned long; I am sending this as
  a "fix" for the previous patch 1 to be collapsed over the previous one.

- In patch 2, I am adding a separate follow_page_mask() function so that
  the callers to the original follow_page() don't have to be modified to
  ignore the returned page_mask (following another suggestion from Andrew).
  Also the page_mask argument type was changed to unsigned int.

- In patch 3, I similarly changed the page_mask values to unsigned int.

Michel Lespinasse (3):
  fix mm: use long type for page counts in mm_populate() and get_user_pages()
  mm: accelerate mm_populate() treatment of THP pages
  mm: accelerate munlock() treatment of THP pages

 include/linux/hugetlb.h |  2 +-
 include/linux/mm.h  | 24 +---
 mm/hugetlb.c|  8 
 mm/internal.h   |  2 +-
 mm/memory.c | 43 +--
 mm/mlock.c  | 34 ++
 mm/nommu.c  |  6 --
 7 files changed, 78 insertions(+), 41 deletions(-)

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

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

[Stephen Rothwell]

Hi Andrew,

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

arch/x86/mm/init_64.c: In function 'remove_pmd_table':
arch/x86/mm/init_64.c:921:3: error: implicit declaration of function 
'map_low_page' [-Werror=implicit-function-declaration]
arch/x86/mm/init_64.c:921:14: warning: cast to pointer from integer of 
different size [-Wint-to-pointer-cast]
arch/x86/mm/init_64.c:924:3: error: implicit declaration of function 
'unmap_low_page' [-Werror=implicit-function-declaration]
arch/x86/mm/init_64.c: In function 'remove_pud_table':
arch/x86/mm/init_64.c:978:14: warning: cast to pointer from integer of 
different size [-Wint-to-pointer-cast]
arch/x86/mm/init_64.c: In function 'remove_pagetable':
arch/x86/mm/init_64.c:1004:9: warning: cast to pointer from integer of 
different size [-Wint-to-pointer-cast]

Caused by commit "memory-hotplug: common APIs to support page tables
hot-remove" from the akpm tree interacting with commit 973dc4f3fad5
("x86, mm: Remove early_memremap workaround for page table accessing on
64bit") from the tip tree.

I applied the following merge fix patch:

From: Stephen Rothwell 
Date: Mon, 4 Feb 2013 18:12:17 +1100
Subject: [PATCH] memory-hotplug: common APIs to support page tables hot-remove 
fix fix

Signed-off-by: Stephen Rothwell 
---
 arch/x86/mm/init_64.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index 951cc1e..67bad4b 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -918,10 +918,9 @@ remove_pmd_table(pmd_t *pmd_start, unsigned long addr, 
unsigned long end,
continue;
}
 
-   pte_base = (pte_t *)map_low_page((pte_t *)pmd_page_vaddr(*pmd));
+   pte_base = (pte_t *)pmd_page_vaddr(*pmd);
remove_pte_table(pte_base, addr, next, direct);
free_pte_table(pte_base, pmd);
-   unmap_low_page(pte_base);
}
 
/* Call free_pmd_table() in remove_pud_table(). */
@@ -975,10 +974,9 @@ remove_pud_table(pud_t *pud_start, unsigned long addr, 
unsigned long end,
continue;
}
 
-   pmd_base = (pmd_t *)map_low_page((pmd_t *)pud_page_vaddr(*pud));
+   pmd_base = (pmd_t *)pud_page_vaddr(*pud);
remove_pmd_table(pmd_base, addr, next, direct);
free_pmd_table(pmd_base, pud);
-   unmap_low_page(pmd_base);
}
 
if (direct)
@@ -1001,11 +999,10 @@ remove_pagetable(unsigned long start, unsigned long end, 
bool direct)
 
next = pgd_addr_end(start, end);
 
-   pud = (pud_t *)map_low_page((pud_t *)pgd_page_vaddr(*pgd));
+   pud = (pud_t *)pgd_page_vaddr(*pgd);
remove_pud_table(pud, start, next, direct);
if (free_pud_table(pud, pgd))
pgd_changed = true;
-   unmap_low_page(pud);
}
 
if (pgd_changed)
-- 
1.8.1

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


pgpUg2SoDE9D7.pgp
Description: PGP signature

[PATCH v2 3/3] mm: accelerate munlock() treatment of THP pages

[Michel Lespinasse]

munlock_vma_pages_range() was always incrementing addresses by PAGE_SIZE
at a time. When munlocking THP pages (or the huge zero page), this resulted
in taking the mm->page_table_lock 512 times in a row.

We can do better by making use of the page_mask returned by follow_page_mask
(for the huge zero page case), or the size of the page munlock_vma_page()
operated on (for the true THP page case).

Note - I am sending this as RFC only for now as I can't currently put
my finger on what if anything prevents split_huge_page() from operating
concurrently on the same page as munlock_vma_page(), which would mess
up our NR_MLOCK statistics. Is this a latent bug or is there a subtle
point I missed here ?

Signed-off-by: Michel Lespinasse 

---
 mm/internal.h |  2 +-
 mm/mlock.c| 32 +---
 2 files changed, 22 insertions(+), 12 deletions(-)

diff --git a/mm/internal.h b/mm/internal.h
index 1c0c4cc0fcf7..8562de0a5197 100644
--- a/mm/internal.h
+++ b/mm/internal.h
@@ -195,7 +195,7 @@ static inline int mlocked_vma_newpage(struct vm_area_struct 
*vma,
  * must be called with vma's mmap_sem held for read or write, and page locked.
  */
 extern void mlock_vma_page(struct page *page);
-extern void munlock_vma_page(struct page *page);
+extern unsigned int munlock_vma_page(struct page *page);
 
 /*
  * Clear the page's PageMlocked().  This can be useful in a situation where
diff --git a/mm/mlock.c b/mm/mlock.c
index 6baaf4b0e591..486702edee35 100644
--- a/mm/mlock.c
+++ b/mm/mlock.c
@@ -102,13 +102,14 @@ void mlock_vma_page(struct page *page)
  * can't isolate the page, we leave it for putback_lru_page() and vmscan
  * [page_referenced()/try_to_unmap()] to deal with.
  */
-void munlock_vma_page(struct page *page)
+unsigned int munlock_vma_page(struct page *page)
 {
+   unsigned int nr_pages = hpage_nr_pages(page);
+
BUG_ON(!PageLocked(page));
 
if (TestClearPageMlocked(page)) {
-   mod_zone_page_state(page_zone(page), NR_MLOCK,
-   -hpage_nr_pages(page));
+   mod_zone_page_state(page_zone(page), NR_MLOCK, -nr_pages);
if (!isolate_lru_page(page)) {
int ret = SWAP_AGAIN;
 
@@ -141,6 +142,8 @@ void munlock_vma_page(struct page *page)
count_vm_event(UNEVICTABLE_PGMUNLOCKED);
}
}
+
+   return nr_pages;
 }
 
 /**
@@ -159,7 +162,6 @@ long __mlock_vma_pages_range(struct vm_area_struct *vma,
unsigned long start, unsigned long end, int *nonblocking)
 {
struct mm_struct *mm = vma->vm_mm;
-   unsigned long addr = start;
unsigned long nr_pages = (end - start) / PAGE_SIZE;
int gup_flags;
 
@@ -185,7 +187,7 @@ long __mlock_vma_pages_range(struct vm_area_struct *vma,
if (vma->vm_flags & (VM_READ | VM_WRITE | VM_EXEC))
gup_flags |= FOLL_FORCE;
 
-   return __get_user_pages(current, mm, addr, nr_pages, gup_flags,
+   return __get_user_pages(current, mm, start, nr_pages, gup_flags,
NULL, NULL, nonblocking);
 }
 
@@ -222,13 +224,12 @@ static int __mlock_posix_error_return(long retval)
 void munlock_vma_pages_range(struct vm_area_struct *vma,
 unsigned long start, unsigned long end)
 {
-   unsigned long addr;
-
-   lru_add_drain();
vma->vm_flags &= ~VM_LOCKED;
 
-   for (addr = start; addr < end; addr += PAGE_SIZE) {
+   while (start < end) {
struct page *page;
+   unsigned int page_mask, page_increm;
+
/*
 * Although FOLL_DUMP is intended for get_dump_page(),
 * it just so happens that its special treatment of the
@@ -236,13 +237,22 @@ void munlock_vma_pages_range(struct vm_area_struct *vma,
 * suits munlock very well (and if somehow an abnormal page
 * has sneaked into the range, we won't oops here: great).
 */
-   page = follow_page(vma, addr, FOLL_GET | FOLL_DUMP);
+   page = follow_page_mask(vma, start, FOLL_GET | FOLL_DUMP,
+   _mask);
if (page && !IS_ERR(page)) {
lock_page(page);
-   munlock_vma_page(page);
+   lru_add_drain();
+   /*
+* Any THP page found by follow_page_mask() may have
+* gotten split before reaching munlock_vma_page(),
+* so we need to recompute the page_mask here.
+*/
+   page_mask = munlock_vma_page(page);
unlock_page(page);
put_page(page);
}
+   page_increm = 1 + (~(start >> PAGE_SHIFT) & page_mask);
+   start += page_increm * PAGE_SIZE;
cond_resched();
}
 }

[PATCH v2 2/3] mm: accelerate mm_populate() treatment of THP pages

[Michel Lespinasse]

This change adds a follow_page_mask function which is equivalent to
follow_page, but with an extra page_mask argument.

follow_page_mask sets *page_mask to HPAGE_PMD_NR - 1 when it encounters a
THP page, and to 0 in other cases.

__get_user_pages() makes use of this in order to accelerate populating
THP ranges - that is, when both the pages and vmas arrays are NULL,
we don't need to iterate HPAGE_PMD_NR times to cover a single THP page
(and we also avoid taking mm->page_table_lock that many times).

Signed-off-by: Michel Lespinasse 

---
 include/linux/mm.h | 13 +++--
 mm/memory.c| 31 +++
 mm/nommu.c |  6 --
 3 files changed, 38 insertions(+), 12 deletions(-)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index 3d9fbcf9fa94..31e4d42002ee 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1636,8 +1636,17 @@ int vm_insert_pfn(struct vm_area_struct *vma, unsigned 
long addr,
 int vm_insert_mixed(struct vm_area_struct *vma, unsigned long addr,
unsigned long pfn);
 
-struct page *follow_page(struct vm_area_struct *, unsigned long address,
-   unsigned int foll_flags);
+struct page *follow_page_mask(struct vm_area_struct *vma,
+ unsigned long address, unsigned int foll_flags,
+ unsigned int *page_mask);
+
+static inline struct page *follow_page(struct vm_area_struct *vma,
+   unsigned long address, unsigned int foll_flags)
+{
+   unsigned int unused_page_mask;
+   return follow_page_mask(vma, address, foll_flags, _page_mask);
+}
+
 #define FOLL_WRITE 0x01/* check pte is writable */
 #define FOLL_TOUCH 0x02/* mark page accessed */
 #define FOLL_GET   0x04/* do get_page on page */
diff --git a/mm/memory.c b/mm/memory.c
index f0b6b2b798c4..52c8599e7fe4 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -1458,10 +1458,11 @@ int zap_vma_ptes(struct vm_area_struct *vma, unsigned 
long address,
 EXPORT_SYMBOL_GPL(zap_vma_ptes);
 
 /**
- * follow_page - look up a page descriptor from a user-virtual address
+ * follow_page_mask - look up a page descriptor from a user-virtual address
  * @vma: vm_area_struct mapping @address
  * @address: virtual address to look up
  * @flags: flags modifying lookup behaviour
+ * @page_mask: on output, *page_mask is set according to the size of the page
  *
  * @flags can have FOLL_ flags set, defined in 
  *
@@ -1469,8 +1470,9 @@ EXPORT_SYMBOL_GPL(zap_vma_ptes);
  * an error pointer if there is a mapping to something not represented
  * by a page descriptor (see also vm_normal_page()).
  */
-struct page *follow_page(struct vm_area_struct *vma, unsigned long address,
-   unsigned int flags)
+struct page *follow_page_mask(struct vm_area_struct *vma,
+ unsigned long address, unsigned int flags,
+ unsigned int *page_mask)
 {
pgd_t *pgd;
pud_t *pud;
@@ -1480,6 +1482,8 @@ struct page *follow_page(struct vm_area_struct *vma, 
unsigned long address,
struct page *page;
struct mm_struct *mm = vma->vm_mm;
 
+   *page_mask = 0;
+
page = follow_huge_addr(mm, address, flags & FOLL_WRITE);
if (!IS_ERR(page)) {
BUG_ON(flags & FOLL_GET);
@@ -1526,6 +1530,7 @@ struct page *follow_page(struct vm_area_struct *vma, 
unsigned long address,
page = follow_trans_huge_pmd(vma, address,
 pmd, flags);
spin_unlock(>page_table_lock);
+   *page_mask = HPAGE_PMD_NR - 1;
goto out;
}
} else
@@ -1680,6 +1685,7 @@ long __get_user_pages(struct task_struct *tsk, struct 
mm_struct *mm,
 {
long i;
unsigned long vm_flags;
+   unsigned int page_mask;
 
if (!nr_pages)
return 0;
@@ -1757,6 +1763,7 @@ long __get_user_pages(struct task_struct *tsk, struct 
mm_struct *mm,
get_page(page);
}
pte_unmap(pte);
+   page_mask = 0;
goto next_page;
}
 
@@ -1774,6 +1781,7 @@ long __get_user_pages(struct task_struct *tsk, struct 
mm_struct *mm,
do {
struct page *page;
unsigned int foll_flags = gup_flags;
+   unsigned int page_increm;
 
/*
 * If we have a pending SIGKILL, don't keep faulting
@@ -1783,7 +1791,8 @@ long __get_user_pages(struct task_struct *tsk, struct 
mm_struct *mm,
return i ? i : -ERESTARTSYS;
 
cond_resched();
-   while (!(page = follow_page(vma, start, foll_flags))) {
+

[PATCH 2/2]linux-usb:optimize to match the Huawei USB storage devices and support new switch command

[fangxiaozhi 00110321]

From: fangxiaozhi 

1. Optimize the match rules with new macro for Huawei USB storage devices, 
   to avoid to load USB storage driver for the modem interface 
   with Huawei devices.
2. Add to support new switch command for new Huawei USB dongles.

Signed-off-by: fangxiaozhi 


diff -uprN linux-3.8-rc6_orig/drivers/usb/storage/initializers.c 
linux-3.8-rc6/drivers/usb/storage/initializers.c
--- linux-3.8-rc6_orig/drivers/usb/storage/initializers.c   2013-02-04 
14:38:34.268154216 +0800
+++ linux-3.8-rc6/drivers/usb/storage/initializers.c2013-02-04 
14:52:19.947201855 +0800
@@ -92,8 +92,8 @@ int usb_stor_ucr61s2b_init(struct us_dat
return 0;
 }
 
-/* This places the HUAWEI E220 devices in multi-port mode */
-int usb_stor_huawei_e220_init(struct us_data *us)
+/* This places the HUAWEI usb dongles in multi-port mode */
+static int usb_stor_huawei_feature_init(struct us_data *us)
 {
int result;
 
@@ -104,3 +104,75 @@ int usb_stor_huawei_e220_init(struct us_
US_DEBUGP("Huawei mode set result is %d\n", result);
return 0;
 }
+
+/*
+ * It will send a scsi switch command called rewind' to huawei dongle.
+ * When the dongle receives this command at the first time,
+ * it will reboot immediately. After rebooted, it will ignore this command.
+ * So it is  unnecessary to read its response.
+ */
+static int usb_stor_huawei_scsi_init(struct us_data *us)
+{
+   int result = 0;
+   int act_len = 0;
+   struct bulk_cb_wrap *bcbw = (struct bulk_cb_wrap *) us->iobuf;
+   char rewind_cmd[] = {0x11, 0x06, 0x20, 0x00, 0x00, 0x01, 0x01, 0x00,
+   0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
+
+   bcbw->Signature = cpu_to_le32(US_BULK_CB_SIGN);
+   bcbw->Tag = 0;
+   bcbw->DataTransferLength = 0;
+   bcbw->Flags = bcbw->Lun = 0;
+   bcbw->Length = sizeof(rewind_cmd);
+   memset(bcbw->CDB, 0, sizeof(bcbw->CDB));
+   memcpy(bcbw->CDB, rewind_cmd, sizeof(rewind_cmd));
+
+   result = usb_stor_bulk_transfer_buf(us, us->send_bulk_pipe, bcbw,
+   US_BULK_CB_WRAP_LEN, _len);
+   US_DEBUGP("transfer actual length=%d, result=%d\n", act_len, result);
+   return result;
+}
+
+/*
+ * It tries to find the supported Huawei USB dongles.
+ * In Huawei, they assign the following product IDs
+ * for all of their mobile broadband dongles,
+ * including the new dongles in the future.
+ * So if the product ID is not included in this list,
+ * it means it is not Huawei's mobile broadband dongles.
+ */
+static int usb_stor_huawei_dongles_pid(struct us_data *us)
+{
+   struct usb_interface_descriptor *idesc;
+   int idProduct;
+
+   idesc = >pusb_intf->cur_altsetting->desc;
+   idProduct = us->pusb_dev->descriptor.idProduct;
+   /* The first port is CDROM,
+* means the dongle in the single port mode,
+* and a switch command is required to be sent. */
+   if (idesc && idesc->bInterfaceNumber == 0) {
+   if ((idProduct == 0x1001)
+   || (idProduct == 0x1003)
+   || (idProduct == 0x1004)
+   || (idProduct >= 0x1401 && idProduct <= 0x1500)
+   || (idProduct >= 0x1505 && idProduct <= 0x1600)
+   || (idProduct >= 0x1c02 && idProduct <= 0x2202)) {
+   return 1;
+   }
+   }
+   return 0;
+}
+
+int usb_stor_huawei_init(struct us_data *us)
+{
+   int result = 0;
+
+   if (usb_stor_huawei_dongles_pid(us)) {
+   if (us->pusb_dev->descriptor.idProduct >= 0x1446)
+   result = usb_stor_huawei_scsi_init(us);
+   else
+   result = usb_stor_huawei_feature_init(us);
+   }
+   return result;
+}
diff -uprN linux-3.8-rc6_orig/drivers/usb/storage/initializers.h 
linux-3.8-rc6/drivers/usb/storage/initializers.h
--- linux-3.8-rc6_orig/drivers/usb/storage/initializers.h   2013-02-04 
14:38:34.269154217 +0800
+++ linux-3.8-rc6/drivers/usb/storage/initializers.h2013-02-04 
14:52:19.947201855 +0800
@@ -46,5 +46,5 @@ int usb_stor_euscsi_init(struct us_data
  * flash reader */
 int usb_stor_ucr61s2b_init(struct us_data *us);
 
-/* This places the HUAWEI E220 devices in multi-port mode */
-int usb_stor_huawei_e220_init(struct us_data *us);
+/* This places the HUAWEI usb dongles in multi-port mode */
+int usb_stor_huawei_init(struct us_data *us);
diff -uprN linux-3.8-rc6_orig/drivers/usb/storage/unusual_devs.h 
linux-3.8-rc6/drivers/usb/storage/unusual_devs.h
--- linux-3.8-rc6_orig/drivers/usb/storage/unusual_devs.h   2013-02-04 
14:38:34.267154216 +0800
+++ linux-3.8-rc6/drivers/usb/storage/unusual_devs.h2013-02-04 
14:52:19.949201855 +0800
@@ -1527,335 +1527,10 @@ UNUSUAL_DEV(  0x1210, 0x0003, 0x0100, 0x
 /* Reported by fangxiaozhi 
  * This brings the HUAWEI data card devices into 

[PATCH 1/2]linux-usb:Define a new macro for USB storage match rules

[fangxiaozhi 00110321]

From: fangxiaozhi 

1. Define a new macro for USB storage match rules: 
matching with Vendor ID and interface descriptors.

Signed-off-by: fangxiaozhi 


diff -uprN linux-3.8-rc6_orig/drivers/usb/storage/usb.c 
linux-3.8-rc6/drivers/usb/storage/usb.c
--- linux-3.8-rc6_orig/drivers/usb/storage/usb.c2013-02-04 
14:38:34.268154216 +0800
+++ linux-3.8-rc6/drivers/usb/storage/usb.c 2013-02-04 14:42:17.103167073 
+0800
@@ -120,6 +120,17 @@ MODULE_PARM_DESC(quirks, "supplemental l
.useTransport = use_transport,  \
 }
 
+#define UNUSUAL_VENDOR_INTF(idVendor, cl, sc, pr, \
+   vendor_name, product_name, use_protocol, use_transport, \
+   init_function, Flags) \
+{ \
+   .vendorName = vendor_name,  \
+   .productName = product_name,\
+   .useProtocol = use_protocol,\
+   .useTransport = use_transport,  \
+   .initFunction = init_function,  \
+}
+
 static struct us_unusual_dev us_unusual_dev_list[] = {
 #  include "unusual_devs.h"
{ } /* Terminating entry */
@@ -131,6 +142,7 @@ static struct us_unusual_dev for_dynamic
 #undef UNUSUAL_DEV
 #undef COMPLIANT_DEV
 #undef USUAL_DEV
+#undef UNUSUAL_VENDOR_INTF
 
 #ifdef CONFIG_LOCKDEP
 
diff -uprN linux-3.8-rc6_orig/drivers/usb/storage/usual-tables.c 
linux-3.8-rc6/drivers/usb/storage/usual-tables.c
--- linux-3.8-rc6_orig/drivers/usb/storage/usual-tables.c   2013-02-04 
14:38:34.268154216 +0800
+++ linux-3.8-rc6/drivers/usb/storage/usual-tables.c2013-02-04 
14:49:48.256193103 +0800
@@ -41,6 +41,20 @@
 #define USUAL_DEV(useProto, useTrans) \
 { USB_INTERFACE_INFO(USB_CLASS_MASS_STORAGE, useProto, useTrans) }
 
+/* Define the device is matched with Vendor ID and interface descriptors */
+#define UNUSUAL_VENDOR_INTF(id_vendor, cl, sc, pr, \
+   vendorName, productName, useProtocol, useTransport, \
+   initFunction, flags) \
+{ \
+   .match_flags = USB_DEVICE_ID_MATCH_INT_INFO \
+   | USB_DEVICE_ID_MATCH_VENDOR, \
+   .idVendor= (id_vendor), \
+   .bInterfaceClass = (cl), \
+   .bInterfaceSubClass = (sc), \
+   .bInterfaceProtocol = (pr), \
+   .driver_info = (flags) \
+}
+
 struct usb_device_id usb_storage_usb_ids[] = {
 #  include "unusual_devs.h"
{ } /* Terminating entry */
@@ -50,6 +64,7 @@ MODULE_DEVICE_TABLE(usb, usb_storage_usb
 #undef UNUSUAL_DEV
 #undef COMPLIANT_DEV
 #undef USUAL_DEV
+#undef UNUSUAL_VENDOR_INTF
 
 /*
  * The table of devices to ignore

--
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 v5 10/10] clk: tegra: devicetree match for nvidia,tegra114-car

[Prashant Gaikwad]

On Friday 01 February 2013 03:48 PM, Peter De Schrijver wrote:

Signed-off-by: Peter De Schrijver 
---


Reviewed-by: Prashant Gaikwad 


  drivers/clk/tegra/clk.c |1 +
  drivers/clk/tegra/clk.h |7 +++
  2 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/drivers/clk/tegra/clk.c b/drivers/clk/tegra/clk.c
index a603b9a..a328365 100644
--- a/drivers/clk/tegra/clk.c
+++ b/drivers/clk/tegra/clk.c
@@ -76,6 +76,7 @@ void __init tegra_init_from_table(struct tegra_clk_init_table 
*tbl,
  static const struct of_device_id tegra_dt_clk_match[] = {
{ .compatible = "nvidia,tegra20-car", .data = tegra20_clock_init },
{ .compatible = "nvidia,tegra30-car", .data = tegra30_clock_init },
+   { .compatible = "nvidia,tegra114-car", .data = tegra114_clock_init },
{ }
  };
  
diff --git a/drivers/clk/tegra/clk.h b/drivers/clk/tegra/clk.h

index 8756d9f..8097850 100644
--- a/drivers/clk/tegra/clk.h
+++ b/drivers/clk/tegra/clk.h
@@ -576,4 +576,11 @@ void tegra30_clock_init(struct device_node *np);
  static inline void tegra30_clock_init(struct device_node *np) {}
  #endif /* CONFIG_ARCH_TEGRA_3x_SOC */
  
+#ifdef CONFIG_ARCH_TEGRA_114_SOC

+void tegra114_clock_init(struct device_node *np);
+#else
+static inline void tegra114_clock_init(struct device_node *np) {}
+#endif /* CONFIG_ARCH_TEGRA114_SOC */
+
+
  #endif /* TEGRA_CLK_H */



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

[PATCH V2 3/3] i915: ignore lid open event when resuming

[Zhang Rui]

i915 driver needs to do modeset when
1. system resumes from sleep
2. lid is opened

In PM_SUSPEND_MEM state, all the GPEs are cleared when system resumes,
thus it is the i915_resume code does the modeset rather than intel_lid_notify().

But in PM_SUSPEND_FREEZE state, this will be broken because
system is still responsive to the lid events.
1. When we close the lid in Freeze state, intel_lid_notify() sets 
modeset_on_lid.
2. When we reopen the lid, intel_lid_notify() will do a modeset,
   before the system is resumed.
here is the error log,

[92146.548074] WARNING: at drivers/gpu/drm/i915/intel_display.c:1028 
intel_wait_for_pipe_off+0x184/0x190 [i915]()
[92146.548076] Hardware name: VGN-Z540N
[92146.548078] pipe_off wait timed out
[92146.548167] Modules linked in: hid_generic usbhid hid snd_hda_codec_realtek 
snd_hda_intel snd_hda_codec parport_pc snd_hwdep ppdev snd_pcm_oss i915 
snd_mixer_oss snd_pcm arc4 iwldvm snd_seq_dummy mac80211 snd_seq_oss 
snd_seq_midi fbcon tileblit font bitblit softcursor drm_kms_helper snd_rawmidi 
snd_seq_midi_event coretemp drm snd_seq kvm btusb bluetooth snd_timer iwlwifi 
pcmcia tpm_infineon i2c_algo_bit joydev snd_seq_device intel_agp cfg80211 snd 
intel_gtt yenta_socket pcmcia_rsrc sony_laptop agpgart microcode psmouse 
tpm_tis serio_raw mxm_wmi soundcore snd_page_alloc tpm acpi_cpufreq lpc_ich 
pcmcia_core tpm_bios mperf processor lp parport firewire_ohci firewire_core 
crc_itu_t sdhci_pci sdhci thermal e1000e
[92146.548173] Pid: 4304, comm: kworker/0:0 Tainted: GW
3.8.0-rc3-s0i3-v3-test+ #9
[92146.548175] Call Trace:
[92146.548189]  [] warn_slowpath_common+0x72/0xa0
[92146.548227]  [] ? intel_wait_for_pipe_off+0x184/0x190 [i915]
[92146.548263]  [] ? intel_wait_for_pipe_off+0x184/0x190 [i915]
[92146.548270]  [] warn_slowpath_fmt+0x33/0x40
[92146.548307]  [] intel_wait_for_pipe_off+0x184/0x190 [i915]
[92146.548344]  [] intel_disable_pipe+0x102/0x190 [i915]
[92146.548380]  [] ? intel_disable_plane+0x64/0x80 [i915]
[92146.548417]  [] i9xx_crtc_disable+0xbc/0x150 [i915]
[92146.548456]  [] intel_crtc_update_dpms+0x5e/0x90 [i915]
[92146.548493]  [] intel_modeset_setup_hw_state+0x42f/0x8f0 [i915]
[92146.548535]  [] intel_lid_notify+0x9b/0xc0 [i915]
[92146.548543]  [] notifier_call_chain+0x43/0x60
[92146.548550]  [] __blocking_notifier_call_chain+0x41/0x80
[92146.548556]  [] blocking_notifier_call_chain+0x1f/0x30
[92146.548563]  [] acpi_lid_send_state+0x78/0xa4
[92146.548569]  [] acpi_button_notify+0x3b/0xf1
[92146.548577]  [] ? acpi_os_execute+0x17/0x19
[92146.548582]  [] ? acpi_ec_sync_query+0xa5/0xbc
[92146.548589]  [] acpi_device_notify+0x16/0x18
[92146.548595]  [] acpi_ev_notify_dispatch+0x38/0x4f
[92146.548600]  [] acpi_os_execute_deferred+0x20/0x2b
[92146.548607]  [] process_one_work+0x128/0x3f0
[92146.548613]  [] ? common_interrupt+0x33/0x38
[92146.548618]  [] ? wake_up_worker+0x30/0x30
[92146.548624]  [] ? acpi_os_wait_events_complete+0x1e/0x1e
[92146.548629]  [] worker_thread+0x119/0x3b0
[92146.548634]  [] ? manage_workers+0x240/0x240
[92146.548640]  [] kthread+0x94/0xa0
[92146.548647]  [] ? ftrace_raw_output_sched_stat_runtime+0x70/0xf0
[92146.548652]  [] ret_from_kernel_thread+0x1b/0x28
[92146.548658]  [] ? kthread_create_on_node+0xc0/0xc0

three different modeset flags are introduced in this patch
MODESET_ON_LID: do modeset on next lid open event
MODESET_DONE:  modeset already done
MODESET_ON_RESUME:  do modeset when system is resumed

In this way,
1. when lid is closed, MODESET_ON_LID is set so that
   we'll do modeset on next lid open event.
2. when lid is opened, MODESET_DONE is set
   so that duplicate lid open events will be ignored.
3. when system suspends, MODESET_ON_RESUME is set.
   In this case, we will not do modeset on any lid events.

Plus, locking mechanism is also introduced to avoid racing.

Signed-off-by: Zhang Rui 
---
 drivers/gpu/drm/i915/i915_dma.c   |1 +
 drivers/gpu/drm/i915/i915_drv.c   |   14 +-
 drivers/gpu/drm/i915/i915_drv.h   |   11 +--
 drivers/gpu/drm/i915/intel_lvds.c |   33 -
 4 files changed, 39 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 99daa89..c7cb546 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1585,6 +1585,7 @@ int i915_driver_load(struct drm_device *dev, unsigned 
long flags)
spin_lock_init(_priv->dpio_lock);
 
mutex_init(_priv->rps.hw_lock);
+   mutex_init(_priv->modeset_lock);
 
if (IS_IVYBRIDGE(dev) || IS_HASWELL(dev))
dev_priv->num_pipe = 3;
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 1172658..bd7ab5b 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -468,6 +468,12 @@ static int i915_drm_freeze(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
 
+   /* ignore lid events during 

[PATCH V2 2/3] ACPI: enable ACPI SCI during suspend

[Zhang Rui]

Enable ACPI SCI during suspend so that SCI can be used
as wake events for PM_SUSPEND_FREEZE.

For S3/S4 transition,
We disable all GPEs in suspend_ops->prepare_late() to
fix a problem that GPEs may trigger SCI  before
arch_suspend_disable_irqs() is run.
So it is safe to leave the SCI enabled until
arch_suspend_irq_disable() is run.

Signed-off-by: Zhang Rui 
---
 drivers/acpi/osl.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index 3ff2678..3adeb10 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -787,7 +787,7 @@ acpi_os_install_interrupt_handler(u32 gsi, acpi_osd_handler 
handler,
 
acpi_irq_handler = handler;
acpi_irq_context = context;
-   if (request_irq(irq, acpi_irq, IRQF_SHARED, "acpi", acpi_irq)) {
+   if (request_irq(irq, acpi_irq, IRQF_SHARED | IRQF_NO_SUSPEND, "acpi", 
acpi_irq)) {
printk(KERN_ERR PREFIX "SCI (IRQ%d) allocation failed\n", irq);
acpi_irq_handler = NULL;
return AE_NOT_ACQUIRED;
-- 
1.7.9.5

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

[PATCH V2 1/3] PM: Introduce suspend state PM_SUSPEND_FREEZE

[Zhang Rui]

PM_SUSPEND_FREEZE state is a general state that
does not need any platform specific support, it equals
frozen processes + suspended devices + idle processors.

Compared with PM_SUSPEND_MEMORY,
PM_SUSPEND_FREEZE saves less power
because the system is still in a running state.
PM_SUSPEND_FREEZE has less resume latency because it does not
touch BIOS, and the processors are in idle state.

Compared with RTPM/idle,
PM_SUSPEND_FREEZE saves more power as
1. the processor has longer sleep time because processes are frozen.
   The deeper c-state the processor supports, more power saving we can get.
2. PM_SUSPEND_FREEZE uses system suspend code path, thus we can get
   more power saving from the devices that does not have good RTPM support.

This state is useful for
1) platforms that do not have STR, or have a broken STR.
2) platforms that have an extremely low power idle state,
   which can be used to replace STR.

The following describes how PM_SUSPEND_FREEZE state works.
1. echo freeze > /sys/power/state
2. the processes are frozen.
3. all the devices are suspended.
4. all the processors are blocked by a wait queue
5. all the processors idles and enters (Deep) c-state.
6. an interrupt fires.
7. a processor is woken up and handles the irq.
8. if it is a general event,
   a) the irq handler runs and quites.
   b) goto step 4.
9. if it is a real wake event, say, power button pressing, keyboard touch, 
mouse moving,
   a) the irq handler runs and activate the wakeup source
   b) wakeup_source_activate() notifies the wait queue.
   c) system starts resuming from PM_SUSPEND_FREEZE
10. all the devices are resumed.
11. all the processes are unfrozen.
12. system is back to working.

Known Issue:
The wakeup of this new PM_SUSPEND_FREEZE state may behave differently
from the previous suspend state.
Take ACPI platform for example, there are some GPEs that only enabled
when the system is in sleep state, to wake the system backk from S3/S4.
But we are not touching these GPEs during transition to PM_SUSPEND_FREEZE.
This means we may lose some wake event.
But on the other hand, as we do not disable all the Interrupts during
PM_SUSPEND_FREEZE, we may get some extra "wakeup" Interrupts, that are
not available for S3/S4.

The patches has been tested on an old Sony laptop, and here are the results:

Average Power:
1. RPTM/idle for half an hour:
   14.8W, 12.6W, 14.1W, 12.5W, 14.4W, 13.2W, 12.9W
2. Freeze for half an hour:
   11W, 10.4W, 9.4W, 11.3W 10.5W
3. RTPM/idle for three hours:
   11.6W
4. Freeze for three hours:
   10W
5. Suspend to Memory:
   0.5~0.9W

Average Resume Latency:
1. RTPM/idle with a black screen: (From pressing keyboard to screen back)
   Less than 0.2s
2. Freeze: (From pressing power button to screen back)
   2.50s
3. Suspend to Memory: (From pressing power button to screen back)
   4.33s

>From the results, we can see that all the platforms should benefit from
this patch, even if it does not have Low Power S0.

Signed-off-by: Zhang Rui 
---
 drivers/base/power/wakeup.c |6 
 include/linux/suspend.h |5 +++-
 kernel/power/main.c |2 +-
 kernel/power/suspend.c  |   69 +++
 4 files changed, 67 insertions(+), 15 deletions(-)

diff --git a/drivers/base/power/wakeup.c b/drivers/base/power/wakeup.c
index e6ee5e8..79715e7 100644
--- a/drivers/base/power/wakeup.c
+++ b/drivers/base/power/wakeup.c
@@ -382,6 +382,12 @@ static void wakeup_source_activate(struct wakeup_source 
*ws)
 {
unsigned int cec;
 
+   /*
+* active wakeup source should bring the system
+* out of PM_SUSPEND_FREEZE state
+*/
+   freeze_wake();
+
ws->active = true;
ws->active_count++;
ws->last_time = ktime_get();
diff --git a/include/linux/suspend.h b/include/linux/suspend.h
index 0c808d7..7420ab5 100644
--- a/include/linux/suspend.h
+++ b/include/linux/suspend.h
@@ -34,8 +34,10 @@ static inline void pm_restore_console(void)
 typedef int __bitwise suspend_state_t;
 
 #define PM_SUSPEND_ON  ((__force suspend_state_t) 0)
-#define PM_SUSPEND_STANDBY ((__force suspend_state_t) 1)
+#define PM_SUSPEND_FREEZE  ((__force suspend_state_t) 1)
+#define PM_SUSPEND_STANDBY ((__force suspend_state_t) 2)
 #define PM_SUSPEND_MEM ((__force suspend_state_t) 3)
+#define PM_SUSPEND_MIN PM_SUSPEND_FREEZE
 #define PM_SUSPEND_MAX ((__force suspend_state_t) 4)
 
 enum suspend_stat_step {
@@ -192,6 +194,7 @@ struct platform_suspend_ops {
  */
 extern void suspend_set_ops(const struct platform_suspend_ops *ops);
 extern int suspend_valid_only_mem(suspend_state_t state);
+extern void freeze_wake(void);
 
 /**
  * arch_suspend_disable_irqs - disable IRQs for suspend
diff --git a/kernel/power/main.c b/kernel/power/main.c
index 1c16f91..b1c26a9 100644
--- a/kernel/power/main.c
+++ b/kernel/power/main.c
@@ -313,7 +313,7 @@ static ssize_t state_show(struct kobject *kobj, struct 
kobj_attribute *attr,
 static 

Re: [PATCH v5 09/10] clk: tegra: Implement clocks for Tegra114

[Prashant Gaikwad]

On Friday 01 February 2013 03:48 PM, Peter De Schrijver wrote:

Implement most clocks for Tegra114. The super clocks for the CPU complex
are still missing and will be implemented in a future version.

Signed-off-by: Peter De Schrijver 
---
  drivers/clk/tegra/Makefile   |1 +
  drivers/clk/tegra/clk-tegra114.c | 2002 ++
  2 files changed, 2003 insertions(+), 0 deletions(-)
  create mode 100644 drivers/clk/tegra/clk-tegra114.c

diff --git a/drivers/clk/tegra/Makefile b/drivers/clk/tegra/Makefile
index 2b41b0f..f49fac2 100644
--- a/drivers/clk/tegra/Makefile
+++ b/drivers/clk/tegra/Makefile
@@ -9,3 +9,4 @@ obj-y   += clk-super.o

  obj-$(CONFIG_ARCH_TEGRA_2x_SOC) += clk-tegra20.o
  obj-$(CONFIG_ARCH_TEGRA_3x_SOC) += clk-tegra30.o
+obj-$(CONFIG_ARCH_TEGRA_114_SOC)   += clk-tegra114.o
diff --git a/drivers/clk/tegra/clk-tegra114.c b/drivers/clk/tegra/clk-tegra114.c
new file mode 100644
index 000..f8165d2
--- /dev/null
+++ b/drivers/clk/tegra/clk-tegra114.c
@@ -0,0 +1,2002 @@
+/*
+ * Copyright (c) 2012, 2013, NVIDIA CORPORATION.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "clk.h"
+
+#define RST_DEVICES_L  0x004
+#define RST_DEVICES_H  0x008
+#define RST_DEVICES_U  0x00C
+#define RST_DEVICES_V  0x358
+#define RST_DEVICES_W  0x35C
+#define RST_DEVICES_X  0x28C
+#define RST_DEVICES_SET_L  0x300
+#define RST_DEVICES_CLR_L  0x304
+#define RST_DEVICES_SET_H  0x308
+#define RST_DEVICES_CLR_H  0x30c
+#define RST_DEVICES_SET_U  0x310
+#define RST_DEVICES_CLR_U  0x314
+#define RST_DEVICES_SET_V  0x430
+#define RST_DEVICES_CLR_V  0x434
+#define RST_DEVICES_SET_W  0x438
+#define RST_DEVICES_CLR_W  0x43c
+#define RST_DEVICES_NUM5


RST_DEVICES_SET/CLR_X?


+
+#define CLK_OUT_ENB_L  0x010
+#define CLK_OUT_ENB_H  0x014
+#define CLK_OUT_ENB_U  0x018
+#define CLK_OUT_ENB_V  0x360
+#define CLK_OUT_ENB_W  0x364
+#define CLK_OUT_ENB_X  0x280
+#define CLK_OUT_ENB_SET_L  0x320
+#define CLK_OUT_ENB_CLR_L  0x324
+#define CLK_OUT_ENB_SET_H  0x328
+#define CLK_OUT_ENB_CLR_H  0x32c
+#define CLK_OUT_ENB_SET_U  0x330
+#define CLK_OUT_ENB_CLR_U  0x334
+#define CLK_OUT_ENB_SET_V  0x440
+#define CLK_OUT_ENB_CLR_V  0x444
+#define CLK_OUT_ENB_SET_W  0x448
+#define CLK_OUT_ENB_CLR_W  0x44c
+#define CLK_OUT_ENB_SET_X  0x284
+#define CLK_OUT_ENB_CLR_X  0x288
+#define CLK_OUT_ENB_NUM6





+
+   /* dsia */
+   clk = clk_register_mux(NULL, "dsia_mux", mux_plld_out0_plld2_out0,
+  ARRAY_SIZE(mux_plld_out0_plld2_out0), 0,
+  clk_base + PLLD_BASE, 25, 1, 0, _d_lock);
+   clks[dsia_mux] = clk;
+   clk = tegra_clk_register_periph_gate("dsia", "dsia_mux", 0, clk_base,
+   0, 48, _h_regs,
+   periph_clk_enb_refcnt);
+   clk_register_clkdev(clk, "dsia", "tegradc.0");
+   clks[dsia] = clk;
+
+   /* dsib */
+   clk = clk_register_mux(NULL, "dsib_mux", mux_plld_out0_plld2_out0,
+  ARRAY_SIZE(mux_plld_out0_plld2_out0), 0,
+  clk_base + PLLD2_BASE, 25, 1, 0, _d2_lock);
+   clks[dsib_mux] = clk;
+   clk = tegra_clk_register_periph_gate("dsib", "dsib_mux", 0, clk_base,
+   0, 82, _u_regs,
+   periph_clk_enb_refcnt);
+   clk_register_clkdev(clk, "dsib", "tegradc.1");
+   clks[dsib] = clk;
+


Can we use periph no div clock here for dsia and dsib?


+   /* xusb_hs_src */
+   val = readl(clk_base + CLK_SOURCE_XUSB_SS_SRC);
+   val |= BIT(25); /* always select PLLU_60M */
+   writel(val, clk_base + CLK_SOURCE_XUSB_SS_SRC);
+
+   clk = clk_register_fixed_factor(NULL, "xusb_hs_src", "pll_u_60M", 

Re: 3.8-rc regression with pps-ldisc due to 70ece7a731

[George Spelvin]

Just a quick update: the previously posted patch *does* work;
the crash I was experiencing was pilot error.

My NTP server is running a 3.8.0-rc6-dirty kernel right now.

I'll research whether that race I talk about in pps_tty_dcd_change
is actually possible or not (can interrupts start arriving before the
->open() method returns?) and work out a finished minimal bugfix patch
if nobody else finds a better solution.

Sorry for the delay tracking this down; I've known about the crash
for a week or so now, but was short of around tuitts to track it down.

(Have I mentioned how ANNOYING it is when the kernel dumps more than
50 lines of crash message to the console screen and then locks
the keyboard so I can't scroll back?)
--
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: [Linaro-mm-sig] [PATCH 6/7] reservation: cross-device reservation support

[Inki Dae]

> +/**
> + * ticket_commit - commit a reservation with a new fence
> + * @ticket:[in]the reservation_ticket returned by
> + * ticket_reserve
> + * @entries:   [in]a linked list of struct reservation_entry
> + * @fence: [in]the fence that indicates completion
> + *
> + * This function will call reservation_ticket_fini, no need
> + * to do it manually.
> + *
> + * This function should be called after a hardware command submission is
> + * completed succesfully. The fence is used to indicate completion of
> + * those commands.
> + */
> +void
> +ticket_commit(struct reservation_ticket *ticket,
> + struct list_head *entries, struct fence *fence)
> +{
> +   struct list_head *cur;
> +
> +   if (list_empty(entries))
> +   return;
> +
> +   if (WARN_ON(!fence)) {
> +   ticket_backoff(ticket, entries);
> +   return;
> +   }
> +
> +   list_for_each(cur, entries) {
> +   struct reservation_object *bo;
> +   bool shared;
> +
> +   reservation_entry_get(cur, , );
> +
> +   if (!shared) {
> +   int i;
> +   for (i = 0; i < bo->fence_shared_count; ++i) {
> +   fence_put(bo->fence_shared[i]);
> +   bo->fence_shared[i] = NULL;
> +   }
> +   bo->fence_shared_count = 0;
> +   if (bo->fence_excl)
> +   fence_put(bo->fence_excl);
> +
> +   bo->fence_excl = fence;
> +   } else {
> +   if (WARN_ON(bo->fence_shared_count >=
> +   ARRAY_SIZE(bo->fence_shared))) {
> +   mutex_unreserve_unlock(>lock);
> +   continue;
> +   }
> +
> +   bo->fence_shared[bo->fence_shared_count++] = fence;
> +   }

Hi,

I got some questions to fence_excl and fence_shared. At the above
code, if bo->fence_excl is not NULL then it puts bo->fence_excl and
sets a new fence to it. This seems like that someone that committed a
new fence, wants to access the given dmabuf exclusively even if
someone is accessing the given dmabuf.

On the other hand, in case of fence_shared, someone wants to access
that dmabuf non-exclusively. So this case seems like that the given
dmabuf could be accessed by two more devices. So I guess that the
fence_excl could be used for write access(may need buffer sync like
blocking) and read access for the fence_shared(may not need buffer
sync). I'm not sure that I understand these two things correctly so
could you please give me more comments for them?

Thanks,
Inki Dae

> +   fence_get(fence);
> +
> +   mutex_unreserve_unlock(>lock);
> +   }
> +   reservation_ticket_fini(ticket);
> +}
> +EXPORT_SYMBOL(ticket_commit);
--
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 akpm tree with the tip tree

[Stephen Rothwell]

Hi Andrew,

Today's linux-next merge of the akpm tree got a conflict in
arch/x86/mm/numa.c between commit 07f4207a305c ("x86-32, mm: Remove
reference to alloc_remap()") from the tip tree and commit "x86: get
pg_data_t's memory from other node" from the akpm tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

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

diff --cc arch/x86/mm/numa.c
index a8483df,245a4ba..000
--- a/arch/x86/mm/numa.c
+++ b/arch/x86/mm/numa.c
@@@ -209,22 -213,27 +209,21 @@@ static void __init setup_node_data(int 
   nid, start, end - 1);
  
/*
 -   * Allocate node data.  Try remap allocator first, node-local
 -   * memory and then any node.  Never allocate in DMA zone.
 +   * Allocate node data.  Try node-local memory and then any node.
 +   * Never allocate in DMA zone.
 */
-   nd_pa = memblock_alloc_nid(nd_size, SMP_CACHE_BYTES, nid);
 -  nd = alloc_remap(nid, nd_size);
 -  if (nd) {
 -  nd_pa = __phys_addr_nodebug(nd);
 -  remapped = true;
 -  } else {
 -  nd_pa = memblock_alloc_try_nid(nd_size, SMP_CACHE_BYTES, nid);
 -  if (!nd_pa) {
 -  pr_err("Cannot find %zu bytes in any node\n", nd_size);
 -  return;
 -  }
 -  nd = __va(nd_pa);
++  nd_pa = memblock_alloc_try_nid(nd_size, SMP_CACHE_BYTES, nid);
 +  if (!nd_pa) {
-   pr_err("Cannot find %zu bytes in node %d\n",
-  nd_size, nid);
++  pr_err("Cannot find %zu bytes in any node\n", nd_size);
 +  return;
}
 +  nd = __va(nd_pa);
  
/* report and initialize */
 -  printk(KERN_INFO "  NODE_DATA [mem %#010Lx-%#010Lx]%s\n",
 - nd_pa, nd_pa + nd_size - 1, remapped ? " (remapped)" : "");
 +  printk(KERN_INFO "  NODE_DATA [mem %#010Lx-%#010Lx]\n",
 + nd_pa, nd_pa + nd_size - 1);
tnid = early_pfn_to_nid(nd_pa >> PAGE_SHIFT);
 -  if (!remapped && tnid != nid)
 +  if (tnid != nid)
printk(KERN_INFO "NODE_DATA(%d) on node %d\n", nid, tnid);
  
node_data[nid] = nd;


pgpqr3Y13V295.pgp
Description: PGP signature

RE: [PATCH] x86/apic: check FADT settings after enable x2apic

[Wang, Song-Bo (Stoney)]

 * Ingo Molnar  wrote:
> 
> * Yinghai Lu  wrote:
> 
> > Please check attached.
> 
> Almost good.
> 
> This:
> 
>   > When some HP sytems boot without x2apic_phys, there will be
> 
> Should mention the approximate models of the systems affected - is it
> just a specific line of systems, or a wider range of systems affected?
> 
> This will inform users and will help maintainers like me to prioritize
> the merging and backporting of patches.
> 
> Thanks,
> 
>   Ingo

Hi Ingo,

Due to some HW limitation, HP ProLiant DL980 G7 Server has the BIT 
ACPI_FADT_APIC_PHYSICAL set in BIOS.

This model of systems already shipped. It is great if some backporting could be 
done.

Thanks,

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

Re: [PATCH V3] regulator: add device tree support for s5m8767

[Sachin Kamat]

On 4 February 2013 05:19, Amit Daniel Kachhap  wrote:
> This device tree support is added for PMIC block of S5m8767 multi
> function driver. The usage detail is added in the device tree
> documentation section. This change is tested on exynos5250 based
> arndale platform by regulator voltage set/get API's.
>
> Reviewed-by: Thomas Abraham 
> Signed-off-by: Amit Daniel Kachhap 

Tested this patch using [1] on Exynos4412 based Origen board and it works fine.
Feel free to add Tested-by: Sachin Kamat  if needed.

[1] http://patches.linaro.org/14445/

-- 
With warm regards,
Sachin
--
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 v5 08/10] ARM: dt: Add references to tegra_car clocks

[Prashant Gaikwad]

On Friday 01 February 2013 03:48 PM, Peter De Schrijver wrote:

Add references to tegra_car clocks for the basic device nodes.

Signed-off-by: Peter De Schrijver 
---


Reviewed-by: Prashant Gaikwad 


  arch/arm/boot/dts/tegra114.dtsi |7 ++-
  1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/arch/arm/boot/dts/tegra114.dtsi b/arch/arm/boot/dts/tegra114.dtsi
index 96a8235..1dec620 100644
--- a/arch/arm/boot/dts/tegra114.dtsi
+++ b/arch/arm/boot/dts/tegra114.dtsi
@@ -27,7 +27,7 @@
};
  
  	tegra_car: clock {

-   compatible = "nvidia,tegra114-car, nvidia,tegra30-car";
+   compatible = "nvidia,tegra114-car";
reg = <0x60006000 0x1000>;
#clock-cells = <1>;
};
@@ -43,6 +43,7 @@
reg-shift = <2>;
interrupts = <0 36 0x04>;
status = "disabled";
+   clocks = <_car 6>;
};
  
  	serial@70006040 {

@@ -51,6 +52,7 @@
reg-shift = <2>;
interrupts = <0 37 0x04>;
status = "disabled";
+   clocks = <_car 192>;
};
  
  	serial@70006200 {

@@ -59,6 +61,7 @@
reg-shift = <2>;
interrupts = <0 46 0x04>;
status = "disabled";
+   clocks = <_car 55>;
};
  
  	serial@70006300 {

@@ -67,12 +70,14 @@
reg-shift = <2>;
interrupts = <0 90 0x04>;
status = "disabled";
+   clocks = <_car 65>;
};
  
  	rtc {

compatible = "nvidia,tegra114-rtc", "nvidia,tegra20-rtc";
reg = <0x7000e000 0x100>;
interrupts = <0 2 0x04>;
+   clocks = <_car 4>;
};
  
  	pmc {




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

Re: [PATCH 0/3] Enable multiple MSI feature in pSeries

[Mike Qiu]

2013/2/4 13:56, Michael Ellerman:

On Mon, 2013-02-04 at 11:49 +0800, Mike Qiu wrote:

On Tue, 2013-01-15 at 15:38 +0800, Mike Qiu wrote:

Currently, multiple MSI feature hasn't been enabled in pSeries,
These patches try to enbale this feature.

Hi Mike,


These patches have been tested by using ipr driver, and the driver patch
has been made by Wen Xiong :

So who wrote these patches? Normally we would expect the original author
to post the patches if at all possible.

Hi Michael

These Multiple MSI patches were wrote by myself, you know this feature
has not enabled
and it need device driver to test whether it works suitable. So I test
my patches use
Wen Xiong's ipr patches, which has been send out to the maillinglist.

I'm the original author :)

Ah OK, sorry, that was more or less clear from your mail but I just
misunderstood.


[PATCH 0/7] Add support for new IBM SAS controllers

I would like to see the full series, including the driver enablement.

Yep, but the driver patches were wrote by Wen Xiong and has been send
out.

OK, you mean this series?

http://thread.gmane.org/gmane.linux.scsi/79639

Yes, exactly.




I just use her patches to test my patches. all device support Multiple
MSI can use my feature not only IBM SAS controllers, I also test my
patches use the broadcom wireless card tg3, and also works OK.

You mean drivers/net/ethernet/broadcom/tg3.c ? I don't see where it
calls pci_enable_msi_block() ?

Yes, I just modify the driver to support mutiple MSI.


All devices /can/ use it, but the driver needs to be updated. Currently
we have two drivers that do so (in Linus' tree), plus the updated IPR.

Not all devices, just the device which support the multiple MSI by hardware,
can use it



Test platform: One partition of pSeries with one cpu core(4 SMTs) and
RAID bus controller: IBM PCI-E IPR SAS Adapter (ASIC) in POWER7
OS version: SUSE Linux Enterprise Server 11 SP2  (ppc64) with 3.8-rc3 kernel

IRQ 21 and 22 are assigned to the ipr device which support 2 mutiple MSI.

The test results is shown by 'cat /proc/interrups':
   CPU0   CPU1   CPU2   CPU3
21:  6  5  5  5  XICS Level host1-0
22:817814816813  XICS Level host1-1

This shows that you are correctly configuring two MSIs.

But the key advantage of using multiple interrupts is to distribute load
across CPUs and improve performance. So I would like to see some
performance numbers that show that there is a real benefit for all the
extra complexity in the code.

Yes, the system just has suport two MSIs. Anyway, I will try to do
some proformance test, to show the real benefit.
But actually it needs the driver to do so. As the data show above, it
seems there is some problems in use the interrupt, the irq 21 use few,
most use 22, I will discuss with the driver author to see why and if
she fixed, I will give out the proformance result.

Yeah that would be good.

I really dislike that we have a separate API for multi-MSI vs MSI-X, and
pci_enable_msi_block() also pushes the contiguous power-of-2 allocation
into the irq domain layer, which is unpleasant. So if we really must do
multi-MSI I would like to do it differently.
Yes, but the multi-MSI must need the hardware support, it is one extend 
for MSI,

The device may sopport MSI and multiple MSI, but not support MSI-X.
for these devices, we'd better use multiple MSI to makes it more efficiency,
compare with MSI.

multi-MSI just can use no more than 32 interrupts

Thanks


cheers




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

[RESEND PATCH 3/4] kdump, s390: make saved_max_pfn exclusive

[HATAYAMA Daisuke]

Signed-off-by: HATAYAMA Daisuke 
---

 arch/s390/kernel/setup.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/s390/kernel/setup.c b/arch/s390/kernel/setup.c
index a5360de..3357566 100644
--- a/arch/s390/kernel/setup.c
+++ b/arch/s390/kernel/setup.c
@@ -729,9 +729,9 @@ static void reserve_oldmem(void)
reserve_kdump_bootmem(OLDMEM_SIZE, memory_end - OLDMEM_SIZE,
  CHUNK_OLDMEM);
if (OLDMEM_BASE + OLDMEM_SIZE == real_memory_size)
-   saved_max_pfn = PFN_DOWN(OLDMEM_BASE) - 1;
+   saved_max_pfn = PFN_DOWN(OLDMEM_BASE);
else
-   saved_max_pfn = PFN_DOWN(real_memory_size) - 1;
+   saved_max_pfn = PFN_DOWN(real_memory_size);
 #endif
 }
 

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

[RESEND PATCH 4/4] kdump, oldmem: compare with saved_max_pfn exclusively

[HATAYAMA Daisuke]

Signed-off-by: HATAYAMA Daisuke 
---

 drivers/char/mem.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/char/mem.c b/drivers/char/mem.c
index c6fa3bc..5da737c 100644
--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@ -369,7 +369,7 @@ static ssize_t read_oldmem(struct file *file, char __user 
*buf,
 
while (count) {
pfn = *ppos / PAGE_SIZE;
-   if (pfn > saved_max_pfn)
+   if (!(pfn < saved_max_pfn))
return read;
 
offset = (unsigned long)(*ppos % PAGE_SIZE);

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

[RESEND PATCH 1/4] kdump, mips: make saved_max_pfn exclusive

[HATAYAMA Daisuke]

Signed-off-by: HATAYAMA Daisuke 
---

 arch/mips/kernel/crash_dump.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/mips/kernel/crash_dump.c b/arch/mips/kernel/crash_dump.c
index 35bed0d..6621211 100644
--- a/arch/mips/kernel/crash_dump.c
+++ b/arch/mips/kernel/crash_dump.c
@@ -6,7 +6,7 @@
 static int __init parse_savemaxmem(char *p)
 {
if (p)
-   saved_max_pfn = (memparse(p, ) >> PAGE_SHIFT) - 1;
+   saved_max_pfn = (memparse(p, ) >> PAGE_SHIFT);
 
return 1;
 }

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

[RESEND PATCH 2/4] kdump, ppc: make saved_max_pfn exclusive

[HATAYAMA Daisuke]

Signed-off-by: HATAYAMA Daisuke 
---

 arch/powerpc/kernel/crash_dump.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/kernel/crash_dump.c b/arch/powerpc/kernel/crash_dump.c
index b3ba516..fa64170 100644
--- a/arch/powerpc/kernel/crash_dump.c
+++ b/arch/powerpc/kernel/crash_dump.c
@@ -72,7 +72,7 @@ void __init setup_kdump_trampoline(void)
 static int __init parse_savemaxmem(char *p)
 {
if (p)
-   saved_max_pfn = (memparse(p, ) >> PAGE_SHIFT) - 1;
+   saved_max_pfn = (memparse(p, ) >> PAGE_SHIFT);
 
return 1;
 }

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

[RESEND PATCH 0/4] kdump: make saved_max_pfn exlusive

[HATAYAMA Daisuke]

# I emailed to Vivek at old email address so resend. Please reply to
# this RESEND patch series. Sorry for this noise...

First, there are two kinds of notation to represent a map: inclusive
and exclusive. Here are the examples:

  1)  [mem 0x0001-0x00013fff]
  2)  [mem 0x0001-0x00014000]

1) is inclusive and 2) is exclusive. In case of 1), the pfn calculated
from the end address belongs to the map, while in case of 2), it
doesn't.

Currently, saved_max_pfn is used in read_oldmem() as inclusive for a
check to see if a given request is to within kernel's memory mapping
regions.

while (count) {
pfn = *ppos / PAGE_SIZE;
if (pfn > saved_max_pfn)
return read;

Unfortunately, on x86 and ia64, there are bugs below:

- On the 1st kernel, saved_max_pfn is not initialized so 0. Then, read
  to pfn 0 is not guarded by the condition and the execution goes into
  ioremap path.

- On the 2nd kernel, x86 and ia64 wrongly initializes saved_max_pfn by
  exclusive value, on x86 as:

saved_max_pfn = e820_end_of_ram_pfn();

  by which via /dev/oldmem we can read max_pfn that is not kernel's
  memory.

To fix this, fixing x86 and ia64 part needs smaller change, but
max_pfn is originally treated as exclusive so saved_max_pfn should
normally be exclusive. Also, the memory map information passed from
kexec is all exclusive on every architectures; it's possible to make
saved_max_pfn exclusive now.

However, ppc and ppc64 on kexec doesn't increment end address now and
this should be done as an insurance when map passed from firmware is
inclusive, for which I'll post a patch later.

---

HATAYAMA Daisuke (4):
  kdump, oldmem: compare with saved_max_pfn exclusively
  kdump, s390: make saved_max_pfn exclusive
  kdump, ppc: make saved_max_pfn exclusive
  kdump, mips: make saved_max_pfn exclusive


 arch/mips/kernel/crash_dump.c|2 +-
 arch/powerpc/kernel/crash_dump.c |2 +-
 arch/s390/kernel/setup.c |4 ++--
 drivers/char/mem.c   |2 +-
 4 files changed, 5 insertions(+), 5 deletions(-)

-- 

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

RE: [PATCH v4 4/4] PM: Devfreq: Add Exynos5-bus devfreq driver for Exynos5250

[myungjoo.ham]

> 
> 
> -Original Message-
> From: Abhilash Kesavan [mailto:kesavan.abhil...@gmail.com] 
> Sent: Monday, February 04, 2013 12:48 AM
> To: myungjoo@samsung.com; linux-kernel@vger.kernel.org;
linux...@vger.kernel.org; kgene@samsung.com
> Cc: kyungmin.p...@samsung.com; r...@sisk.pl; jhbird.c...@samsung.com
> Subject: Re: [PATCH v4 4/4] PM: Devfreq: Add Exynos5-bus devfreq driver
for Exynos5250
> 
> Hi Myungjoo,
> 
> Any comments on this patch ?
> 
> Abhilash
> 


Sorry for being late.

One concern is that I cannot apply Patch 1/4 directly as the .dts file isn't
available to me.
Do you intend to apply that patch to another tree and apply the other three
to devfreq tree?

Another is the location of exynos_ppmu.h.
Who is going to refer exynos_ppmu.h?
If Exynos devfreq drivers are the only files to refer, wouldn't it be better
located at drivers/devfreq/exynos/ ?

Or do you intend to let someone else (drivers located not in
drivers/devfreq) access exynos-ppmu?
(If so, who's going to be? and that means we are going to have
include/linux/devfreq/, I don't think it'd be appropriate to populate
include/linux with device driver specific headers)



And, there are errors (we do not have __devinit/__devexit anymore):

  CC  drivers/devfreq/exynos/exynos5_bus.o
drivers/devfreq/exynos/exynos5_bus.c:315:18: error: expected =, ,, ;, asm or
__attribute__ before int
drivers/devfreq/exynos/exynos5_bus.c:430:18: error: expected =, ,, ;, asm or
__attribute__ before int
drivers/devfreq/exynos/exynos5_bus.c:462:11: error:
exynos5_busfreq_int_probe undeclared here (not in a function)
drivers/devfreq/exynos/exynos5_bus.c:463:2: error: implicit declaration of
function __devexit_p [-Werror=implicit-function-declaration]
drivers/devfreq/exynos/exynos5_bus.c:463:24: error:
exynos5_busfreq_int_remove undeclared here (not in a function)
drivers/devfreq/exynos/exynos5_bus.c:235:35: warning:
exynos5_devfreq_int_profile defined but not used [-Wunused-variable]
drivers/devfreq/exynos/exynos5_bus.c:243:12: warning:
exynos5250_init_int_tables defined but not used [-Wunused-function]
drivers/devfreq/exynos/exynos5_bus.c:259:12: warning:
exynos5_busfreq_int_pm_notifier_event defined but not used
[-Wunused-function]
cc1: some warnings being treated as errors



Cheers,
MyungJoo.


> On Fri, Jan 18, 2013 at 6:54 PM, Abhilash Kesavan 
wrote:
> > Exynos5-bus device devfreq driver monitors PPMU counters and adjusts 
> > operating frequencies and voltages with OPP. ASV should be used to 
> > provide appropriate voltages as per the speed group of the SoC rather 
> > than using a constant 1.025V.
> >
> > Signed-off-by: Abhilash Kesavan 
> > Cc: Jonghwan Choi 
> > Cc: Kukjin Kim 
> > ---
> > Changes since RFC v1:
> > * Moved the Exynos5 PPMU driver to machine specific directory
> > * Migrated to the PM QOS framework
> > Changes since v2:
> > * Moved the PPMU driver to drivers/devfreq/exynos
> > * Fixed whitespace, commenting, empty lines in PPMU driver Changes 
> > since v3:
> > * Removed the custom devfreq monitor and PPMU polling function
> > * Moved exynos5 PPMU access functions to the devfreq driver
> >
> >  drivers/devfreq/Kconfig  |   10 +
> >  drivers/devfreq/Makefile |1 +
> >  drivers/devfreq/exynos/Makefile  |1 +
> >  drivers/devfreq/exynos/exynos5_bus.c |  502
++
> >  drivers/devfreq/exynos/exynos_ppmu.c |   55 
> >  include/linux/exynos_ppmu.h  |   79 ++
> >  6 files changed, 648 insertions(+), 0 deletions(-)  create mode 
> > 100644 drivers/devfreq/exynos/exynos5_bus.c
> >  create mode 100644 drivers/devfreq/exynos/exynos_ppmu.c
> >  create mode 100644 include/linux/exynos_ppmu.h
> >

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

Re: [PATCH v5 06/10] clk: tegra: Workaround for Tegra114 MSENC problem

[Prashant Gaikwad]

On Friday 01 February 2013 03:48 PM, Peter De Schrijver wrote:

Workaround a hardware bug in MSENC during clock enable.

Signed-off-by: Peter De Schrijver 
---
  drivers/clk/tegra/clk-periph-gate.c |9 +
  drivers/clk/tegra/clk.h |1 +
  2 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/drivers/clk/tegra/clk-periph-gate.c 
b/drivers/clk/tegra/clk-periph-gate.c
index 6dd5332..c9083fb 100644
--- a/drivers/clk/tegra/clk-periph-gate.c
+++ b/drivers/clk/tegra/clk-periph-gate.c
@@ -43,6 +43,8 @@ static DEFINE_SPINLOCK(periph_ref_lock);
  
  #define periph_clk_to_bit(periph) (1 << (gate->clk_num % 32))
  
+#define LVL2_CLK_GATE_OVRE 0x554

+
  /* Peripheral gate clock ops */
  static int clk_periph_is_enabled(struct clk_hw *hw)
  {
@@ -83,6 +85,13 @@ static int clk_periph_enable(struct clk_hw *hw)
}
}
  
+	if (gate->flags & TEGRA_PERIPH_WAR_1005168) {

+   writel_relaxed(0, gate->clk_base + LVL2_CLK_GATE_OVRE);
+   writel_relaxed(BIT(22), gate->clk_base + LVL2_CLK_GATE_OVRE);
+   udelay(1);
+   writel_relaxed(0, gate->clk_base + LVL2_CLK_GATE_OVRE);
+   }
+
spin_unlock_irqrestore(_ref_lock, flags);
  
  	return 0;

diff --git a/drivers/clk/tegra/clk.h b/drivers/clk/tegra/clk.h
index 79f5e2a..8756d9f 100644
--- a/drivers/clk/tegra/clk.h
+++ b/drivers/clk/tegra/clk.h
@@ -371,6 +371,7 @@ struct tegra_clk_periph_gate {
  #define TEGRA_PERIPH_NO_RESET BIT(0)
  #define TEGRA_PERIPH_MANUAL_RESET BIT(1)
  #define TEGRA_PERIPH_ON_APB BIT(2)
+#define TEGRA_PERIPH_WAR_1005168 BIT(3)
  


Comment for this flag, otherwise

Reviewed-by: Prashant Gaikwad 


  void tegra_periph_reset(struct tegra_clk_periph_gate *gate, bool assert);
  extern const struct clk_ops tegra_clk_periph_gate_ops;



--
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: [PATCHv2 0/9] Thermal Framework Enhancements

[R, Durgadoss]

Hi Wei,

> -Original Message-
> From: linux-pm-ow...@vger.kernel.org [mailto:linux-pm-
> ow...@vger.kernel.org] On Behalf Of Wei Ni
> Sent: Monday, February 04, 2013 11:10 AM
> To: R, Durgadoss
> Cc: Zhang, Rui; linux...@vger.kernel.org; linux-kernel@vger.kernel.org;
> eduardo.valen...@ti.com; hongbo.zh...@linaro.org
> Subject: Re: [PATCHv2 0/9] Thermal Framework Enhancements
> 
> On 01/07/2013 03:13 PM, Durgadoss R wrote:
> > This patch set is a v2 of the previous versions submitted here:
> > [v1]:  https://lkml.org/lkml/2012/12/18/108
> > [RFC]: https://patchwork.kernel.org/patch/1758921/
> >
> > This patch set is based on Rui's -thermal tree, and is
> > tested on a Core-i5 and an Atom netbook.
> >
> > Changes Since v1:
> >  * Removed kobject creation for thermal_trip and thermal_map
> >nodes as per Greg-KH's comments.
> >  * Added ABI Documentation under 'testing'.
> >  * Modified the GET_INDEX macro to be more linux-like, thanks
> >to Joe Perches.
> >  * Added get_[sensor/cdev]_by_name APIs to thermal.h
> 
> Hi, Durgadoss and Rui
> Will these patches be merged to next branch? or will you send out next
> version?

Yes, I have to send the v3, with some small changes on the patch 5/9
(map sysfs node..) and others won't have any changes.

> I wish to use this new framework, could I send out patches for RFC based
> on this serial patches?

So, if your patch set does not need 5/9, you can send your RFC.

Thanks,
Durga

> 
> Thanks.
> Wei.
> 
> >
> > This series contains 9 patches:
> > Patch 1/9: Creates new sensor level APIs
> > Patch 2/9: Creates new zone level APIs. The existing tzd structure is
> >kept as such for clarity and compatibility purposes.
> > Patch 3/9: Creates functions to add/remove a cdev to/from a zone. The
> >existing tcd structure need not be modified.
> > Patch 4/9: Adds sensorX_trip_[active/passive/hot/critical] sysfs nodes,
> >under /sys/class/thermal/zoneY/. This exposes various trip
> >points for sensorX present in zoneY.
> > Patch 5/9: Adds mapX sysfs node. It is a compact representation
> >of the binding relationship between a sensor and a cdev,
> >within a zone.
> > Patch 6/9: Creates Documentation for the new APIs. A new file is
> >created for clarity. Final goal is to merge with the existing
> >file or refactor the files, as whatever seems appropriate.
> > Patch 7/9: Make PER ZONE values configurable through Kconfig
> > Patch 8/9: Add ABI documentation for sysfs interfaces introduced in this
> patch.
> > Patch 9/9: A dummy driver that can be used for testing. This is not for
> merge.
> >
> > Thanks to Greg-KH, Hongbo Zhang and Joe Perches for their comments on
> v1.
> >
> > Durgadoss R (9):
> >   Thermal: Create sensor level APIs
> >   Thermal: Create zone level APIs
> >   Thermal: Add APIs to bind cdev to new zone structure
> >   Thermal: Add trip point sysfs nodes for sensor
> >   Thermal: Create 'mapX' sysfs node for a zone
> >   Thermal: Add Documentation to new APIs
> >   Thermal: Make PER_ZONE values configurable
> >   Thermal: Add ABI Documentation for sysfs interfaces
> >   Thermal: Dummy driver used for testing
> >
> >  Documentation/ABI/testing/sysfs-class-thermal |   93 +++
> >  Documentation/thermal/sysfs-api2.txt  |  248 +++
> >  drivers/thermal/Kconfig   |   19 +
> >  drivers/thermal/Makefile  |3 +
> >  drivers/thermal/thermal_sys.c |  881
> +
> >  drivers/thermal/thermal_test.c|  315 +
> >  include/linux/thermal.h   |  117 +++-
> >  7 files changed, 1675 insertions(+), 1 deletion(-)
> >  create mode 100644 Documentation/ABI/testing/sysfs-class-thermal
> >  create mode 100644 Documentation/thermal/sysfs-api2.txt
> >  create mode 100644 drivers/thermal/thermal_test.c
> >
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: manual merge of the signal tree with the mips tree

[Stephen Rothwell]

Hi Al,

Today's linux-next merge of the signal tree got a conflict in
arch/mips/kernel/syscall.c between commit 7034228792cc ("MIPS: Whitespace
cleanup") from the mips tree and commit 50150d2bb903 ("mips: switch to
generic sys_fork() and sys_clone()") from the signal tree.

I fixed it up (the sys_clone stuff was removed by the latter - see below)
and can carry the fix as necessary (no action is required).

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

diff --cc arch/mips/kernel/syscall.c
index d7feee0,b32466a..000
--- a/arch/mips/kernel/syscall.c
+++ b/arch/mips/kernel/syscall.c
@@@ -41,25 -41,19 +41,19 @@@
  
  /*
   * For historic reasons the pipe(2) syscall on MIPS has an unusual calling
 - * convention.  It returns results in registers $v0 / $v1 which means there
 + * convention.It returns results in registers $v0 / $v1 which means 
there
   * is no need for it to do verify the validity of a userspace pointer
 - * argument.  Historically that used to be expensive in Linux.  These days
 + * argument.  Historically that used to be expensive in Linux.These 
days
   * the performance advantage is negligible.
   */
- asmlinkage int sysm_pipe(nabi_no_regargs volatile struct pt_regs regs)
+ asmlinkage int sysm_pipe(void)
  {
int fd[2];
-   int error, res;
- 
-   error = do_pipe_flags(fd, 0);
-   if (error) {
-   res = error;
-   goto out;
-   }
-   regs.regs[3] = fd[1];
-   res = fd[0];
- out:
-   return res;
+   int error = do_pipe_flags(fd, 0);
+   if (error)
+   return error;
+   current_pt_regs()->regs[3] = fd[1];
+   return fd[0];
  }
  
  SYSCALL_DEFINE6(mips_mmap, unsigned long, addr, unsigned long, len,


pgpPcXS6JyfQi.pgp
Description: PGP signature

Re: [PATCH v5 04/10] clk: tegra: Add new fields and PLL types for Tegra114

[Prashant Gaikwad]

On Saturday 02 February 2013 01:10 AM, Rhyland Klein wrote:

On 2/1/2013 5:18 AM, Peter De Schrijver wrote:

Tegra114 introduces new PLL types. This requires new clocktypes as well
as some new fields in the pll structure.

Signed-off-by: Peter De Schrijver 
---
   drivers/clk/tegra/clk-pll.c |  719 
+++
   drivers/clk/tegra/clk.h |   47 +++
   2 files changed, 766 insertions(+), 0 deletions(-)

diff --git a/drivers/clk/tegra/clk-pll.c b/drivers/clk/tegra/clk-pll.c
index 87d2f34..50114b7 100644
--- a/drivers/clk/tegra/clk-pll.c
+++ b/drivers/clk/tegra/clk-pll.c
[snip]
+struct clk *tegra_clk_register_pllxc(const char *name, const char *parent_name,
+ void __iomem *clk_base, void __iomem *pmc,
+ unsigned long flags, unsigned long fixed_rate,
+ struct tegra_clk_pll_params *pll_params,
+ u32 pll_flags,
+ struct tegra_clk_pll_freq_table *freq_table,
+ spinlock_t *lock)
+{
+   if (!pll_params->pdiv_tohw)
+   return -EINVAL;
+

This will cause the following warning:
warning: return makes pointer from integer without a cast

Same with occurrences in tegra_clk_register_pllm and
tegra_clk_register_pllc.

Should this instead be returning NULL?


return ERR_PTR(-EINVAL)



-rhyland



--
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 v5 05/10] clk: tegra: Add flags to tegra_clk_periph()

[Prashant Gaikwad]

On Friday 01 February 2013 03:48 PM, Peter De Schrijver wrote:

We will need some tegra peripheral clocks with the CLK_IGNORE_UNUSED flag,
most notably mselect, which is a bridge between AXI and most peripherals.

Signed-off-by: Peter De Schrijver 
---


Looks good to me.

Reviewed-by: Prashant Gaikwad 


  drivers/clk/tegra/clk-periph.c  |   11 ++-
  drivers/clk/tegra/clk-tegra20.c |2 +-
  drivers/clk/tegra/clk-tegra30.c |2 +-
  drivers/clk/tegra/clk.h |9 ++---
  4 files changed, 14 insertions(+), 10 deletions(-)

diff --git a/drivers/clk/tegra/clk-periph.c b/drivers/clk/tegra/clk-periph.c
index 788486e..067abb3 100644
--- a/drivers/clk/tegra/clk-periph.c
+++ b/drivers/clk/tegra/clk-periph.c
@@ -170,14 +170,15 @@ const struct clk_ops tegra_clk_periph_nodiv_ops = {
  static struct clk *_tegra_clk_register_periph(const char *name,
const char **parent_names, int num_parents,
struct tegra_clk_periph *periph,
-   void __iomem *clk_base, u32 offset, bool div)
+   void __iomem *clk_base, u32 offset, bool div,
+   unsigned long flags)
  {
struct clk *clk;
struct clk_init_data init;
  
  	init.name = name;

init.ops = div ? _clk_periph_ops : _clk_periph_nodiv_ops;
-   init.flags = div ? 0 : CLK_SET_RATE_PARENT;
+   init.flags = flags;
init.parent_names = parent_names;
init.num_parents = num_parents;
  
@@ -202,10 +203,10 @@ static struct clk *_tegra_clk_register_periph(const char *name,

  struct clk *tegra_clk_register_periph(const char *name,
const char **parent_names, int num_parents,
struct tegra_clk_periph *periph, void __iomem *clk_base,
-   u32 offset)
+   u32 offset, unsigned long flags)
  {
return _tegra_clk_register_periph(name, parent_names, num_parents,
-   periph, clk_base, offset, true);
+   periph, clk_base, offset, true, flags);
  }
  
  struct clk *tegra_clk_register_periph_nodiv(const char *name,

@@ -214,5 +215,5 @@ struct clk *tegra_clk_register_periph_nodiv(const char 
*name,
u32 offset)
  {
return _tegra_clk_register_periph(name, parent_names, num_parents,
-   periph, clk_base, offset, false);
+   periph, clk_base, offset, false, CLK_SET_RATE_PARENT);
  }
diff --git a/drivers/clk/tegra/clk-tegra20.c b/drivers/clk/tegra/clk-tegra20.c
index 54c6777..870349e 100644
--- a/drivers/clk/tegra/clk-tegra20.c
+++ b/drivers/clk/tegra/clk-tegra20.c
@@ -1048,7 +1048,7 @@ static void __init tegra20_periph_clk_init(void)
data = _periph_clk_list[i];
clk = tegra_clk_register_periph(data->name, data->parent_names,
data->num_parents, >periph,
-   clk_base, data->offset);
+   clk_base, data->offset, data->flags);
clk_register_clkdev(clk, data->con_id, data->dev_id);
clks[data->clk_id] = clk;
}
diff --git a/drivers/clk/tegra/clk-tegra30.c b/drivers/clk/tegra/clk-tegra30.c
index 078f9b8..126747b 100644
--- a/drivers/clk/tegra/clk-tegra30.c
+++ b/drivers/clk/tegra/clk-tegra30.c
@@ -1665,7 +1665,7 @@ static void __init tegra30_periph_clk_init(void)
data = _periph_clk_list[i];
clk = tegra_clk_register_periph(data->name, data->parent_names,
data->num_parents, >periph,
-   clk_base, data->offset);
+   clk_base, data->offset, data->flags);
clk_register_clkdev(clk, data->con_id, data->dev_id);
clks[data->clk_id] = clk;
}
diff --git a/drivers/clk/tegra/clk.h b/drivers/clk/tegra/clk.h
index 4d0f556..79f5e2a 100644
--- a/drivers/clk/tegra/clk.h
+++ b/drivers/clk/tegra/clk.h
@@ -411,7 +411,7 @@ extern const struct clk_ops tegra_clk_periph_ops;
  struct clk *tegra_clk_register_periph(const char *name,
const char **parent_names, int num_parents,
struct tegra_clk_periph *periph, void __iomem *clk_base,
-   u32 offset);
+   u32 offset, unsigned long flags);
  struct clk *tegra_clk_register_periph_nodiv(const char *name,
const char **parent_names, int num_parents,
struct tegra_clk_periph *periph, void __iomem *clk_base,
@@ -454,12 +454,14 @@ struct tegra_periph_init_data {
u32 offset;
const char *con_id;
const char *dev_id;
+   unsigned long flags;
  };
  
  #define TEGRA_INIT_DATA_TABLE(_name, _con_id, _dev_id, _parent_names, _offset,\

_mux_shift, _mux_mask, _mux_flags, _div_shift,  \
_div_width, _div_frac_width, _div_flags, _regs, \
-   _clk_num, _enb_refcnt, _gate_flags, _clk_id, 

Re: [PATCH v5 03/10] clk: tegra: Add PLL post divider table

[Prashant Gaikwad]

On Friday 01 February 2013 03:48 PM, Peter De Schrijver wrote:

Some PLLs in Tegra114 don't use a power of 2 mapping for the post divider.
Introduce a table based approach and switch PLLU to it.

Signed-off-by: Peter De Schrijver 
---


Looks good to me.

Reviewed-by: Prashant Gaikwad 


  drivers/clk/tegra/clk-pll.c |   38 --
  drivers/clk/tegra/clk-tegra20.c |7 +++
  drivers/clk/tegra/clk-tegra30.c |7 +++
  drivers/clk/tegra/clk.h |   13 +
  4 files changed, 59 insertions(+), 6 deletions(-)

diff --git a/drivers/clk/tegra/clk-pll.c b/drivers/clk/tegra/clk-pll.c
index 3c3a25e..87d2f34 100644
--- a/drivers/clk/tegra/clk-pll.c
+++ b/drivers/clk/tegra/clk-pll.c
@@ -258,6 +258,7 @@ static int _calc_rate(struct clk_hw *hw, struct 
tegra_clk_pll_freq_table *cfg,
  unsigned long rate, unsigned long parent_rate)
  {
struct tegra_clk_pll *pll = to_clk_pll(hw);
+   struct pdiv_map *p_tohw = pll->params->pdiv_tohw;
unsigned long cfreq;
u32 p_div = 0;
  
@@ -291,7 +292,6 @@ static int _calc_rate(struct clk_hw *hw, struct tegra_clk_pll_freq_table *cfg,

 cfg->output_rate <<= 1)
p_div++;
  
-	cfg->p = p_div;

cfg->m = parent_rate / cfreq;
cfg->n = cfg->output_rate / cfreq;
cfg->cpcon = OUT_OF_TABLE_CPCON;
@@ -304,8 +304,19 @@ static int _calc_rate(struct clk_hw *hw, struct 
tegra_clk_pll_freq_table *cfg,
return -EINVAL;
}
  
-	if (pll->flags & TEGRA_PLLU)

-   cfg->p ^= 1;
+   if (p_tohw) {
+   p_div = 1 << p_div;
+   while (p_tohw->pdiv) {
+   if (p_div <= p_tohw->pdiv) {
+   cfg->p = p_tohw->hw_val;
+   break;
+   }
+   p_tohw++;
+   }
+   if (!p_tohw->pdiv)
+   return -EINVAL;
+   } else
+   cfg->p = p_div;
  
  	return 0;

  }
@@ -452,8 +463,10 @@ static unsigned long clk_pll_recalc_rate(struct clk_hw *hw,
  {
struct tegra_clk_pll *pll = to_clk_pll(hw);
struct tegra_clk_pll_freq_table cfg;
+   struct pdiv_map *p_tohw = pll->params->pdiv_tohw;
u32 val;
u64 rate = parent_rate;
+   int pdiv;
  
  	val = pll_readl_base(pll);
  
@@ -472,10 +485,23 @@ static unsigned long clk_pll_recalc_rate(struct clk_hw *hw,
  
  	_get_pll_mnp(pll, );
  
-	if (pll->flags & TEGRA_PLLU)

-   cfg.p ^= 1;
+   if (p_tohw) {
+   while (p_tohw->pdiv) {
+   if (cfg.p == p_tohw->hw_val) {
+   pdiv = p_tohw->pdiv;
+   break;
+   }
+   p_tohw++;
+   }
+
+   if (!p_tohw->pdiv) {
+   WARN_ON(1);
+   pdiv = 1;
+   }
+   } else
+   pdiv = 1 << cfg.p;
  
-	cfg.m *= 1 << cfg.p;

+   cfg.m *= pdiv;
  
  	rate *= cfg.n;

do_div(rate, cfg.m);
diff --git a/drivers/clk/tegra/clk-tegra20.c b/drivers/clk/tegra/clk-tegra20.c
index 30bd3fd..54c6777 100644
--- a/drivers/clk/tegra/clk-tegra20.c
+++ b/drivers/clk/tegra/clk-tegra20.c
@@ -440,6 +440,12 @@ static struct tegra_clk_pll_params pll_d_params = {
.lock_delay = 1000,
  };
  
+static struct pdiv_map pllu_p[] = {

+   { .pdiv = 1, .hw_val = 1 },
+   { .pdiv = 2, .hw_val = 0 },
+   { .pdiv = 0, .hw_val = 0 },
+};
+
  static struct tegra_clk_pll_params pll_u_params = {
.input_min = 200,
.input_max = 4000,
@@ -452,6 +458,7 @@ static struct tegra_clk_pll_params pll_u_params = {
.lock_bit_idx = PLL_BASE_LOCK,
.lock_enable_bit_idx = PLLDU_MISC_LOCK_ENABLE,
.lock_delay = 1000,
+   .pdiv_tohw = pllu_p,
  };
  
  static struct tegra_clk_pll_params pll_x_params = {

diff --git a/drivers/clk/tegra/clk-tegra30.c b/drivers/clk/tegra/clk-tegra30.c
index 28a2997..078f9b8 100644
--- a/drivers/clk/tegra/clk-tegra30.c
+++ b/drivers/clk/tegra/clk-tegra30.c
@@ -466,6 +466,12 @@ static struct tegra_clk_pll_freq_table pll_d_freq_table[] 
= {
{ 0, 0, 0, 0, 0, 0 },
  };
  
+static struct pdiv_map pllu_p[] = {

+   { .pdiv = 1, .hw_val = 1 },
+   { .pdiv = 2, .hw_val = 0 },
+   { .pdiv = 0, .hw_val = 0 },
+};
+
  static struct tegra_clk_pll_freq_table pll_u_freq_table[] = {
{ 1200, 48000, 960, 12, 0, 12},
{ 1300, 48000, 960, 13, 0, 12},
@@ -639,6 +645,7 @@ static struct tegra_clk_pll_params pll_u_params = {
.lock_bit_idx = PLL_BASE_LOCK,
.lock_enable_bit_idx = PLLDU_MISC_LOCK_ENABLE,
.lock_delay = 1000,
+   .pdiv_tohw = pllu_p,
  };
  
  static struct tegra_clk_pll_params pll_x_params = {

diff --git a/drivers/clk/tegra/clk.h b/drivers/clk/tegra/clk.h
index 3cff1df..1b9cbcd 100644
--- 

Re: [Intel-gfx] [RFC PATCH 3/3] i915: ignore lid open event when resuming

[Zhang Rui]

On Tue, 2013-01-29 at 11:10 +0100, Daniel Vetter wrote:
> On Mon, Jan 28, 2013 at 06:06:38PM +0800, Zhang Rui wrote:
> > On Mon, 2013-01-28 at 09:31 +0100, Daniel Vetter wrote:
> > > On Mon, Jan 28, 2013 at 3:36 AM, Zhang Rui  wrote:
> > > >> Given that this essentially requires users to manually set this module
> > > >> option to make stuff work I don't like this.
> > > >>
> > > > sorry, I do not understand.
> > > > this patch just disables modeset_on_lid during suspend.
> > > 
> > > Pardon me, the misunderstanding is on my side - I've mixed up
> > > dev_priv->modeset_on_lid with the corresponding module option.
> > > 
> > > Is my understanding correct that only with the new SCI pm state this
> > > can happen, since that still allows acpi events to be processed (and
> > > so our lid_notifier being called?
> > > 
> > yep.
> > 
> > > >> I see a few possible options:
> > > >> - plug the races between all the different parts - I've never really
> > > >> understood why acpi sends us events before the resume code has
> > > >> completed ... If that's indeed intentional, we could delay the
> > > >> handling a bit until at least the i915 resume code completed.
> > > >
> > > > IMO, the real question is that, during a suspend/resume cycle, if we
> > > > need to take care of the lid open event or not.
> > > > To me, the answer is no, because when resuming from STR, i915 is not
> > > > aware of such an event, and the i915 resume code works well, right?
> > > > so I do not think it is a problem to ignore the lid event for another
> > > > lightweight suspend state, which is introduced in Patch 1/3 in this
> > > > series.
> > > >
> > > >> - Judging from the diff context you're not on the latest 3.8-rc
> > > >> codebase - we've applied a few fixes to this lid hack recently. Please
> > > >> retest on a kernel with
> > > >>
> > > > the patch is based on 3.8.0-rc3, which already includes the commit
> > > > below.
> > > > And yes, the problem still exists.
> > > 
> > > Ok, I think I see the issue now. But I suspect that we need some
> > > additional locking to make this solid, since currently
> > > dev_priv->modeset_on_lid updates can race with our lid notifier
> > > handler. Let me think about this a bit more.
> > 
> > hmm,
> > with this patch, intel_lid_notify() will return immediately if
> > modeset_on_lid is set to -1. So the only problem in my mind is that we
> > got a lid open event during i915_suspend().
> > 
> > Say,
> > lid is opened -> i915_lid_notify() is invoked (modeset_on_lid is 1 at
> > this time) -> i915_suspend() set modeset_on_lid to -1, just before
> > intel_modeset_setup_hw_state() being invoked in i915_lid_notify() ->
> > intel_modeset_setup_hw_state() breaks the system.
> > 
> > but my first question would be is this (lid open on suspend) possible in
> > real world?
> > If the answer is yes, then my second question is that, this problem
> > exists for STR as well because SCI is still valid at this time when
> > suspending to memory, have we seen such issues for STR before?
> > 
> > Anyway, if the current code does not break STR, this patch should be
> > enough for the new suspend state.
> > what do you think?
> 
> I think I have two wishlist changes for your patch ;-)
> 
> - Convert dev_priv->modeset_on_lid to an enum, so that we have descriptive
>   names instead of magic numbers.
> 
sure, will update in next version.

> - I think we can close all races by adding a new lid_notifier mutex (I
>   prefer a new lock instead of overloading an existing one with). If we
>   hold that in the suspend/resume paths just for changing modeset_on_lid
>   and also for the entire lid notifier callback (i.e. grab the lock before
>   first looking at modest_on_lid, only drop it once the modeset fixup has
>   been completed at the end of the function) we should be race-free in all
>   cases.
> 
>   Also, I think we should move the modeset_on_lid updates in the
>   suspend/resume paths to the very beginning/end.
> 
> Can you pls update your patch with these changes? Or do you see an
> additional race we need to plug somewhere?
> 
yep. will send out V2 soon.
thanks for your comments.

-rui

--
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/4] kdump, s390: make saved_max_pfn exclusive

[HATAYAMA Daisuke]

Signed-off-by: HATAYAMA Daisuke 
---

 arch/s390/kernel/setup.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/s390/kernel/setup.c b/arch/s390/kernel/setup.c
index a5360de..3357566 100644
--- a/arch/s390/kernel/setup.c
+++ b/arch/s390/kernel/setup.c
@@ -729,9 +729,9 @@ static void reserve_oldmem(void)
reserve_kdump_bootmem(OLDMEM_SIZE, memory_end - OLDMEM_SIZE,
  CHUNK_OLDMEM);
if (OLDMEM_BASE + OLDMEM_SIZE == real_memory_size)
-   saved_max_pfn = PFN_DOWN(OLDMEM_BASE) - 1;
+   saved_max_pfn = PFN_DOWN(OLDMEM_BASE);
else
-   saved_max_pfn = PFN_DOWN(real_memory_size) - 1;
+   saved_max_pfn = PFN_DOWN(real_memory_size);
 #endif
 }
 

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

[PATCH 0/4] kdump: make saved_max_pfn exlusive

[HATAYAMA Daisuke]

First, there are two kinds of notation to represent a map: inclusive
and exclusive. Here are the examples:

  1)  [mem 0x0001-0x00013fff]
  2)  [mem 0x0001-0x00014000]

1) is inclusive and 2) is exclusive. In case of 1), the pfn calculated
from the end address belongs to the map, while in case of 2), it
doesn't.

Currently, saved_max_pfn is used in read_oldmem() as inclusive for a
check to see if a given request is to within kernel's memory mapping
regions.

while (count) {
pfn = *ppos / PAGE_SIZE;
if (pfn > saved_max_pfn)
return read;

Unfortunately, on x86 and ia64, there are bugs below:

- On the 1st kernel, saved_max_pfn is not initialized so 0. Then, read
  to pfn 0 is not guarded by the condition and the execution goes into
  ioremap path.

- On the 2nd kernel, x86 and ia64 wrongly initializes saved_max_pfn by
  exclusive value, on x86 as:

saved_max_pfn = e820_end_of_ram_pfn();

  by which via /dev/oldmem we can read max_pfn that is not kernel's
  memory.

To fix this, fixing x86 and ia64 part needs smaller change, but
max_pfn is originally treated as exclusive so saved_max_pfn should
normally be exclusive. Also, the memory map information passed from
kexec is all exclusive on every architectures; it's possible to make
saved_max_pfn exclusive now.

However, ppc and ppc64 on kexec doesn't increment end address now and
this should be done as an insurance when map passed from firmware is
inclusive, for which I'll post a patch later.

---

HATAYAMA Daisuke (4):
  kdump, oldmem: compare with saved_max_pfn exclusively
  kdump, s390: make saved_max_pfn exclusive
  kdump, ppc: make saved_max_pfn exclusive
  kdump, mips: make saved_max_pfn exclusive


 arch/mips/kernel/crash_dump.c|2 +-
 arch/powerpc/kernel/crash_dump.c |2 +-
 arch/s390/kernel/setup.c |4 ++--
 drivers/char/mem.c   |2 +-
 4 files changed, 5 insertions(+), 5 deletions(-)

-- 

Thanks.
HATAYAMA, Daisuke
--
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] tmpfs: add support for read_iter and write_iter

[Hugh Dickins]

Convert tmpfs do_shmem_file_read() to shmem_file_read_iter().
Make file_read_iter_actor() global so tmpfs can use it too: delete
file_read_actor(), which was made global in 2.4.4 for use by tmpfs.
Replace tmpfs generic_file_aio_write() by generic_file_write_iter().

Signed-off-by: Hugh Dickins 
---
Please add this to the end of your loop O_DIRECT series.  I tested loop
on tmpfs successfully with .direct_IO = shmem_direct_IO() { return 0; }
but that's better left as a patch for separate discussion.

Hmm, I don't see an equivalent of the old fault_in_pages_writeable():
have I missed it, or is that a problem?

 include/linux/fs.h |5 ++-
 mm/filemap.c   |   42 +
 mm/shmem.c |   61 +--
 3 files changed, 24 insertions(+), 84 deletions(-)

--- 3.8-dk/include/linux/fs.h   2013-01-29 14:40:40.272041622 -0800
+++ linux/include/linux/fs.h2013-02-02 20:40:07.316296654 -0800
@@ -2458,8 +2458,9 @@ extern int sb_min_blocksize(struct super
 extern int generic_file_mmap(struct file *, struct vm_area_struct *);
 extern int generic_file_readonly_mmap(struct file *, struct vm_area_struct *);
 extern int generic_file_remap_pages(struct vm_area_struct *, unsigned long 
addr,
-   unsigned long size, pgoff_t pgoff);
-extern int file_read_actor(read_descriptor_t * desc, struct page *page, 
unsigned long offset, unsigned long size);
+   unsigned long size, pgoff_t pgoff);
+extern int file_read_iter_actor(read_descriptor_t *desc, struct page *page,
+   unsigned long offset, unsigned long size);
 int generic_write_checks(struct file *file, loff_t *pos, size_t *count, int 
isblk);
 extern ssize_t generic_file_aio_read(struct kiocb *, const struct iovec *, 
unsigned long, loff_t);
 extern ssize_t generic_file_read_iter(struct kiocb *, struct iov_iter *,
--- 3.8-dk/mm/filemap.c 2013-01-29 14:40:12.520040962 -0800
+++ linux/mm/filemap.c  2013-02-02 20:40:17.728296902 -0800
@@ -1295,44 +1295,6 @@ out:
file_accessed(filp);
 }
 
-int file_read_actor(read_descriptor_t *desc, struct page *page,
-   unsigned long offset, unsigned long size)
-{
-   char *kaddr;
-   unsigned long left, count = desc->count;
-
-   if (size > count)
-   size = count;
-
-   /*
-* Faults on the destination of a read are common, so do it before
-* taking the kmap.
-*/
-   if (!fault_in_pages_writeable(desc->arg.buf, size)) {
-   kaddr = kmap_atomic(page);
-   left = __copy_to_user_inatomic(desc->arg.buf,
-   kaddr + offset, size);
-   kunmap_atomic(kaddr);
-   if (left == 0)
-   goto success;
-   }
-
-   /* Do it the slow way */
-   kaddr = kmap(page);
-   left = __copy_to_user(desc->arg.buf, kaddr + offset, size);
-   kunmap(page);
-
-   if (left) {
-   size -= left;
-   desc->error = -EFAULT;
-   }
-success:
-   desc->count = count - size;
-   desc->written += size;
-   desc->arg.buf += size;
-   return size;
-}
-
 /*
  * Performs necessary checks before doing a write
  * @iov:   io vector request
@@ -1372,8 +1334,8 @@ int generic_segment_checks(const struct
 }
 EXPORT_SYMBOL(generic_segment_checks);
 
-static int file_read_iter_actor(read_descriptor_t *desc, struct page *page,
-   unsigned long offset, unsigned long size)
+int file_read_iter_actor(read_descriptor_t *desc, struct page *page,
+unsigned long offset, unsigned long size)
 {
struct iov_iter *iter = desc->arg.data;
unsigned long copied = 0;
--- 3.8-dk/mm/shmem.c   2013-01-02 20:27:10.956550061 -0800
+++ linux/mm/shmem.c2013-02-03 21:21:17.332510148 -0800
@@ -1463,14 +1463,23 @@ shmem_write_end(struct file *file, struc
return copied;
 }
 
-static void do_shmem_file_read(struct file *filp, loff_t *ppos, 
read_descriptor_t *desc, read_actor_t actor)
+static ssize_t shmem_file_read_iter(struct kiocb *iocb,
+   struct iov_iter *iter, loff_t pos)
 {
+   read_descriptor_t desc;
+   loff_t *ppos = >ki_pos;
+   struct file *filp = iocb->ki_filp;
struct inode *inode = filp->f_path.dentry->d_inode;
struct address_space *mapping = inode->i_mapping;
pgoff_t index;
unsigned long offset;
enum sgp_type sgp = SGP_READ;
 
+   desc.written = 0;
+   desc.count = iov_iter_count(iter);
+   desc.arg.data = iter;
+   desc.error = 0;
+
/*
 * Might this read be for a stacking filesystem?  Then when reading
 * holes of a sparse file, we actually need to allocate those pages,
@@ -1497,10 +1506,10 @@ static void do_shmem_file_read(struct fi
break;
}
 
-   

Re: [PATCH v5 02/10] clk: tegra: Add TEGRA_PLL_BYPASS flag

[Prashant Gaikwad]

On Friday 01 February 2013 03:48 PM, Peter De Schrijver wrote:

Not all PLLs in Tegra114 have a bypass bit. Adapt the common code to only use
this bit when available.

Signed-off-by: Peter De Schrijver 
---


Looks good to me.

Reviewed-by: Prashant Gaikwad 


  drivers/clk/tegra/clk-pll.c |   15 ++-
  drivers/clk/tegra/clk.h |8 +---
  2 files changed, 15 insertions(+), 8 deletions(-)

diff --git a/drivers/clk/tegra/clk-pll.c b/drivers/clk/tegra/clk-pll.c
index 912c977..3c3a25e 100644
--- a/drivers/clk/tegra/clk-pll.c
+++ b/drivers/clk/tegra/clk-pll.c
@@ -166,7 +166,8 @@ static void _clk_pll_enable(struct clk_hw *hw)
clk_pll_enable_lock(pll);
  
  	val = pll_readl_base(pll);

-   val &= ~PLL_BASE_BYPASS;
+   if (pll->flags & TEGRA_PLL_BYPASS)
+   val &= ~PLL_BASE_BYPASS;
val |= PLL_BASE_ENABLE;
pll_writel_base(val, pll);
  
@@ -183,7 +184,9 @@ static void _clk_pll_disable(struct clk_hw *hw)

u32 val;
  
  	val = pll_readl_base(pll);

-   val &= ~(PLL_BASE_BYPASS | PLL_BASE_ENABLE);
+   if (pll->flags & TEGRA_PLL_BYPASS)
+   val &= ~PLL_BASE_BYPASS;
+   val &= ~PLL_BASE_ENABLE;
pll_writel_base(val, pll);
  
  	if (pll->flags & TEGRA_PLLM) {

@@ -454,7 +457,7 @@ static unsigned long clk_pll_recalc_rate(struct clk_hw *hw,
  
  	val = pll_readl_base(pll);
  
-	if (val & PLL_BASE_BYPASS)

+   if ((pll->flags & TEGRA_PLL_BYPASS) && (val & PLL_BASE_BYPASS))
return parent_rate;
  
  	if ((pll->flags & TEGRA_PLL_FIXED) && !(val & PLL_BASE_OVERRIDE)) {

@@ -660,9 +663,10 @@ static struct clk *_tegra_clk_register_pll(const char 
*name,
  struct clk *tegra_clk_register_pll(const char *name, const char *parent_name,
void __iomem *clk_base, void __iomem *pmc,
unsigned long flags, unsigned long fixed_rate,
-   struct tegra_clk_pll_params *pll_params, u8 pll_flags,
+   struct tegra_clk_pll_params *pll_params, u32 pll_flags,
struct tegra_clk_pll_freq_table *freq_table, spinlock_t *lock)
  {
+   pll_flags |= TEGRA_PLL_BYPASS;
return _tegra_clk_register_pll(name, parent_name, clk_base, pmc,
flags, fixed_rate, pll_params, pll_flags, freq_table,
lock, _clk_pll_ops);
@@ -671,9 +675,10 @@ struct clk *tegra_clk_register_pll(const char *name, const 
char *parent_name,
  struct clk *tegra_clk_register_plle(const char *name, const char *parent_name,
void __iomem *clk_base, void __iomem *pmc,
unsigned long flags, unsigned long fixed_rate,
-   struct tegra_clk_pll_params *pll_params, u8 pll_flags,
+   struct tegra_clk_pll_params *pll_params, u32 pll_flags,
struct tegra_clk_pll_freq_table *freq_table, spinlock_t *lock)
  {
+   pll_flags |= TEGRA_PLL_BYPASS;
return _tegra_clk_register_pll(name, parent_name, clk_base, pmc,
flags, fixed_rate, pll_params, pll_flags, freq_table,
lock, _clk_plle_ops);
diff --git a/drivers/clk/tegra/clk.h b/drivers/clk/tegra/clk.h
index a09d7dc..3cff1df 100644
--- a/drivers/clk/tegra/clk.h
+++ b/drivers/clk/tegra/clk.h
@@ -182,12 +182,13 @@ struct tegra_clk_pll_params {
   * TEGRA_PLL_FIXED - We are not supposed to change output frequency
   * of some plls.
   * TEGRA_PLLE_CONFIGURE - Configure PLLE when enabling.
+ * TEGRA_PLL_BYPASS - PLL has bypass bit
   */
  struct tegra_clk_pll {
struct clk_hw   hw;
void __iomem*clk_base;
void __iomem*pmc;
-   u8  flags;
+   u32 flags;
unsigned long   fixed_rate;
spinlock_t  *lock;
u8  divn_shift;
@@ -210,18 +211,19 @@ struct tegra_clk_pll {
  #define TEGRA_PLLM BIT(5)
  #define TEGRA_PLL_FIXED BIT(6)
  #define TEGRA_PLLE_CONFIGURE BIT(7)
+#define TEGRA_PLL_BYPASS BIT(8)
  
  extern const struct clk_ops tegra_clk_pll_ops;

  extern const struct clk_ops tegra_clk_plle_ops;
  struct clk *tegra_clk_register_pll(const char *name, const char *parent_name,
void __iomem *clk_base, void __iomem *pmc,
unsigned long flags, unsigned long fixed_rate,
-   struct tegra_clk_pll_params *pll_params, u8 pll_flags,
+   struct tegra_clk_pll_params *pll_params, u32 pll_flags,
struct tegra_clk_pll_freq_table *freq_table, spinlock_t *lock);
  struct clk *tegra_clk_register_plle(const char *name, const char *parent_name,
void __iomem *clk_base, void __iomem *pmc,
unsigned long flags, unsigned long fixed_rate,
-   struct tegra_clk_pll_params *pll_params, u8 pll_flags,
+   struct tegra_clk_pll_params *pll_params, u32 pll_flags,
struct tegra_clk_pll_freq_table *freq_table, spinlock_t *lock);
  
  /**



--
To unsubscribe from this list: send the line "unsubscribe 

Re: No sysfs directory for openvswitch module when built-in

[Rusty Russell]

Cong Wang  writes:
> Hello, Rusty, Jesse,
>
> I met an interesting problem when I compile openvswitch module as a
> built-in (actually I compile ALL kernel modules as built-in), there is
> no /sys/module/openvswitch/ directory created by the kernel in this
> case.
...
> What's worse, the user-space init script thinks openvswitch module is
> not loaded by checking the exist of this directory, therefore refuses
> to start.

We only know built-in "modules" exist if we see a parameter or version
which mention them.  Looking for /sys/module/openvswitch/ is almost as
flawed as looking in /proc/modules.

I hacked up something which lists KBUILD_MODNAME for every element in my
kernel which did EXPORT_KERNEL or module_init, and most of them can
never be modules, though any could have parameters.  Even if we changed
the build system so we could tell things which "could have been a
module", it's silly.

In summary, you really need to test features, not presence of modules.

Cheers,
Rusty.

PS. Here's the list:

8250_core, 8250_pci, ac, access, acpi, acpi_i2c, addrconf_core, aead,
aerdriver, aes_generic, af_inet, af_netlink, af_packet, agpgart, ahci,
aio, amd, amd64_agp, amd_nb, anon_inodes, apic, arc4, argv_split, arp,
asn1_decoder, asymmetric_keys, async, ata_piix, atkbd, atomic64_32,
attr, attribute_container, autoprobe, average, backing_dev, backlight,
bad_inode, balloon_compaction, battery, bcd, bin, bio, bitblit, bitmap,
bitrev, blk_core, blk_exec, blk_flush, blk_ioc, blk_iopoll, blk_lib,
blk_map, blk_merge, blk_settings, blk_softirq, blk_tag, blk_timeout,
block_dev, boot, bootflag, bounce, bsearch, buffer, bus, bus, button,
cache_smp, capability, cfbcopyarea, cfbfillrect, cfbimgblt, cfg80211,
chainiv, char_dev, check_signature, chip, class, clock, clockevents,
clocksource, cmdline, common, common, configs, consolemap, container,
core, core, core, coredump, cpu, cpu, cpu, cpu_rmap, cpuidle, cpumask,
cputime, crc16, crc32, crc32c, crc_t10dif, cred, crypto, crypto_algapi,
crypto_blkcipher, crypto_hash, crypto_wq, cryptomgr, cstate, ctype,
datagram, datagram, dcache, dd, debug_core, debug_locks, debugfs,
dec_and_lock, delay, delayacct, dev, dev_addr_lists, devinet, devpts,
devres, devres, devres, dir, direct_io, div64, dma, dma_buf,
dma_coherent, dma_mapping, dmapool, dmi_scan, dnotify, driver, driver,
drm, drm_kms_helper, dst, dummychip, dumpstack, dumpstack_32,
dynamic_queue_limits, e1000e, e820, elevator, eseqiv, eth, ethtool,
eventfd, exec, exec_domain, exit, ext2, ext3, ext4, exthdrs_core, fan,
fb, fb_notify, fbcon, fbdev, fcntl, fib_frontend, fib_rules, fib_rules,
fib_trie, file, file, file_table, filemap, filesystems, filter,
find_last_bit, find_next_bit, firmware, firmware_class, flex_array,
flow, flow_dissector, font, fork, freezer, fremap, fs_struct,
fs_writeback, fsnotify, gcd, gen_estimator, gen_stats, generic,
generic_ops, genetlink, genhd, group, groups, halfmd4, hexdump, hid,
hid_a4tech, hid_apple, hid_belkin, hid_cherry, hid_chicony, hid_cypress,
hid_ezkey, hid_generic, hid_gyration, hid_logitech, hid_microsoft,
hid_monterey, hid_petalynx, hid_pl, hid_samsung, hid_sony, hid_sunplus,
highmem, highmem_32, host_bridge, hpet, hrtimer, htirq, hung_task,
hvc_console, hw_breakpoint, hw_breakpoint, hweight, hwmon, hypervisor,
i2c_algo_bit, i2c_boardinfo, i2c_core, i386, i386_ksyms_32, i387, i8042,
i810, i810fb, i8253, i915, icmp, ide_core, ide_gd_mod, ide_generic,
ide_pci_generic, ide_scan_pci, idr, igmp, inet_connection_sock,
inet_fragment, inet_hashtables, inet_lro, inet_timewait_sock, inetpeer,
init_32, init_task, inode, inotify_user, input_core, int_sqrt,
intel_agp, intel_gtt, io_apic, io_delay, ioapic, ioctl, ioctl, iomap,
iomap_32, iomap_copy, ioprio, ioremap, ioremap, iovec, ip_fragment,
ip_input, ip_options, ip_output, ip_sockglue, ip_tables, irq, irq,
irq_32, irq_work, irqdesc, jbd, jbd2, jiffies, kasprintf, kdebugfs, key,
keyboard, keyring, kfifo, kgdboc, klist, kmod, kobject, kobject_uevent,
krng, kstrtox, ksysfs, kthread, ladder, lcm, led_class, led_core,
led_triggers, legacy, lglock, libahci, libata, libfs, libps2,
link_watch, list_debug, list_sort, llist, locks, logo, mac80211,
maccess, main, main, main, main, manage, match, mbcache, mce, md5, md5,
memcpy_32, memory, mempool, memweight, menu, mii, misc, mlock, mm_init,
mmap, mmu_context, mmu_notifier, module, mount, mousedev, mpage, mpi,
mshyperv, msr, msr_reg_export, msr_smp, mutex, mutex_debug, n_tty,
namei, namespace, neighbour, net_namespace, net_sysfs, netevent,
netfilter, netfilter, netpoll, nf_conntrack, nf_conntrack_ipv4,
nf_defrag_ipv4, nlattr, nls_base, nmi, nobootmem, noop_iosched,
notification, notifier, nvram, oid_registry, oom_kill, open, output,
output_core, page_alloc, page_writeback, pageattr, panic, params,
paravirt, parser, partition_generic, pat, pcbios, pci, pci_dma,
pci_driver, pci_iomap, pci_quirks, pcieportdrv, pcips2, pcompress,
percpu, percpu_counter, perf_event, perf_event_amd, perf_event_amd_ibs,
perf_event_intel, 

Re: [PATCH v5 01/10] clk: tegra: Refactor PLL programming code

[Prashant Gaikwad]

On Friday 01 February 2013 03:48 PM, Peter De Schrijver wrote:

Refactor the PLL programming code to make it useable by the new PLL types
introduced by Tegra114.

The following changes were done:

* Split programming the PLL into updating m,n,p and updating cpcon
* Move locking from _update_pll_cpcon() to clk_pll_set_rate()
* Introduce _get_pll_mnp() helper
* Move check for identical m,n,p values to clk_pll_set_rate()
* struct tegra_clk_pll_freq_table will always contain the values as defined
   by the hardware.
* Simplify the arguments to clk_pll_wait_for_lock()

Signed-off-by: Peter De Schrijver 
---
  drivers/clk/tegra/clk-pll.c |  178 +
  drivers/clk/tegra/clk-tegra20.c |  144 
  drivers/clk/tegra/clk-tegra30.c |  234 +++---
  3 files changed, 294 insertions(+), 262 deletions(-)

diff --git a/drivers/clk/tegra/clk-pll.c b/drivers/clk/tegra/clk-pll.c
index 165f247..912c977 100644
--- a/drivers/clk/tegra/clk-pll.c
+++ b/drivers/clk/tegra/clk-pll.c
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 2012, NVIDIA CORPORATION.  All rights reserved.
+ * Copyright (c) 2012, 2013, NVIDIA CORPORATION.  All rights reserved.
   *
   * This program is free software; you can redistribute it and/or modify it
   * under the terms and conditions of the GNU General Public License,
@@ -113,20 +113,23 @@ static void clk_pll_enable_lock(struct tegra_clk_pll *pll)
 pll_writel_misc(val, pll);
  }

-static int clk_pll_wait_for_lock(struct tegra_clk_pll *pll,
-void __iomem *lock_addr, u32 lock_bit_idx)
+static int clk_pll_wait_for_lock(struct tegra_clk_pll *pll)
  {
 int i;
-   u32 val;
+   u32 val, lock_bit;
+   void __iomem *lock_addr;

 if (!(pll->flags & TEGRA_PLL_USE_LOCK)) {
 udelay(pll->params->lock_delay);
 return 0;
 }

+   lock_addr = pll->clk_base + pll->params->base_reg;


This will not work for PLLE. Lock bit for PLLE is in misc register.


+   lock_bit = BIT(pll->params->lock_bit_idx);
+
 for (i = 0; i < pll->params->lock_delay; i++) {
 val = readl_relaxed(lock_addr);
-   if (val & BIT(lock_bit_idx)) {
+   if (val & lock_bit) {


Need to change the lock bit idx parameter for Tegra20 and Tegra30 PLLs 
else this patch will break those.



 udelay(PLL_POST_LOCK_DELAY);
 return 0;
 }
@@ -155,7 +158,7 @@ static int clk_pll_is_enabled(struct clk_hw *hw)
 return val & PLL_BASE_ENABLE ? 1 : 0;
  }





@@ -538,8 +570,8 @@ static int clk_plle_enable(struct clk_hw *hw)
 val |= (PLL_BASE_BYPASS | PLL_BASE_ENABLE);
 pll_writel_base(val, pll);

-   clk_pll_wait_for_lock(pll, pll->clk_base + pll->params->misc_reg,
- pll->params->lock_bit_idx);
+   clk_pll_wait_for_lock(pll);
+
 return 0;
  }





  static struct tegra_clk_pll_freq_table pll_x_freq_table[] = {
 /* 1.7 GHz */
-   { 1200, 17, 850,  6,  1, 8},
-   { 1300, 17, 915,  7,  1, 8},/* actual: 1699.2 MHz */
-   { 1680, 17, 708,  7,  1, 8},/* actual: 1699.2 MHz */
-   { 1920, 17, 885,  10, 1, 8},/* actual: 1699.2 MHz */
-   { 2600, 17, 850,  13, 1, 8},
+   { 1200, 17, 850,  6,  0, 8},
+   { 1300, 17, 915,  7,  0, 8},/* actual: 1699.2 MHz */
+   { 1680, 17, 708,  7,  0, 8},/* actual: 1699.2 MHz */
+   { 1920, 17, 885,  10, 0, 8},/* actual: 1699.2 MHz */
+   { 2600, 17, 850,  13, 0, 8},

 /* 1.6 GHz */
-   { 1200, 16, 800,  6,  1, 8},
-   { 1300, 16, 738,  6,  1, 8},/* actual: 1599.0 MHz */
-   { 1680, 16, 857,  9,  1, 8},/* actual: 1599.7 MHz */
-   { 1920, 16, 500,  6,  1, 8},
-   { 2600, 16, 800,  13, 1, 8},
+   { 1200, 16, 800,  6,  0, 8},
+   { 1300, 16, 738,  6,  0, 8},/* actual: 1599.0 MHz */
+   { 1680, 16, 857,  9,  0, 8},/* actual: 1599.7 MHz */
+   { 1920, 16, 500,  6,  0, 8},
+   { 2600, 16, 800,  13, 0, 8},

 /* 1.5 GHz */
-   { 1200, 15, 750,  6,  1, 8},
-   { 1300, 15, 923,  8,  1, 8},/* actual: 1499.8 MHz */
-   { 1680, 15, 625,  7,  1, 8},
-   { 1920, 15, 625,  8,  1, 8},
-   { 2600, 15, 750,  13, 1, 8},
+   { 1200, 15, 750,  6,  0, 8},
+   { 1300, 15, 923,  8,  0, 8},/* actual: 1499.8 MHz */
+   { 1680, 15, 625,  7,  0, 8},
+   { 1920, 15, 625,  8,  0, 8},
+   { 2600, 15, 750,  13, 0, 8},

 /* 

linux-next: manual merge of the arm-soc tree with the mfd tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the arm-soc tree got a conflict in
drivers/mfd/db8500-prcmu.c between commit 5073e7b57041 ("mfd:
db8500-prcmu: Add ux500_wdt mfd_cell") from the mfd tree and commit
520f7bd73354 ("irqchip: Move ARM gic.h to
include/linux/irqchip/arm-gic.h") from the arm-soc tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

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

diff --cc drivers/mfd/db8500-prcmu.c
index e42a417,42f3afc..000
--- a/drivers/mfd/db8500-prcmu.c
+++ b/drivers/mfd/db8500-prcmu.c
@@@ -32,8 -33,6 +33,7 @@@
  #include 
  #include 
  #include 
 +#include 
- #include 
  #include 
  #include 
  #include 


pgpvV0CWvjInE.pgp
Description: PGP signature

Re: [PATCH 0/3] Enable multiple MSI feature in pSeries

[Michael Ellerman]

On Mon, 2013-02-04 at 11:49 +0800, Mike Qiu wrote:
> > On Tue, 2013-01-15 at 15:38 +0800, Mike Qiu wrote:
> > > Currently, multiple MSI feature hasn't been enabled in pSeries,
> > > These patches try to enbale this feature.
> > Hi Mike,
> > 
> > > These patches have been tested by using ipr driver, and the driver patch
> > > has been made by Wen Xiong :
> > So who wrote these patches? Normally we would expect the original author
> > to post the patches if at all possible.
> Hi Michael
> 
> These Multiple MSI patches were wrote by myself, you know this feature
> has not enabled
> and it need device driver to test whether it works suitable. So I test
> my patches use 
> Wen Xiong's ipr patches, which has been send out to the maillinglist.
> 
> I'm the original author :)

Ah OK, sorry, that was more or less clear from your mail but I just
misunderstood.

> > > [PATCH 0/7] Add support for new IBM SAS controllers
> > I would like to see the full series, including the driver enablement.
> Yep, but the driver patches were wrote by Wen Xiong and has been send
> out.

OK, you mean this series?

http://thread.gmane.org/gmane.linux.scsi/79639


> I just use her patches to test my patches. all device support Multiple
> MSI can use my feature not only IBM SAS controllers, I also test my
> patches use the broadcom wireless card tg3, and also works OK.

You mean drivers/net/ethernet/broadcom/tg3.c ? I don't see where it
calls pci_enable_msi_block() ?

All devices /can/ use it, but the driver needs to be updated. Currently
we have two drivers that do so (in Linus' tree), plus the updated IPR.

> > > Test platform: One partition of pSeries with one cpu core(4 SMTs) and 
> > >RAID bus controller: IBM PCI-E IPR SAS Adapter (ASIC) in 
> > > POWER7
> > > OS version: SUSE Linux Enterprise Server 11 SP2  (ppc64) with 3.8-rc3 
> > > kernel 
> > > 
> > > IRQ 21 and 22 are assigned to the ipr device which support 2 mutiple MSI.
> > > 
> > > The test results is shown by 'cat /proc/interrups':
> > >   CPU0   CPU1   CPU2   CPU3   
> > > 21:  6  5  5  5  XICS Level 
> > > host1-0
> > > 22:817814816813  XICS Level 
> > > host1-1
> > This shows that you are correctly configuring two MSIs.
> > 
> > But the key advantage of using multiple interrupts is to distribute load
> > across CPUs and improve performance. So I would like to see some
> > performance numbers that show that there is a real benefit for all the
> > extra complexity in the code.

> Yes, the system just has suport two MSIs. Anyway, I will try to do
> some proformance test, to show the real benefit.
> But actually it needs the driver to do so. As the data show above, it
> seems there is some problems in use the interrupt, the irq 21 use few,
> most use 22, I will discuss with the driver author to see why and if
> she fixed, I will give out the proformance result.

Yeah that would be good.

I really dislike that we have a separate API for multi-MSI vs MSI-X, and
pci_enable_msi_block() also pushes the contiguous power-of-2 allocation
into the irq domain layer, which is unpleasant. So if we really must do
multi-MSI I would like to do it differently.

cheers


--
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 02/15] mm: frontswap: lazy initialization to allow tmem backends to build/run as modules

[Bob Liu]

On Sun, Feb 3, 2013 at 3:07 PM, Ric Mason  wrote:
> Hi Konrad,
> On Fri, 2013-02-01 at 15:22 -0500, Konrad Rzeszutek Wilk wrote:
>> From: Dan Magenheimer 
>>
>> With the goal of allowing tmem backends (zcache, ramster, Xen tmem) to be
>> built/loaded as modules rather than built-in and enabled by a boot parameter,
>> this patch provides "lazy initialization", allowing backends to register to
>> frontswap even after swapon was run. Before a backend registers all calls
>> to init are recorded and the creation of tmem_pools delayed until a backend
>> registers or until a frontswap put is attempted.
>
> Do you mean __frontswap_store? It seems that just add fail count if
> backend doesn't register, why you said that the creation of tmem_pools
> will delay until this time?
>
>>
>> Signed-off-by: Stefan Hengelein 
>> Signed-off-by: Florian Schmaus 
>> Signed-off-by: Andor Daam 
>> Signed-off-by: Dan Magenheimer 
>> [v1: Fixes per Seth Jennings suggestions]
>> [v2: Removed FRONTSWAP_HAS_.. ]
>> [v3: Fix up per Bob Liu  recommendations]
>> [v4: Fix up per Andrew's comments]
>> Signed-off-by: Konrad Rzeszutek Wilk 
>> ---
>>  mm/frontswap.c | 95 
>> +++---
>>  1 file changed, 85 insertions(+), 10 deletions(-)
>>
>> diff --git a/mm/frontswap.c b/mm/frontswap.c
>> index 2890e67..c05a9db 100644
>> --- a/mm/frontswap.c
>> +++ b/mm/frontswap.c
>> @@ -80,6 +80,46 @@ static inline void inc_frontswap_succ_stores(void) { }
>>  static inline void inc_frontswap_failed_stores(void) { }
>>  static inline void inc_frontswap_invalidates(void) { }
>>  #endif
>> +
>> +/*
>> + * Due to the asynchronous nature of the backends loading potentially
>> + * _after_ the swap system has been activated, we have chokepoints
>> + * on all frontswap functions to not call the backend until the backend
>> + * has registered.
>> + *
>> + * Specifically when no backend is registered (nobody called
>> + * frontswap_register_ops) all calls to frontswap_init (which is done via
>> + * swapon -> enable_swap_info -> frontswap_init) are registered and 
>> remembered
>> + * (via the setting of need_init bitmap) but fail to create tmem_pools. 
>> When a
>> + * backend registers with frontswap at some later point the previous
>> + * calls to frontswap_init are executed (by iterating over the need_init
>> + * bitmap) to create tmem_pools and set the respective poolids. All of that 
>> is
>> + * guarded by us using atomic bit operations on the 'need_init' bitmap.
>> + *
>> + * This would not guards us against the user deciding to call swapoff right 
>> as
>> + * we are calling the backend to initialize (so swapon is in action).
>> + * Fortunatly for us, the swapon_mutex has been taked by the callee so we 
>> are
>> + * OK. The other scenario where calls to frontswap_store (called via
>> + * swap_writepage) is racing with frontswap_invalidate_area (called via
>> + * swapoff) is again guarded by the swap subsystem.
>> + *
>> + * While no backend is registered all calls to frontswap_[store|load|
>> + * invalidate_area|invalidate_page] are ignored or fail.
>> + *
>> + * The time between the backend being registered and the swap file system
>> + * calling the backend (via the frontswap_* functions) is indeterminate as
>> + * backend_registered is not atomic_t (or a value guarded by a spinlock).
>> + * That is OK as we are comfortable missing some of these calls to the newly
>> + * registered backend.
>> + *
>> + * Obviously the opposite (unloading the backend) must be done after all
>> + * the frontswap_[store|load|invalidate_area|invalidate_page] start
>> + * ignorning or failing the requests - at which point backend_registered
>> + * would have to be made in some fashion atomic.
>> + */
>> +static DECLARE_BITMAP(need_init, MAX_SWAPFILES);
>> +static bool backend_registered __read_mostly;
>> +
>>  /*
>>   * Register operations for frontswap, returning previous thus allowing
>>   * detection of multiple backends and possible nesting.
>> @@ -87,9 +127,22 @@ static inline void inc_frontswap_invalidates(void) { }
>>  struct frontswap_ops frontswap_register_ops(struct frontswap_ops *ops)
>>  {
>>   struct frontswap_ops old = frontswap_ops;
>> + int i;
>>
>>   frontswap_ops = *ops;
>>   frontswap_enabled = true;
>> +
>> + for (i = 0; i < MAX_SWAPFILES; i++) {
>> + if (test_and_clear_bit(i, need_init))
>> + (*frontswap_ops.init)(i);
>> + }
>> + /*
>> +  * We MUST have backend_registered set _after_ the frontswap_init's
>> +  * have been called. Otherwise __frontswap_store might fail. Hence
>> +  * the barrier to make sure compiler does not re-order us.
>> +  */
>> + barrier();
>> + backend_registered = true;
>>   return old;
>>  }
>>  EXPORT_SYMBOL(frontswap_register_ops);
>> @@ -119,10 +172,17 @@ void __frontswap_init(unsigned type)
>>  {
>>   struct swap_info_struct *sis = swap_info[type];
>>
>> - BUG_ON(sis == NULL);
>> -  

Re: [PATCH 4/4] x86, 32-bit: Drop new_cpu_data

[H. Peter Anvin]

boot_cpu_data is ok for things that are indeed universally valid across.  That 
does not include CPUID level, for one.

Borislav Petkov  wrote:

>On Sun, Feb 03, 2013 at 03:44:29PM -0800, H. Peter Anvin wrote:
>> On 02/03/2013 08:14 AM, Borislav Petkov wrote:
>> >From: Borislav Petkov 
>> >
>> >We copy it to boot_cpu_data anyway so use boot_cpu_data from the
>get-go.
>> >
>> 
>> Hmm... this is the only part of this patchset I feel skeptical
>> towards.  Overall, a lot of the early SMP code went way out of its
>> way to have zero impact on the !CONFIG_SMP case, but that was a long
>> time ago. Nowadays what we really should have is cpu_data being a
>> percpu variable separate from boot_cpu_data (which is really
>> "all_cpu_data") even on UP.
>
>Hmmkay.
>
>My thought vector here was to use boot_cpu_data to cache stuff
>here which is universally valid on the current system, i.e. like
>all_cpu_data. IOW, cache here family (model and stepping could differ,
>as we've come to realize over the years :)) vendor (btw, X86_VENDOR is
>unused) CPUID_EAX(0) level, capability, etc and use them later instead
>of querying them again.
>
>So, so early and in this case, we're saving CPU data which is valid for
>all CPUs on the system and thus it belongs into boot_cpu_data, right?
>
>And then, btw, that data could've been used in verify_cpu.S only if the
>damn thing wasn't being used in arch/x86/boot/...
>
>> Another cleanup desperately needed in this area is a bitvector for
>> bugs in addition to features.
>
>Yeah, c->x86_unfeatures! :-)
>
>> In fact, I kind of suspect we should make it the *same* bitvector
>> (different words) so we cpu_has(X) works on both without confusion
>> (just put the BUGS at the end; it means that if we add feature words
>> the bug numbers will shift but that is okay.)
>>
>> I actually mean to do this when I did the CPU feature vector stuff
>> over 10 years ago, but never got around to it... and it still has
>> never gotten done.
>>
>> The difference between bugs and features, of course, is that the
>> former should be combined across CPUs with an OR whereas the latter
>> get combined with an AND.
>
>Yeah, that should be pretty easy to do with the current machinery
>already in place. I'll take a look.
>
>Thanks.

-- 
Sent from my mobile phone. Please excuse brevity and lack of formatting.
--
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] video: add ili922x lcd driver

[Jingoo Han]

On Friday, February 01, 2013 11:42 PM, Anatolij Gustschin wrote

CC'ed Andrew Morton
> 
> From: Stefano Babic 
> 
> Add LCD driver for Ilitek ILI9221/ILI9222 controller.
> 
> Signed-off-by: Stefano Babic 
> Signed-off-by: Anatolij Gustschin 
> Cc: Richard Purdie 
> Cc: Florian Tobias Schandinat 
> ---
>  drivers/video/backlight/Kconfig   |7 +
>  drivers/video/backlight/Makefile  |1 +
>  drivers/video/backlight/ili922x.c |  586 
> +
>  3 files changed, 594 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/video/backlight/ili922x.c
> 
> diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
> index 765a945..97b4672 100644
> --- a/drivers/video/backlight/Kconfig
> +++ b/drivers/video/backlight/Kconfig
> @@ -59,6 +59,13 @@ config LCD_LTV350QV
> 
> The LTV350QV panel is present on all ATSTK1000 boards.
> 
> +config LCD_ILI922X
> + tristate "ILI Technology ILI9221/ILI9222 support"
> + depends on SPI
> + help
> +   If you have a panel based on the ILI9221/9222 controller
> +   chip then say y to include a driver for it.
> +
>  config LCD_ILI9320
>   tristate "ILI Technology ILI9320 controller support"
>   depends on SPI
> diff --git a/drivers/video/backlight/Makefile 
> b/drivers/video/backlight/Makefile
> index e7ce729..3cfd901 100644
> --- a/drivers/video/backlight/Makefile
> +++ b/drivers/video/backlight/Makefile
> @@ -6,6 +6,7 @@ obj-$(CONFIG_LCD_HP700)  += jornada720_lcd.o
>  obj-$(CONFIG_LCD_L4F00242T03)   += l4f00242t03.o
>  obj-$(CONFIG_LCD_LMS283GF05)+= lms283gf05.o
>  obj-$(CONFIG_LCD_LTV350QV)  += ltv350qv.o
> +obj-$(CONFIG_LCD_ILI922X)   += ili922x.o
>  obj-$(CONFIG_LCD_ILI9320)   += ili9320.o
>  obj-$(CONFIG_LCD_PLATFORM)  += platform_lcd.o
>  obj-$(CONFIG_LCD_VGG2432A4) += vgg2432a4.o
> diff --git a/drivers/video/backlight/ili922x.c 
> b/drivers/video/backlight/ili922x.c
> new file mode 100644
> index 000..18c33df
> --- /dev/null
> +++ b/drivers/video/backlight/ili922x.c
> @@ -0,0 +1,586 @@
> +/*
> + * (C) Copyright 2008
> + * Stefano Babic, DENX Software Engineering, sba...@denx.de.
> + *
> + * 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, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
> + * MA 02111-1307 USA

Please remove this comment. It is hard to keep track of the address of
Free Software Foundation.
Also, above mentioned address is not the same with the current address.

> + *
> + * This driver implements a lcd device for the ILITEK 922x display
> + * controller. The interface to the display is SPI and the display's
> + * memory is cyclically updated
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

Would you order inclusions of  according to alphabetical
ordering, for readability?

> +
> +/* Register offset, see manual section 8.2 */
> +#define REG_START_OSCILLATION0x00
> +#define REG_DRIVER_CODE_READ 0x00
> +#define REG_DRIVER_OUTPUT_CONTROL0x01
> +#define REG_LCD_AC_DRIVEING_CONTROL  0x02
> +#define REG_ENTRY_MODE   0x03
> +#define REG_COMPARE_10x04
> +#define REG_COMPARE_20x05
> +#define REG_DISPLAY_CONTROL_10x07
> +#define REG_DISPLAY_CONTROL_20x08
> +#define REG_DISPLAY_CONTROL_30x09
> +#define REG_FRAME_CYCLE_CONTROL  0x0B
> +#define REG_EXT_INTF_CONTROL 0x0C
> +#define REG_POWER_CONTROL_1  0x10
> +#define REG_POWER_CONTROL_2  0x11
> +#define REG_POWER_CONTROL_3  0x12
> +#define REG_POWER_CONTROL_4  0x13
> +#define REG_RAM_ADDRESS_SET  0x21
> +#define REG_WRITE_DATA_TO_GRAM   0x22
> +#define REG_RAM_WRITE_MASK1  0x23
> +#define REG_RAM_WRITE_MASK2  0x24
> +#define REG_GAMMA_CONTROL_1  0x30
> +#define REG_GAMMA_CONTROL_2  0x31
> +#define REG_GAMMA_CONTROL_3  0x32
> +#define REG_GAMMA_CONTROL_4  0x33
> +#define REG_GAMMA_CONTROL_5  0x34

linux-next: manual merge of the pinctrl tree with the battery tree

[Stephen Rothwell]

Hi Linus,

Today's linux-next merge of the pinctrl tree got a conflict in
include/linux/mfd/abx500/ab8500.h between commit 0ed5107fa860
("ab8500-charger: Do not touch VBUSOVV bits") from the battery tree and
commit 56813f798e8c ("mfd: ab8500: update header file and version
detection") from the pinctrl tree.

I fixed it up (the former is a subset of the latter) and can carry the
fix as necessary (no action is required).

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


pgpuUQmeO0gUY.pgp
Description: PGP signature

Re: [PATCHv2 0/9] Thermal Framework Enhancements

[Wei Ni]

On 01/07/2013 03:13 PM, Durgadoss R wrote:
> This patch set is a v2 of the previous versions submitted here:
> [v1]:  https://lkml.org/lkml/2012/12/18/108 
> [RFC]: https://patchwork.kernel.org/patch/1758921/
> 
> This patch set is based on Rui's -thermal tree, and is
> tested on a Core-i5 and an Atom netbook.
> 
> Changes Since v1:
>  * Removed kobject creation for thermal_trip and thermal_map
>nodes as per Greg-KH's comments.
>  * Added ABI Documentation under 'testing'.
>  * Modified the GET_INDEX macro to be more linux-like, thanks
>to Joe Perches.
>  * Added get_[sensor/cdev]_by_name APIs to thermal.h

Hi, Durgadoss and Rui
Will these patches be merged to next branch? or will you send out next
version?
I wish to use this new framework, could I send out patches for RFC based
on this serial patches?

Thanks.
Wei.

> 
> This series contains 9 patches:
> Patch 1/9: Creates new sensor level APIs
> Patch 2/9: Creates new zone level APIs. The existing tzd structure is
>kept as such for clarity and compatibility purposes.
> Patch 3/9: Creates functions to add/remove a cdev to/from a zone. The
>existing tcd structure need not be modified.
> Patch 4/9: Adds sensorX_trip_[active/passive/hot/critical] sysfs nodes,
>  under /sys/class/thermal/zoneY/. This exposes various trip
>points for sensorX present in zoneY.
> Patch 5/9: Adds mapX sysfs node. It is a compact representation
>of the binding relationship between a sensor and a cdev,
>within a zone.
> Patch 6/9: Creates Documentation for the new APIs. A new file is
>created for clarity. Final goal is to merge with the existing
>file or refactor the files, as whatever seems appropriate.
> Patch 7/9: Make PER ZONE values configurable through Kconfig
> Patch 8/9: Add ABI documentation for sysfs interfaces introduced in this 
> patch.
> Patch 9/9: A dummy driver that can be used for testing. This is not for merge.
> 
> Thanks to Greg-KH, Hongbo Zhang and Joe Perches for their comments on v1.
> 
> Durgadoss R (9):
>   Thermal: Create sensor level APIs
>   Thermal: Create zone level APIs
>   Thermal: Add APIs to bind cdev to new zone structure
>   Thermal: Add trip point sysfs nodes for sensor
>   Thermal: Create 'mapX' sysfs node for a zone
>   Thermal: Add Documentation to new APIs
>   Thermal: Make PER_ZONE values configurable
>   Thermal: Add ABI Documentation for sysfs interfaces
>   Thermal: Dummy driver used for testing
> 
>  Documentation/ABI/testing/sysfs-class-thermal |   93 +++
>  Documentation/thermal/sysfs-api2.txt  |  248 +++
>  drivers/thermal/Kconfig   |   19 +
>  drivers/thermal/Makefile  |3 +
>  drivers/thermal/thermal_sys.c |  881 
> +
>  drivers/thermal/thermal_test.c|  315 +
>  include/linux/thermal.h   |  117 +++-
>  7 files changed, 1675 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/ABI/testing/sysfs-class-thermal
>  create mode 100644 Documentation/thermal/sysfs-api2.txt
>  create mode 100644 drivers/thermal/thermal_test.c
> 

--
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] arch: avr32: add dummy syscalls

[Håvard Skinnemoen]

On Sun, Feb 3, 2013 at 9:05 PM, Al Viro  wrote:
> On Sun, Feb 03, 2013 at 08:52:18PM -0800, H?vard Skinnemoen wrote:
>
>> You're right on -- in this case, the compiler will skip r10, and do
>> (r12, r11, r8:r9, stack). We pass the syscall number in r8, but we
>> also unconditionally move r7 to r8 in the syscall path, so it
>> shouldn't matter (libc does the opposite when necessary).
>>
>> I remember some talk about having the compiler reuse r10 for the next
>> 32-bit argument in cases like this, but I don't think it ever
>> happened.
>
> Umm...  In case of fallocate() the next argument is 64bit one, though;
> sys_fallocate() will be looking for two 32bit words on stack, so no
> matter how do we pass them to syscall, we'd better push two words in
> the wrapper.

Right.

> But yes, 32bit/32bit/64bit/32bit is another interesting case -
> fanotify_mark is 32/32/64/32/32.  From what ABI says it would seem to
> be r12/r11/r8:r9/r10/stack, but if I understand you correctly, we'll
> end up wanting *two* arguments on stack...

Yes, I think there may be a difference between the IAR and gcc ABI
here. But I could be wrong.

Havard
--
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 6/6] ARM: davinci: da850: configure system configuration chip(CFGCHIP3) for emac

[Sekhar Nori]

On 2/3/2013 6:15 PM, Sekhar Nori wrote:
> On 1/28/2013 7:17 PM, Prabhakar Lad wrote:
>> From: Lad, Prabhakar 

> There are couple of issues with this implementation.
> 
> 1) da8xx_config_emac() is specific to DA850 EVM, but masquerades as
>generic for da8xx. Looks like you need two functions, one for soc
>specific configuration and one board specific.
> 2) da8xx_config_emac() goes through all the time, whether the
>particular board has emac module or not. Shouldn't
>da8xx_config_emac() check if emac is actually enabled in the passed
>dtb and only the do the configuration?
> 3) The function assumes mii is used always, you can use the rmii_en dt
>property to check if rmii/mii is enabled and configure the soc/board
>accordingly.
> 4) If the same function can work both for da850 and da830, then it can
>be implemented outside of CONFIG_ARCH_DAVINCI_DA850.

Another thing I forgot to mention:

5) This patch replicates a lot of code form board-da850-evm.c. This
needs to be avoided. May be create function to configure emac in
da850.c. This can then be called in board-da850-evm.c as well as in the
dt case.

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

Re: [PATCH 4/4] x86, 32-bit: Drop new_cpu_data

[Borislav Petkov]

On Sun, Feb 03, 2013 at 03:44:29PM -0800, H. Peter Anvin wrote:
> On 02/03/2013 08:14 AM, Borislav Petkov wrote:
> >From: Borislav Petkov 
> >
> >We copy it to boot_cpu_data anyway so use boot_cpu_data from the get-go.
> >
> 
> Hmm... this is the only part of this patchset I feel skeptical
> towards.  Overall, a lot of the early SMP code went way out of its
> way to have zero impact on the !CONFIG_SMP case, but that was a long
> time ago. Nowadays what we really should have is cpu_data being a
> percpu variable separate from boot_cpu_data (which is really
> "all_cpu_data") even on UP.

Hmmkay.

My thought vector here was to use boot_cpu_data to cache stuff
here which is universally valid on the current system, i.e. like
all_cpu_data. IOW, cache here family (model and stepping could differ,
as we've come to realize over the years :)) vendor (btw, X86_VENDOR is
unused) CPUID_EAX(0) level, capability, etc and use them later instead
of querying them again.

So, so early and in this case, we're saving CPU data which is valid for
all CPUs on the system and thus it belongs into boot_cpu_data, right?

And then, btw, that data could've been used in verify_cpu.S only if the
damn thing wasn't being used in arch/x86/boot/...

> Another cleanup desperately needed in this area is a bitvector for
> bugs in addition to features.

Yeah, c->x86_unfeatures! :-)

> In fact, I kind of suspect we should make it the *same* bitvector
> (different words) so we cpu_has(X) works on both without confusion
> (just put the BUGS at the end; it means that if we add feature words
> the bug numbers will shift but that is okay.)
>
> I actually mean to do this when I did the CPU feature vector stuff
> over 10 years ago, but never got around to it... and it still has
> never gotten done.
>
> The difference between bugs and features, of course, is that the
> former should be combined across CPUs with an OR whereas the latter
> get combined with an AND.

Yeah, that should be pretty easy to do with the current machinery
already in place. I'll take a look.

Thanks.

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
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] Input: tegra-kbc- Convert to devm_ioremap_resource()

[Sachin Kamat]

Hi Greg,

On 1 February 2013 15:37, Sachin Kamat  wrote:
> Use the newly introduced devm_ioremap_resource() instead of
> devm_request_and_ioremap() which provides more consistent error handling.
>
> devm_ioremap_resource() provides its own error messages; so all explicit
> error messages can be removed from the failure code paths.
>
> Signed-off-by: Sachin Kamat 
> Cc: Dmitry Torokhov 
> Cc: linux-in...@vger.kernel.org
> ---
>  Patch based & compile tested on linux-next tree (20130128).
>  Changes since v1:
>  * Dropped the error message as it is now handled by devm_ioremap_resource()
>  itself.
> ---

Just realized that most of these patches (converting to
devm_ioremap_resource) which were based on linux-next tree do not
apply on the driver-core tree due to missing dependent patches in it.
I will re-send them once 3.9-rc1 is out. For now, please ignore them.

- -
With warm regards,
Sachin
--
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 char-misc tree with the mfd tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the char-misc tree got a conflict in
drivers/mfd/wm5102-tables.c between commit d078377faf5f ("mfd: wm5102:
Refresh register defaults") from the mfd tree and commit 689557d3c704
("mfd: wm5102: Add microphone clamp control registers") from the
char-misc tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

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

diff --cc drivers/mfd/wm5102-tables.c
index c68727d,a396a3a..000
--- a/drivers/mfd/wm5102-tables.c
+++ b/drivers/mfd/wm5102-tables.c
@@@ -315,13 -316,9 +321,13 @@@ static const struct reg_default wm5102_
{ 0x0218, 0x01A6 },   /* R536   - Mic Bias Ctrl 1 */ 
{ 0x0219, 0x01A6 },   /* R537   - Mic Bias Ctrl 2 */ 
{ 0x021A, 0x01A6 },   /* R538   - Mic Bias Ctrl 3 */ 
 +  { 0x0225, 0x0400 },   /* R549   - HP Ctrl 1L */
 +  { 0x0226, 0x0400 },   /* R550   - HP Ctrl 1R */
{ 0x0293, 0x },   /* R659   - Accessory Detect Mode 1 */ 
{ 0x029B, 0x0020 },   /* R667   - Headphone Detect 1 */ 
 +  { 0x029C, 0x },   /* R668   - Headphone Detect 2 */
 +  { 0x029F, 0x },   /* R671   - Headphone Detect Test */
-   { 0x02A2, 0x },   /* R674   - Micd Clamp control */
+   { 0x02A2, 0x },   /* R674   - Micd clamp control */
{ 0x02A3, 0x1102 },   /* R675   - Mic Detect 1 */ 
{ 0x02A4, 0x009F },   /* R676   - Mic Detect 2 */ 
{ 0x02A5, 0x },   /* R677   - Mic Detect 3 */ 
@@@ -1854,11 -1883,8 +1862,12 @@@ static bool wm5102_volatile_register(st
case ARIZONA_DSP1_STATUS_1:
case ARIZONA_DSP1_STATUS_2:
case ARIZONA_DSP1_STATUS_3:
 +  case ARIZONA_DSP1_SCRATCH_0:
 +  case ARIZONA_DSP1_SCRATCH_1:
 +  case ARIZONA_DSP1_SCRATCH_2:
 +  case ARIZONA_DSP1_SCRATCH_3:
case ARIZONA_HEADPHONE_DETECT_2:
+   case ARIZONA_HP_DACVAL:
case ARIZONA_MIC_DETECT_3:
return true;
default:


pgpo4P5OnH8Da.pgp
Description: PGP signature

Re: boot warnings due to swap: make each swap partition have one address_space

[Hugh Dickins]

On Wed, 30 Jan 2013, Shaohua Li wrote:
> On Sun, Jan 27, 2013 at 01:40:40PM -0800, Hugh Dickins wrote:
> > 
> > I'm glad Minchan has now pointed you to Rik's posting of two years ago:
> > I think there are more important changes to be made in that direction.
> 
> Not sure how others use multiple swaps, but current lock contention forces us
> to use multiple swaps. I haven't carefully think about Rik's posting, but 
> looks
> it doesn't solve the lock contention problem.

Nobody had reported any swap lock contention problem before your patch,
so no, Rik's posting wasn't directed at that.  I always thought swap
writing patterns a much bigger problem.

But if lock contention there is, then I think it can be implemented
with reducing that in mind.  There are two levels of allocation: one
to allocate the tokens which we will insert in page tables, and one
to allocate the final diskspace to which those tokens will point.

(I may be using totally different language from Rik,
it's the principles that I have in mind, not his actual posting.)

Allocating the tokens can very well be done with per-cpu batches,
perhaps of SWAP_CLUSTER_MAX 32 to match vmscan.c's batching: there
is no significance to their ordering.  And allocating the diskspace
would want to be done in batches, to maximize contiguous writing.

That may not solve all the swap_info_get() contention which you saw,
but should help some.

I'm thinking that we go with your per-swapper-space locking for now;
but I wouldn't mind taking it out again later, if we arrive at a
better solution which benefits even those with a single swap area.

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

3.8: possible circular locking dependency detected

[Christian Kujau]

Hi,

similar to what I reported earlier [0] for 3.8.0-rc1, this happens during 
"ifup wlan0" (which in effect starts wpa_supplicant to bring up a Broadcom 
b43 wifi network interface). The interface is working though and continues 
to work over several ifup/ifdown iterations.

The backtrace looks awfully similar to the earlier[0] report, but this 
time it had b43* stuff in it so I thought I should report it. Full dmesg 
and .config here: http://nerdbynature.de/bits/3.8.0-rc6/

Christian.

[  807.693791] 
[  807.695519] ==
[  807.697198] [ INFO: possible circular locking dependency detected ]
[  807.698890] 3.8.0-rc6-8-g8b31849 #1 Not tainted
[  807.700573] ---
[  807.702255] wpa_supplicant/4129 is trying to acquire lock:
[  807.703925]  ((>firmware_load)){+.+.+.}, at: [] 
flush_work+0x0/0x2b0
[  807.705696] 
[  807.705696] but task is already holding lock:
[  807.709023]  (rtnl_mutex){+.+.+.}, at: [] rtnl_lock+0x1c/0x2c
[  807.710743] 
[  807.710743] which lock already depends on the new lock.
[  807.710743] 
[  807.715541] 
[  807.715541] the existing dependency chain (in reverse order) is:
[  807.718691] 
[  807.718691] -> #1 (rtnl_mutex){+.+.+.}:
[  807.721903][] mutex_lock_nested+0x6c/0x2bc
[  807.723533][] rtnl_lock+0x1c/0x2c
[  807.725138][] wiphy_register+0x510/0x53c [cfg80211]
[  807.726798][] ieee80211_register_hw+0x3f8/0x82c [mac80211]
[  807.728431][] b43_request_firmware+0x8c/0x198 [b43]
[  807.730025][] process_one_work+0x1a4/0x498
[  807.731549][] worker_thread+0x17c/0x428
[  807.733025][] kthread+0xa8/0xac
[  807.734439][] ret_from_kernel_thread+0x64/0x6c
[  807.735810] 
[  807.735810] -> #0 ((>firmware_load)){+.+.+.}:
[  807.738389][] lock_acquire+0x50/0x6c
[  807.739694][] flush_work+0x3c/0x2b0
[  807.740980][] __cancel_work_timer+0x94/0xec
[  807.742271][] b43_wireless_core_stop+0x5c/0x234 [b43]
[  807.743574][] b43_op_stop+0x4c/0x88 [b43]
[  807.744888][] ieee80211_stop_device+0x4c/0x8c [mac80211]
[  807.746240][] ieee80211_do_stop+0x2c0/0x5dc [mac80211]
[  807.747582][] ieee80211_stop+0x18/0x2c [mac80211]
[  807.748925][] __dev_close_many+0xb0/0x100
[  807.750257][] __dev_close+0x2c/0x4c
[  807.751560][] __dev_change_flags+0x124/0x178
[  807.752868][] dev_change_flags+0x1c/0x64
[  807.754177][] devinet_ioctl+0x69c/0x74c
[  807.755459][] inet_ioctl+0xcc/0xf8
[  807.756709][] sock_ioctl+0x70/0x2e8
[  807.757948][] do_vfs_ioctl+0xa4/0x7c0
[  807.759182][] sys_ioctl+0x44/0x70
[  807.760407][] ret_from_syscall+0x0/0x38
[  807.761622] 
[  807.761622] other info that might help us debug this:
[  807.761622] 
[  807.765107]  Possible unsafe locking scenario:
[  807.765107] 
[  807.767412]CPU0CPU1
[  807.768561]
[  807.769690]   lock(rtnl_mutex);
[  807.770822]lock((>firmware_load));
[  807.771970]lock(rtnl_mutex);
[  807.773115]   lock((>firmware_load));
[  807.774244] 
[  807.774244]  *** DEADLOCK ***
[  807.774244] 
[  807.777405] 1 lock held by wpa_supplicant/4129:
[  807.778475]  #0:  (rtnl_mutex){+.+.+.}, at: [] rtnl_lock+0x1c/0x2c
[  807.779628] 
[  807.779628] stack backtrace:
[  807.781720] Call Trace:
[  807.782765] [eea2db20] [c0009160] show_stack+0x48/0x15c (unreliable)
[  807.784087] [eea2db60] [c04fae24] print_circular_bug+0x2b0/0x2c8
[  807.785169] [eea2db90] [c0071300] __lock_acquire+0x14f4/0x18c8
[  807.786254] [eea2dc30] [c0071b38] lock_acquire+0x50/0x6c
[  807.787335] [eea2dc50] [c0049d58] flush_work+0x3c/0x2b0
[  807.788418] [eea2dcc0] [c004c30c] __cancel_work_timer+0x94/0xec
[  807.789516] [eea2dcf0] [f64c748c] b43_wireless_core_stop+0x5c/0x234 [b43]
[  807.790629] [eea2dd20] [f64c76b0] b43_op_stop+0x4c/0x88 [b43]
[  807.791754] [eea2dd40] [f64a4c08] ieee80211_stop_device+0x4c/0x8c [mac80211]
[  807.792888] [eea2dd50] [f64913a8] ieee80211_do_stop+0x2c0/0x5dc [mac80211]
[  807.794016] [eea2dd80] [f64916dc] ieee80211_stop+0x18/0x2c [mac80211]
[  807.795124] [eea2dd90] [c0423d94] __dev_close_many+0xb0/0x100
[  807.796237] [eea2ddb0] [c0423e10] __dev_close+0x2c/0x4c
[  807.797345] [eea2ddd0] [c0427514] __dev_change_flags+0x124/0x178
[  807.798451] [eea2ddf0] [c042761c] dev_change_flags+0x1c/0x64
[  807.799564] [eea2de10] [c047db9c] devinet_ioctl+0x69c/0x74c
[  807.800680] [eea2de70] [c047ecf8] inet_ioctl+0xcc/0xf8
[  807.801792] [eea2de80] [c040eab0] sock_ioctl+0x70/0x2e8
[  807.802905] [eea2dea0] [c00d9f70] do_vfs_ioctl+0xa4/0x7c0
[  807.804025] [eea2df10] [c00da6d0] sys_ioctl+0x44/0x70
[  807.805145] [eea2df40] [c001084c] ret_from_syscall+0x0/0x38
[  807.806270] --- Exception: c01 at 0xfbf2758
[  807.806270] LR = 0xfbf26bc

[  

Re: [PATCH v2 4/6] ARM: davinci: da850: add DT node for eth0.

[Prabhakar Lad]

Sekhar ,

On Sun, Feb 3, 2013 at 5:33 PM, Sekhar Nori  wrote:
> On 1/28/2013 7:17 PM, Prabhakar Lad wrote:
>> From: Lad, Prabhakar 
>>
>> Add eth0 device tree node information and pinmux for mii to da850 by
>> providing interrupt details and local mac address of eth0.
>>
>> Signed-off-by: Lad, Prabhakar 
>> Cc: linux-arm-ker...@lists.infradead.org
>> Cc: linux-kernel@vger.kernel.org
>> Cc: davinci-linux-open-sou...@linux.davincidsp.com
>> Cc: net...@vger.kernel.org
>> Cc: devicetree-disc...@lists.ozlabs.org
>> Cc: Sekhar Nori 
>> Cc: Heiko Schocher 
>> ---
>>  arch/arm/boot/dts/da850-evm.dts |5 +
>>  arch/arm/boot/dts/da850.dtsi|   35 +++
>>  2 files changed, 40 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/da850-evm.dts 
>> b/arch/arm/boot/dts/da850-evm.dts
>> index a319491..19aa2b3 100644
>> --- a/arch/arm/boot/dts/da850-evm.dts
>> +++ b/arch/arm/boot/dts/da850-evm.dts
>> @@ -30,6 +30,11 @@
>>   mdio: davinci_mdio@1e24000 {
>>   status = "okay";
>>   };
>> + eth0: emac@1e2 {
>> + status = "okay";
>> + pinctrl-names = "default";
>> + pinctrl-0 = <_pins>;
>> + };
>>   };
>>   nand_cs3@6200 {
>>   status = "okay";
>> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
>> index ba28f2d..76905f3 100644
>> --- a/arch/arm/boot/dts/da850.dtsi
>> +++ b/arch/arm/boot/dts/da850.dtsi
>> @@ -56,6 +56,26 @@
>>   0x30 0x0110  0x0ff0
>>   >;
>>   };
>> + mii_pins: pinmux_mii_pins {
>> + pinctrl-single,bits = <
>> + /*
>> +  * MII_TXEN, MII_TXCLK, MII_COL
>> +  * MII_TXD_3, MII_TXD_2, MII_TXD_1
>> +  * MII_TXD_0
>> +  */
>> + 0x8 0x8880 0xfff0
>> + /*
>> +  * MII_RXER, MII_CRS, MII_RXCLK
>> +  * MII_RXDV, MII_RXD_3, MII_RXD_2
>> +  * MII_RXD_1, MII_RXD_0
>> +  */
>> + 0xc 0x 0x
>> + /* MDIO_CLK, MDIO_D */
>
> You call this mii_pins, but include mdio pins in there as well. Can you
> separate them out? Then some board which uses rmii can simply reuse the
> entry.
>
Ok makes sense.

>> + 0x10 0x0088 0x00ff
>> + /* GPIO2_6 */
>> + 0x18 0x0080 0x00f0
>
> This is SoC specific pin list. Such board specific pins should not make
> it here.
>
Ok, so this should be set up using GPIO API's ?

>> + >;
>> + };
>>   };
>>   serial0: serial@1c42000 {
>>   compatible = "ns16550a";
>> @@ -88,6 +108,21 @@
>>   reg = <0x224000 0x1000>;
>>   bus_freq = <220>;
>>   };
>> + eth0: emac@1e2 {
>> + compatible = "ti,davinci-dm6467-emac";
>> + reg = <0x22 0x4000>;
>> + ti,davinci-ctrl-reg-offset = <0x3000>;
>> + ti,davinci-ctrl-mod-reg-offset = <0x2000>;
>> + ti,davinci-ctrl-ram-offset = <0>;
>> + ti,davinci-ctrl-ram-size = <0x2000>;
>> + local-mac-address = [ 00 00 00 00 00 00 ];
>> + interrupts = <33
>> + 34
>> + 35
>> + 36
>> + >;
>> + phy-handle = <>;
>
> I doubt this is required. This property is to pass a handle to the phy,
> not mdio bus.
>
Ok I'll check on this.

Regards,
--Prabhakar


> Thanks,
> Sekhar
--
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] arch: avr32: add dummy syscalls

[Al Viro]

On Sun, Feb 03, 2013 at 08:52:18PM -0800, H?vard Skinnemoen wrote:

> You're right on -- in this case, the compiler will skip r10, and do
> (r12, r11, r8:r9, stack). We pass the syscall number in r8, but we
> also unconditionally move r7 to r8 in the syscall path, so it
> shouldn't matter (libc does the opposite when necessary).
> 
> I remember some talk about having the compiler reuse r10 for the next
> 32-bit argument in cases like this, but I don't think it ever
> happened.

Umm...  In case of fallocate() the next argument is 64bit one, though;
sys_fallocate() will be looking for two 32bit words on stack, so no
matter how do we pass them to syscall, we'd better push two words in
the wrapper.

But yes, 32bit/32bit/64bit/32bit is another interesting case -
fanotify_mark is 32/32/64/32/32.  From what ABI says it would seem to
be r12/r11/r8:r9/r10/stack, but if I understand you correctly, we'll
end up wanting *two* arguments on stack...
--
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 6/6] ARM: davinci: da850: configure system configuration chip(CFGCHIP3) for emac

[Prabhakar Lad]

Sekhar ,

On Sun, Feb 3, 2013 at 6:15 PM, Sekhar Nori  wrote:
> On 1/28/2013 7:17 PM, Prabhakar Lad wrote:
>> From: Lad, Prabhakar 
>>
>> The system configuration chip CFGCHIP3, controls the emac module.
>> This patch appropriately configures this register for emac and
>> sets DA850_MII_MDIO_CLKEN_PIN GPIO pin appropriately.
>>
>> Signed-off-by: Lad, Prabhakar 
>> Cc: linux-arm-ker...@lists.infradead.org
>> Cc: linux-kernel@vger.kernel.org
>> Cc: davinci-linux-open-sou...@linux.davincidsp.com
>> Cc: net...@vger.kernel.org
>> Cc: devicetree-disc...@lists.ozlabs.org
>> Cc: Sekhar Nori 
>> Cc: Heiko Schocher 
>> ---
>>  arch/arm/mach-davinci/da8xx-dt.c |   28 
>>  1 files changed, 28 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/mach-davinci/da8xx-dt.c 
>> b/arch/arm/mach-davinci/da8xx-dt.c
>> index e533a0a..4a096e3 100644
>> --- a/arch/arm/mach-davinci/da8xx-dt.c
>> +++ b/arch/arm/mach-davinci/da8xx-dt.c
>> @@ -8,6 +8,7 @@
>>   * published by the Free Software Foundation.
>>   */
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -39,6 +40,32 @@ static void __init da8xx_init_irq(void)
>>
>>  #ifdef CONFIG_ARCH_DAVINCI_DA850
>>
>> +static void __init da8xx_config_emac(void)
>> +{
>> +#define DA850_MII_MDIO_CLKEN_PIN GPIO_TO_PIN(2, 6)
>> +#define DA850_EMAC_MODE_SELECT   BIT(8)
>> + void __iomem *cfg_chip3_base;
>> + int ret;
>> + u32 val;
>> +
>> + cfg_chip3_base = DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP3_REG);
>> +
>> + val = __raw_readl(cfg_chip3_base);
>> + val &= ~DA850_EMAC_MODE_SELECT;
>> + /* configure the CFGCHIP3 register for MII */
>> + __raw_writel(val, cfg_chip3_base);
>
> Use readl/writel instead.
>
Ok.

>> + pr_info("EMAC: MII PHY configured\n");
>> +
>> + ret = gpio_request(DA850_MII_MDIO_CLKEN_PIN, "mdio_clk_en");
>> + if (ret) {
>> + pr_warn("Cannot open GPIO %d\n",
>> + DA850_MII_MDIO_CLKEN_PIN);
>> + return;
>> + }
>> + /* Enable/Disable MII MDIO clock */
>> + gpio_direction_output(DA850_MII_MDIO_CLKEN_PIN, 0);
>> +}
>> +
>>  struct of_dev_auxdata da8xx_auxdata[] __initdata = {
>>   OF_DEV_AUXDATA("ti,davinci_mdio", 0x01e24000, "davinci_mdio.0", NULL),
>>   OF_DEV_AUXDATA("ti,davinci-dm6467-emac", 0x01e2, "davinci_emac.1",
>> @@ -52,6 +79,7 @@ static void __init da850_init_machine(void)
>>da8xx_auxdata, NULL);
>>
>>   da8xx_uart_clk_enable();
>> + da8xx_config_emac();
>
> There are couple of issues with this implementation.
>
> 1) da8xx_config_emac() is specific to DA850 EVM, but masquerades as
>generic for da8xx. Looks like you need two functions, one for soc
>specific configuration and one board specific.
Ok.

> 2) da8xx_config_emac() goes through all the time, whether the
>particular board has emac module or not. Shouldn't
>da8xx_config_emac() check if emac is actually enabled in the passed
>dtb and only the do the configuration?

Ok. Can you give some pointers how we can access the dtb in board files.

> 3) The function assumes mii is used always, you can use the rmii_en dt
>property to check if rmii/mii is enabled and configure the soc/board
>accordingly.

Ok.

> 4) If the same function can work both for da850 and da830, then it can
>be implemented outside of CONFIG_ARCH_DAVINCI_DA850.
>
Ok.

Regards,
--Prabhakar

> Thanks,
> Sekhar
--
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] kdump, oldmem: support mmap on /dev/oldmem

[Hatayama, Daisuke]

Support mmap() on /dev/oldmem to improve performance of reading
/proc/vmcore. Currently, read to /proc/vmcore is done by read_oldmem()
that uses ioremap and iounmap per a single page; for example, if
memory is 1GB, ioremap/iounmap is called (1GB / 4KB)-times, that is,
262144 times. This causes big performance degradation.

By this patch, we saw improvement on simple benchmark from

  200 [MiB/sec] to over 100.00 [GiB/sec].

Benchmark
=

= Machine spec
  - CPU: Intel(R) Xeon(R) CPU E7- 4820 @ 2.00GHz (4 sockets, 8 cores) (*)
  - memory: 32GB
  - kernel: 3.8-rc5 with this patch
  - vmcore size: 31.7GB

  (*) only 1 cpu is used in the 2nd kernel now.

= Benchmark Case

1) copy /proc/vmcore with mmap() on /dev/oldmem

  I ran the next command and recorded real time:

  $ for n in $(seq 1 15) ; do \
  >   time copyvmcore --blocksize=$((4096 * (1 << (n - 1 /proc/vmcore 
/dev/null \
  > done

  where copyvmcore is an ad-hoc test tool that parses ELF headers
  and copies them sequentially using mmap() on /dev/oldmem.
  See attached file.

|  n | map size |  time | page table | performance |
||  | (sec) ||   [GiB/sec] |
|+--+---++-|
|  1 | 4 KiB| 41.86 | 8 iB   |0.76 |
|  2 | 8 KiB| 25.43 | 16 iB  |1.25 |
|  3 | 16 KiB   | 13.28 | 32 iB  |2.39 |
|  4 | 32 KiB   |  7.20 | 64 iB  |4.40 |
|  5 | 64 KiB   |  3.45 | 128 iB |9.19 |
|  6 | 128 KiB  |  1.82 | 256 iB |   17.42 |
|  7 | 256 KiB  |  1.03 | 512 iB |   30.78 |
|  8 | 512 KiB  |  0.61 | 1K iB  |   51.97 |
|  9 | 1 MiB|  0.41 | 2K iB  |   77.32 |
| 10 | 2 MiB|  0.32 | 4K iB  |   99.06 |
| 11 | 4 MiB|  0.27 | 8K iB  |  117.41 |
| 12 | 8 MiB|  0.24 | 16 KiB |  132.08 |
| 13 | 16 MiB   |  0.23 | 32 KiB |  137.83 |
| 14 | 32 MiB   |  0.22 | 64 KiB |  144.09 |
| 15 | 64 MiB   |  0.22 | 128 KiB|  144.09 |

2) copy /proc/vmcore without mmap() on /dev/oldmem

$ time dd bs=4096 if=/proc/vmcore of=/dev/null
8307246+1 records in
8307246+1 records out
real2m 31.50s
user0m 1.06s
sys 2m 27.60s

So performance is 214.26 [MiB/sec].

3) The benchmark on previous patch

  See:

  http://lists.infradead.org/pipermail/kexec/2013-January/007758.html

  where more than 2.5 [GiB/sec] improvement was shown.

= Discussion

When map size is small, there are many mmap() calls and we can see the
same situation as ioremap() case. When map size is large enough, we
can see drastic improvement. This is because the number of mmap() is
as small enough as page table modification and TLB flush doesn't
matter. Another reason why performance is drastically better than the
previous patch's is that memory copy from kernel-space to user-space
is no longer performed now.

Performance improvement is saturated in relatively small map size and
so page table is relatively small. I guess we don't need to support
large pages on remap_pfn_range() for now or for ever.

Design Concern
==

The previous patch mapped a whole memory range targeted by kdump at
the same time on linear direct-mapping region. But doing that way is,
on the worst case, difficult to estimate amount of memory used for
page table to map the range.

Although I then once tried to investigate how to improve the issue by
mapping all the DIMM ranges that are all expected to be 1GB-aligned
and so 1GB pages are effective for small memory, I didn't choose this
way due to one memory hot-plugging issue related to undefined
behaviour of reading physical memory hole typically resulting in
system hang and another issue complicating the address to the 1st
issue, that there's no reliable source of actually present DIMM ranges
for use of kernel; SMBIOS is not sufficient since not all the
firmwares exports them.

On the other hand, /dev/oldmem is a simple interface whose offset
value corresponds to physical address of a whole system memory, and
even by this, there's room for userland tool to improve performance in
enough quality. For example, makedumpfile causes the performance in
reading huge consequtive memory sequentially, such as huge mem_map
array or each chunk corresponding to PT_LOAD map. We can improve the
performance even by using mmap() only there.

For design decision, I didn't support mmap() on /proc/vmcore because
it abstracts old memory as ELF format, so there's range consequtive on
/proc/vmcore but not consequtive on the actual old memory. For
example, consider ELF headers on the 2nd kernel and the note objects,
memory chunks corresponding to PT_LOAD entries on the first kernel.
They are not consequtive on the old memory. So reampping them so
/proc/vmcore appears consequtive using existing remap_pfn_range() needs
some complicated work.

TODO


- fix makedumpfile to use mmap() on /dev/oldmem and benchmark it to
  confirm whether we can see enough performance improvement.

Test

Re: linux-next: manual merge of the driver-core tree with the net-next tree

[Greg KH]

On Mon, Feb 04, 2013 at 03:38:31PM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the driver-core tree got a conflict in 
> drivers/net/wan/Kconfig between commit a786a7c0ad44 ("wanrouter: completely 
> decouple obsolete code from kernel") from the net-next tree and commit 
> c9f1b39aee74 ("drivers/net/wan: remove depends on CONFIG_EXPERIMENTAL") from 
> the driver-core tree.
> 
> The former removed part of the text changed by the latter, so I just did
> that (see below) and can carry the fix as necessary (no action is
> required).

That sounds fine to me, thanks.

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

Re: [PATCH] kdump: do not drop entire e820 in crash kernel

[H. Peter Anvin]

On 02/03/2013 08:04 PM, Cliff Wickman wrote:

From: Cliff Wickman 

The crash kernel is not able to find its root device if that device is not
on PCI 0.

This is because it is booted with the command line option memmap=exactmap
which currently clears the e820 table.  So ACPI processing does not
find reserved i/o spaces.

This works for a device on PCI 0 because ACPI falls back to a legacy mode.
But the error message " [Firmware Bug]: PCI: MMCONFIG at
  [mem 0x8000-0x80cf] not reserved in ACPI motherboard resources"
is written to the log even in this functioning case.

It fails for some devices on UV2, and only for UV2, because SGI seems to
be the only manufacturer currently using the extended PCI(>0).

The fix is to not drop the entire e820 table on a memmap=exactmap, but
to preserve all the non-E820_RAM reservations that the BIOS has made.



NAK.  This is a fundamntal semantic change to  something that isn't just 
affecting kexec.


This ultimately is the result of the very bad design decision to use the 
command line to muck with the target kernel memory map.


The work is underway to fix this, but this is not the right fix.

-hpa

--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

--
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] arch: avr32: add dummy syscalls

[Håvard Skinnemoen]

On Sun, Feb 3, 2013 at 7:02 PM, Al Viro  wrote:
> On Mon, Feb 04, 2013 at 01:31:11AM +, Al Viro wrote:
>
>> Unless I'm misreading ocavr32.pdf, that should be (R12, R10:R11, R9, R8) and
>> (R12, R10:R11, R9:R8, stack) resp., so fadvise64 doesn't need a wrapper, but
>> fadvise64_64 does.  And something like (s32, s32, s64, s64) would turn into
>> (R12, R11, R9:R8, stack, stack); AFAICS, we don't have anything that ugly...
>
> Oh, yes, we do - fallocate(2).  int fd, int mode, loff_t offset, loff_t len.
> On something like mips or sparc32 it packs nicely; on avr32 it doesn't.
> Could you confirm that I haven't misparsed the ABI?

You're right on -- in this case, the compiler will skip r10, and do
(r12, r11, r8:r9, stack). We pass the syscall number in r8, but we
also unconditionally move r7 to r8 in the syscall path, so it
shouldn't matter (libc does the opposite when necessary).

I remember some talk about having the compiler reuse r10 for the next
32-bit argument in cases like this, but I don't think it ever
happened.

Havard
--
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: CPU hotplug hang due to "swap: make each swap partition have one address_space"

[Joseph Lo]

On Mon, 2013-02-04 at 10:36 +0800, Shaohua Li wrote:
> On Fri, Feb 01, 2013 at 10:02:33PM -0700, Stephen Warren wrote:
> > Shaohua,
> > 
> > In next-20130128, commit 174f064 "swap: make each swap partition have
> > one address_space" (from the mm/akpm tree) appears causes a hang/RCU
> > stall for me when hot-unplugging a CPU.
> 
> does this one work for you?
> http://marc.info/?l=linux-mm=135929599505624=2
> Or try a more recent linux-next. The patch is in akpm's tree.
> 
Hi Shaohua,

The patch you pointed out did fix the issue. Just verified on Tegra
device.

Thanks,
Joseph


--
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 driver-core tree with the net-next tree

[Stephen Rothwell]

Hi Greg,

Today's linux-next merge of the driver-core tree got a conflict in 
drivers/net/wan/Kconfig between commit a786a7c0ad44 ("wanrouter: completely 
decouple obsolete code from kernel") from the net-next tree and commit 
c9f1b39aee74 ("drivers/net/wan: remove depends on CONFIG_EXPERIMENTAL") from 
the driver-core tree.

The former removed part of the text changed by the latter, so I just did
that (see below) and can carry the fix as necessary (no action is
required).

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

diff --cc drivers/net/wan/Kconfig
index 0c077b0,c0cd88d..000
--- a/drivers/net/wan/Kconfig
+++ b/drivers/net/wan/Kconfig
@@@ -356,9 -356,63 +356,9 @@@ config SDL
  To compile this driver as a module, choose M here: the
  module will be called sdla.
  
 -# Wan router core.
 -config WAN_ROUTER_DRIVERS
 -  tristate "WAN router drivers"
 -  depends on WAN_ROUTER
 -  ---help---
 -Connect LAN to WAN via Linux box.
 -
 -Select driver your card and remember to say Y to "Wan Router."
 -You will need the wan-tools package which is available from
 -.
 -
 -Note that the answer to this question won't directly affect the
 -kernel except for how subordinate drivers may be built:
 -saying N will just cause the configurator to skip all
 -the questions about WAN router drivers.
 -
 -If unsure, say N.
 -
 -config CYCLADES_SYNC
 -  tristate "Cyclom 2X(tm) cards"
 -  depends on WAN_ROUTER_DRIVERS && (PCI || ISA)
 -  ---help---
 -Cyclom 2X from Cyclades Corporation  is an
 -intelligent multiprotocol WAN adapter with data transfer rates up to
 -512 Kbps. These cards support the X.25 and SNA related protocols.
 -
 -While no documentation is available at this time please grab the
 -wanconfig tarball in
 - (with minor changes
 -to make it compile with the current wanrouter include files; efforts
 -are being made to use the original package available at
 -).
 -
 -Feel free to contact me or the cycsyn-devel mailing list at
 - and  for
 -additional details, I hope to have documentation available as soon as
 -possible. (Cyclades Brazil is writing the Documentation).
 -
 -The next questions will ask you about the protocols you want the
 -driver to support (for now only X.25 is supported).
 -
 -If you have one or more of these cards, say Y to this option.
 -
 -To compile this driver as a module, choose M here: the
 -module will be called cyclomx.
 -
 -config CYCLOMX_X25
 -  bool "Cyclom 2X X.25 support"
 -  depends on CYCLADES_SYNC
 -  help
 -Connect a Cyclom 2X card to an X.25 network.
 -
 -Enabling X.25 support will enlarge your kernel by about 11 kB.
 -
  # X.25 network drivers
  config LAPBETHER
-   tristate "LAPB over Ethernet driver (EXPERIMENTAL)"
+   tristate "LAPB over Ethernet driver"
depends on LAPB && X25
---help---
  Driver for a pseudo device (typically called /dev/lapb0) which allows


pgp2PF_9NAWQ4.pgp
Description: PGP signature

linux-next: manual merge of the driver-core tree with the net-next tree

[Stephen Rothwell]

Hi Greg,

Today's linux-next merge of the driver-core tree got a conflict in
net/wanrouter/Kconfig between commit 6fcdf4facb85 ("wanrouter: delete now
orphaned header content, files/drivers") from the net-next tree and
commit 1ed42403e764 ("net/wanrouter: remove depends on
CONFIG_EXPERIMENTAL") from the driver-core tree.

The former removed the file, so I did that and can carry the fix as
necessary (no action is required).

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


pgp6D0HTcU4jK.pgp
Description: PGP signature

Linux 3.7.6

[Greg KH]

I'm announcing the release of the 3.7.6 kernel.

All users of the 3.7 kernel series must upgrade.

The updated 3.7.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-3.7.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Documentation/device-mapper/dm-raid.txt   |1 
 Makefile  |2 
 arch/arm/kernel/head.S|5 
 arch/arm/kernel/hyp-stub.S|   18 +--
 arch/arm/mach-at91/setup.c|2 
 arch/arm/mach-omap2/board-omap4panda.c|6 +
 arch/arm/mach-s3c64xx/mach-crag6410-module.c  |2 
 arch/arm/mm/dma-mapping.c |   18 +--
 arch/arm/vfp/entry.S  |6 -
 arch/arm/vfp/vfphw.S  |4 
 arch/powerpc/kernel/entry_64.S|   13 ++
 arch/powerpc/kvm/emulate.c|2 
 arch/s390/include/asm/pgtable.h   |   12 ++
 arch/x86/boot/compressed/eboot.c  |3 
 arch/x86/boot/compressed/head_32.S|2 
 arch/x86/include/asm/efi.h|1 
 arch/x86/kernel/msr.c |3 
 arch/x86/kernel/reboot.c  |2 
 arch/x86/kernel/setup.c   |   30 ++---
 arch/x86/platform/efi/efi.c   |   59 ++
 arch/x86/platform/efi/efi_64.c|   22 +++
 drivers/acpi/osl.c|2 
 drivers/edac/edac_pci_sysfs.c |2 
 drivers/firmware/dmi_scan.c   |2 
 drivers/firmware/efivars.c|4 
 drivers/firmware/iscsi_ibft_find.c|2 
 drivers/gpu/drm/i915/i915_debugfs.c   |2 
 drivers/gpu/drm/i915/i915_reg.h   |1 
 drivers/gpu/drm/i915/intel_pm.c   |   15 +-
 drivers/gpu/drm/i915/intel_ringbuffer.c   |   24 +++-
 drivers/gpu/drm/radeon/radeon_cs.c|6 -
 drivers/gpu/drm/radeon/radeon_cursor.c|3 
 drivers/gpu/drm/radeon/radeon_device.c|3 
 drivers/gpu/drm/radeon/radeon_display.c   |2 
 drivers/hid/hid-ids.h |3 
 drivers/hid/usbhid/hid-quirks.c   |1 
 drivers/iommu/amd_iommu_init.c|   34 ++
 drivers/iommu/intel-iommu.c   |   21 ++-
 drivers/md/dm-raid.c  |  101 ++
 drivers/mfd/tc3589x.c |   17 ---
 drivers/net/can/c_can/c_can.c |4 
 drivers/net/can/pch_can.c |2 
 drivers/net/can/ti_hecc.c |4 
 drivers/net/wireless/ath/ath9k/ar9003_phy.c   |   25 +---
 drivers/net/wireless/ath/ath9k/ath9k.h|3 
 drivers/net/wireless/ath/ath9k/beacon.c   |2 
 drivers/net/wireless/ath/ath9k/debug.c|1 
 drivers/net/wireless/ath/ath9k/debug.h|2 
 drivers/net/wireless/ath/ath9k/htc_hst.c  |2 
 drivers/net/wireless/ath/ath9k/main.c |   22 +--
 drivers/net/wireless/ath/ath9k/recv.c |   54 ++---
 drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c |   11 +
 drivers/net/wireless/brcm80211/brcmsmac/main.c|   14 +-
 drivers/net/wireless/brcm80211/brcmsmac/main.h|2 
 drivers/net/wireless/brcm80211/brcmsmac/pub.h |2 
 drivers/net/wireless/iwlegacy/common.c|   35 ++
 drivers/net/wireless/mwifiex/cfg80211.c   |   15 --
 drivers/net/wireless/mwifiex/pcie.c   |2 
 drivers/net/wireless/mwifiex/sta_ioctl.c  |   14 ++
 drivers/platform/x86/ibm_rtl.c|2 
 drivers/platform/x86/samsung-laptop.c |4 
 drivers/scsi/isci/init.c  |2 
 drivers/target/target_core_fabric_configfs.c  |   11 -
 fs/cifs/cifs_dfs_ref.c|2 
 fs/nfs/namespace.c|   20 +++
 fs/nfs/nfs4client.c   |   62 ---
 fs/nfs/nfs4state.c|   22 ++-
 fs/nfs/super.c|   22 +--
 fs/xfs/xfs_aops.c |2 
 fs/xfs/xfs_buf.c  |   18 +++
 fs/xfs/xfs_sync.c 

Re: Linux 3.4.29

[Greg KH]

diff --git a/Makefile b/Makefile
index 8ccebba..23bcb1a 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
 VERSION = 3
 PATCHLEVEL = 4
-SUBLEVEL = 28
+SUBLEVEL = 29
 EXTRAVERSION =
 NAME = Saber-toothed Squirrel
 
diff --git a/arch/arm/mach-at91/setup.c b/arch/arm/mach-at91/setup.c
index 582142e..55293a7 100644
--- a/arch/arm/mach-at91/setup.c
+++ b/arch/arm/mach-at91/setup.c
@@ -104,6 +104,8 @@ static void __init soc_detect(u32 dbgu_base)
switch (socid) {
case ARCH_ID_AT91RM9200:
at91_soc_initdata.type = AT91_SOC_RM9200;
+   if (at91_soc_initdata.subtype == AT91_SOC_SUBTYPE_NONE)
+   at91_soc_initdata.subtype = AT91_SOC_RM9200_BGA;
at91_boot_soc = at91rm9200_soc;
break;
 
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index db23ae4..a3e4adf 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -503,25 +503,27 @@ static void dma_cache_maint_page(struct page *page, 
unsigned long offset,
size_t size, enum dma_data_direction dir,
void (*op)(const void *, size_t, int))
 {
+   unsigned long pfn;
+   size_t left = size;
+
+   pfn = page_to_pfn(page) + offset / PAGE_SIZE;
+   offset %= PAGE_SIZE;
+
/*
 * A single sg entry may refer to multiple physically contiguous
 * pages.  But we still need to process highmem pages individually.
 * If highmem is not configured then the bulk of this loop gets
 * optimized out.
 */
-   size_t left = size;
do {
size_t len = left;
void *vaddr;
 
+   page = pfn_to_page(pfn);
+
if (PageHighMem(page)) {
-   if (len + offset > PAGE_SIZE) {
-   if (offset >= PAGE_SIZE) {
-   page += offset / PAGE_SIZE;
-   offset %= PAGE_SIZE;
-   }
+   if (len + offset > PAGE_SIZE)
len = PAGE_SIZE - offset;
-   }
vaddr = kmap_high_get(page);
if (vaddr) {
vaddr += offset;
@@ -538,7 +540,7 @@ static void dma_cache_maint_page(struct page *page, 
unsigned long offset,
op(vaddr, len, dir);
}
offset = 0;
-   page++;
+   pfn++;
left -= len;
} while (left);
 }
diff --git a/arch/arm/vfp/entry.S b/arch/arm/vfp/entry.S
index cc926c9..323ce1a 100644
--- a/arch/arm/vfp/entry.S
+++ b/arch/arm/vfp/entry.S
@@ -22,7 +22,7 @@
 @  IRQs disabled.
 @
 ENTRY(do_vfp)
-#ifdef CONFIG_PREEMPT
+#ifdef CONFIG_PREEMPT_COUNT
ldr r4, [r10, #TI_PREEMPT]  @ get preempt count
add r11, r4, #1 @ increment it
str r11, [r10, #TI_PREEMPT]
@@ -35,7 +35,7 @@ ENTRY(do_vfp)
 ENDPROC(do_vfp)
 
 ENTRY(vfp_null_entry)
-#ifdef CONFIG_PREEMPT
+#ifdef CONFIG_PREEMPT_COUNT
get_thread_info r10
ldr r4, [r10, #TI_PREEMPT]  @ get preempt count
sub r11, r4, #1 @ decrement it
@@ -53,7 +53,7 @@ ENDPROC(vfp_null_entry)
 
__INIT
 ENTRY(vfp_testing_entry)
-#ifdef CONFIG_PREEMPT
+#ifdef CONFIG_PREEMPT_COUNT
get_thread_info r10
ldr r4, [r10, #TI_PREEMPT]  @ get preempt count
sub r11, r4, #1 @ decrement it
diff --git a/arch/arm/vfp/vfphw.S b/arch/arm/vfp/vfphw.S
index 3a0efaa..6ff903e 100644
--- a/arch/arm/vfp/vfphw.S
+++ b/arch/arm/vfp/vfphw.S
@@ -167,7 +167,7 @@ vfp_hw_state_valid:
@ else it's one 32-bit instruction, so
@ always subtract 4 from the following
@ instruction address.
-#ifdef CONFIG_PREEMPT
+#ifdef CONFIG_PREEMPT_COUNT
get_thread_info r10
ldr r4, [r10, #TI_PREEMPT]  @ get preempt count
sub r11, r4, #1 @ decrement it
@@ -191,7 +191,7 @@ look_for_VFP_exceptions:
@ not recognised by VFP
 
DBGSTR  "not VFP"
-#ifdef CONFIG_PREEMPT
+#ifdef CONFIG_PREEMPT_COUNT
get_thread_info r10
ldr r4, [r10, #TI_PREEMPT]  @ get preempt count
sub r11, r4, #1 @ decrement it
diff --git a/arch/x86/kernel/msr.c b/arch/x86/kernel/msr.c
index eb11369..8563b64 100644
--- a/arch/x86/kernel/msr.c
+++ b/arch/x86/kernel/msr.c
@@ -174,6 +174,9 @@ static int msr_open(struct inode *inode, struct file *file)
unsigned int cpu;
struct cpuinfo_x86 *c;
 
+   if (!capable(CAP_SYS_RAWIO))
+   return -EPERM;
+
cpu = iminor(file->f_path.dentry->d_inode);
if (cpu >= nr_cpu_ids || !cpu_online(cpu))
return -ENXIO;  /* No such CPU */
diff --git a/arch/x86/kernel/setup.c 

Linux 3.4.29

[Greg KH]

I'm announcing the release of the 3.4.29 kernel.

All users of the 3.4 kernel series must upgrade.

The updated 3.4.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-3.4.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Makefile  |2 -
 arch/arm/mach-at91/setup.c|2 +
 arch/arm/mm/dma-mapping.c |   18 +
 arch/arm/vfp/entry.S  |6 +--
 arch/arm/vfp/vfphw.S  |4 +-
 arch/x86/kernel/msr.c |3 +
 arch/x86/kernel/setup.c   |2 +
 arch/x86/platform/efi/efi.c   |2 -
 arch/x86/platform/efi/efi_64.c|   22 ---
 drivers/edac/edac_pci_sysfs.c |2 -
 drivers/gpu/drm/radeon/radeon_cursor.c|3 +
 drivers/gpu/drm/radeon/radeon_display.c   |2 -
 drivers/iommu/amd_iommu_init.c|   34 +
 drivers/iommu/intel-iommu.c   |   21 +++---
 drivers/net/can/c_can/c_can.c |4 +-
 drivers/net/can/pch_can.c |2 -
 drivers/net/can/ti_hecc.c |4 +-
 drivers/net/wireless/ath/ath9k/beacon.c   |1 
 drivers/net/wireless/ath/ath9k/htc_hst.c  |2 +
 drivers/net/wireless/ath/ath9k/recv.c |   10 +++--
 drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c |7 ++-
 drivers/net/wireless/iwlegacy/common.c|   35 +++---
 drivers/net/wireless/mwifiex/pcie.c   |2 -
 drivers/target/target_core_fabric_configfs.c  |   11 ++---
 fs/cifs/cifs_dfs_ref.c|2 +
 fs/nfs/namespace.c|   20 ++
 fs/xfs/xfs_aops.c |2 -
 kernel/smp.c  |   13 ++
 net/bluetooth/hci_event.c |2 -
 net/bluetooth/hidp/core.c |2 -
 net/mac80211/cfg.c|   12 +-
 net/mac80211/ieee80211_i.h|6 +--
 net/mac80211/offchannel.c |   17 +++-
 net/mac80211/scan.c   |   15 ++-
 net/mac80211/work.c   |4 +-
 sound/pci/hda/patch_realtek.c |1 
 sound/soc/codecs/wm2200.c |3 -
 sound/usb/mixer.c |   17 ++--
 38 files changed, 208 insertions(+), 109 deletions(-)

Alan Cox (1):
  x86/msr: Add capabilities check

Anderson Lizardo (1):
  Bluetooth: Fix incorrect strncpy() in hidp_setup_hid()

Avinash Patil (1):
  mwifiex: fix typo in PCIe adapter NULL check

Chris Rattray (1):
  ASoC: wm2200: correct mixer values and text

Clemens Ladisch (1):
  ALSA: usb-audio: fix invalid length check for RME and other UAC 2 devices

Cong Ding (1):
  fs/cifs/cifs_dfs_ref.c: fix potential memory leakage

Dan Carpenter (1):
  EDAC: Test correct variable in ->store function

Daniel Vetter (1):
  iommu/intel: disable DMAR for g4x integrated gfx

Felix Fietkau (2):
  ath9k: do not link receive buffers during flush
  ath9k: fix double-free bug on beacon generate failure

Greg Kroah-Hartman (1):
  Linux 3.4.29

H. Peter Anvin (1):
  x86/Sandy Bridge: Sandy Bridge workaround depends on CONFIG_PCI

Jan Kara (1):
  xfs: Fix possible use-after-free with AIO

Jean-Christophe PLAGNIOL-VILLARD (1):
  ARM: at91: rm9200: remake the BGA as default version

Jerome Glisse (1):
  drm/radeon: fix cursor corruption on DCE6 and newer

Johannes Berg (1):
  mac80211: fix FT roaming

Matt Fleming (1):
  x86, efi: Set runtime_version to the EFI spec revision

Nathan Zimmer (1):
  efi, x86: Pass a proper identity mapping in efi_call_phys_prelog

Nicholas Bellinger (1):
  target: fix regression with dev_link_magic in target_fabric_port_link

Olivier Sobrie (3):
  can: c_can: fix invalid error codes
  can: ti_hecc: fix invalid error codes
  can: pch_can: fix invalid error codes

Piotr Haber (1):
  brcmsmac: increase timer reference count for new timers only

Russell King (1):
  ARM: DMA: Fix struct page iterator in dma_cache_maint() to work with 
sparsemem

Stanislaw Gruszka (2):
  iwlegacy: fix IBSS cleanup
  mac80211: synchronize scan off/on-channel and PS states

Stephen Boyd (1):
  ARM: 7627/1: Predicate preempt logic on PREEMP_COUNT not 

Re: Linux 3.0.62

[Greg KH]

diff --git a/Makefile b/Makefile
index 2d64957..20f4902 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
 VERSION = 3
 PATCHLEVEL = 0
-SUBLEVEL = 61
+SUBLEVEL = 62
 EXTRAVERSION =
 NAME = Sneaky Weasel
 
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index f96d2c7..5663650 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -467,25 +467,27 @@ static void dma_cache_maint_page(struct page *page, 
unsigned long offset,
size_t size, enum dma_data_direction dir,
void (*op)(const void *, size_t, int))
 {
+   unsigned long pfn;
+   size_t left = size;
+
+   pfn = page_to_pfn(page) + offset / PAGE_SIZE;
+   offset %= PAGE_SIZE;
+
/*
 * A single sg entry may refer to multiple physically contiguous
 * pages.  But we still need to process highmem pages individually.
 * If highmem is not configured then the bulk of this loop gets
 * optimized out.
 */
-   size_t left = size;
do {
size_t len = left;
void *vaddr;
 
+   page = pfn_to_page(pfn);
+
if (PageHighMem(page)) {
-   if (len + offset > PAGE_SIZE) {
-   if (offset >= PAGE_SIZE) {
-   page += offset / PAGE_SIZE;
-   offset %= PAGE_SIZE;
-   }
+   if (len + offset > PAGE_SIZE)
len = PAGE_SIZE - offset;
-   }
vaddr = kmap_high_get(page);
if (vaddr) {
vaddr += offset;
@@ -502,7 +504,7 @@ static void dma_cache_maint_page(struct page *page, 
unsigned long offset,
op(vaddr, len, dir);
}
offset = 0;
-   page++;
+   pfn++;
left -= len;
} while (left);
 }
diff --git a/arch/x86/kernel/msr.c b/arch/x86/kernel/msr.c
index 12fcbe2..f7d1a64 100644
--- a/arch/x86/kernel/msr.c
+++ b/arch/x86/kernel/msr.c
@@ -175,6 +175,9 @@ static int msr_open(struct inode *inode, struct file *file)
unsigned int cpu;
struct cpuinfo_x86 *c;
 
+   if (!capable(CAP_SYS_RAWIO))
+   return -EPERM;
+
cpu = iminor(file->f_path.dentry->d_inode);
if (cpu >= nr_cpu_ids || !cpu_online(cpu))
return -ENXIO;  /* No such CPU */
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index eb9eb8b..6c4e9ff 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -633,6 +633,7 @@ static unsigned reserve_low = CONFIG_X86_RESERVE_LOW << 10;
 
 static bool __init snb_gfx_workaround_needed(void)
 {
+#ifdef CONFIG_PCI
int i;
u16 vendor, devid;
static const u16 snb_ids[] = {
@@ -657,6 +658,7 @@ static bool __init snb_gfx_workaround_needed(void)
for (i = 0; i < ARRAY_SIZE(snb_ids); i++)
if (devid == snb_ids[i])
return true;
+#endif
 
return false;
 }
diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
index ac3aa54..0fba86d 100644
--- a/arch/x86/platform/efi/efi_64.c
+++ b/arch/x86/platform/efi/efi_64.c
@@ -38,7 +38,7 @@
 #include 
 #include 
 
-static pgd_t save_pgd __initdata;
+static pgd_t *save_pgd __initdata;
 static unsigned long efi_flags __initdata;
 
 static void __init early_code_mapping_set_exec(int executable)
@@ -61,12 +61,20 @@ static void __init early_code_mapping_set_exec(int 
executable)
 void __init efi_call_phys_prelog(void)
 {
unsigned long vaddress;
+   int pgd;
+   int n_pgds;
 
early_code_mapping_set_exec(1);
local_irq_save(efi_flags);
-   vaddress = (unsigned long)__va(0x0UL);
-   save_pgd = *pgd_offset_k(0x0UL);
-   set_pgd(pgd_offset_k(0x0UL), *pgd_offset_k(vaddress));
+
+   n_pgds = DIV_ROUND_UP((max_pfn << PAGE_SHIFT), PGDIR_SIZE);
+   save_pgd = kmalloc(n_pgds * sizeof(pgd_t), GFP_KERNEL);
+
+   for (pgd = 0; pgd < n_pgds; pgd++) {
+   save_pgd[pgd] = *pgd_offset_k(pgd * PGDIR_SIZE);
+   vaddress = (unsigned long)__va(pgd * PGDIR_SIZE);
+   set_pgd(pgd_offset_k(pgd * PGDIR_SIZE), 
*pgd_offset_k(vaddress));
+   }
__flush_tlb_all();
 }
 
@@ -75,7 +83,11 @@ void __init efi_call_phys_epilog(void)
/*
 * After the lock is released, the original page table is restored.
 */
-   set_pgd(pgd_offset_k(0x0UL), save_pgd);
+   int pgd;
+   int n_pgds = DIV_ROUND_UP((max_pfn << PAGE_SHIFT) , PGDIR_SIZE);
+   for (pgd = 0; pgd < n_pgds; pgd++)
+   set_pgd(pgd_offset_k(pgd * PGDIR_SIZE), save_pgd[pgd]);
+   kfree(save_pgd);
__flush_tlb_all();
local_irq_restore(efi_flags);
early_code_mapping_set_exec(0);
diff --git a/drivers/edac/edac_pci_sysfs.c 

Linux 3.0.62

[Greg KH]

I'm announcing the release of the 3.0.62 kernel.

All users of the 3.0 kernel series must upgrade.

The updated 3.0.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-3.0.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Makefile |2 +-
 arch/arm/mm/dma-mapping.c|   18 ++
 arch/x86/kernel/msr.c|3 +++
 arch/x86/kernel/setup.c  |2 ++
 arch/x86/platform/efi/efi_64.c   |   22 +-
 drivers/edac/edac_pci_sysfs.c|2 +-
 drivers/net/can/c_can/c_can.c|4 ++--
 drivers/net/can/pch_can.c|2 +-
 drivers/net/can/ti_hecc.c|4 ++--
 drivers/net/wireless/ath/ath9k/beacon.c  |1 +
 drivers/net/wireless/ath/ath9k/htc_hst.c |2 ++
 fs/cifs/cifs_dfs_ref.c   |2 ++
 kernel/smp.c |   13 -
 net/bluetooth/hci_event.c|2 +-
 net/bluetooth/hidp/core.c|2 +-
 sound/usb/mixer.c|   17 -
 16 files changed, 70 insertions(+), 28 deletions(-)

Alan Cox (1):
  x86/msr: Add capabilities check

Anderson Lizardo (1):
  Bluetooth: Fix incorrect strncpy() in hidp_setup_hid()

Clemens Ladisch (1):
  ALSA: usb-audio: fix invalid length check for RME and other UAC 2 devices

Cong Ding (1):
  fs/cifs/cifs_dfs_ref.c: fix potential memory leakage

Dan Carpenter (1):
  EDAC: Test correct variable in ->store function

Felix Fietkau (1):
  ath9k: fix double-free bug on beacon generate failure

Greg Kroah-Hartman (1):
  Linux 3.0.62

H. Peter Anvin (1):
  x86/Sandy Bridge: Sandy Bridge workaround depends on CONFIG_PCI

Nathan Zimmer (1):
  efi, x86: Pass a proper identity mapping in efi_call_phys_prelog

Olivier Sobrie (3):
  can: c_can: fix invalid error codes
  can: ti_hecc: fix invalid error codes
  can: pch_can: fix invalid error codes

Russell King (1):
  ARM: DMA: Fix struct page iterator in dma_cache_maint() to work with 
sparsemem

Sujith Manoharan (1):
  ath9k_htc: Fix memory leak

Szymon Janc (1):
  Bluetooth: Fix sending HCI commands after reset

Wang YanQing (1):
  smp: Fix SMP function call empty cpu mask race



pgpdkZ_ix6lfT.pgp
Description: PGP signature

RE: [PATCH V4] suspend: enable freeze timeout configuration through sys

[Liu, Chuansheng]

> -Original Message-
> From: Alan Stern [mailto:st...@rowland.harvard.edu]
> Sent: Monday, February 04, 2013 11:16 AM
> To: Li, Fei
> Cc: Rafael J. Wysocki; a...@linux-foundation.org;
> linux-kernel@vger.kernel.org; linux...@vger.kernel.org; Liu, Chuansheng
> Subject: RE: [PATCH V4] suspend: enable freeze timeout configuration through
> sys
> 
> On Mon, 4 Feb 2013, Li, Fei wrote:
> 
> > > -> the situation described above shouldn't happen and if it does, then 
> > > there
> > > is a bug that needs to be fixed.
> >
> > Yes, we agree with that it's a bug that needs to be fixed, and we are 
> > already
> done
> > for some cases.
> > During the process, we realize that tuning the timeout value to smaller 
> > value
> will help
> > to expose freezing failure for some cases.
> 
> Besides, the underlying bug is well known (fuse filesystems hanging
> because the fuse daemon gets frozen before the process doing file I/O,
> or something like that) and so far nobody has a good idea of how to
> fix it.
Indeed, we have some well-known deadlock issues existed there.
And once there is deadlock case, this patch is helpful to the user experience,
because 20s is pointless for those deadlock case.

Also even adjusting the 20s to 2s, we still can get to know the process stack 
who rejecting the freezing,
so this freezing configuration is really helpful to avoid 20s waiting for that 
deadlock case.
Alan and Rafael, could you consider this patch? Thanks.
> 
> Alan Stern

--
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] memcg: stop warning on memcg_propagate_kmem

[Hugh Dickins]

Whilst I run the risk of a flogging for disloyalty to the Lord of Sealand,
I do have CONFIG_MEMCG=y CONFIG_MEMCG_KMEM not set, and grow tired of the
"mm/memcontrol.c:4972:12: warning: `memcg_propagate_kmem' defined but not
used [-Wunused-function]" seen in 3.8-rc: move the #ifdef outwards.

Signed-off-by: Hugh Dickins 
---

 mm/memcontrol.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- 3.8-rc6/mm/memcontrol.c 2012-12-22 09:43:27.628015582 -0800
+++ linux/mm/memcontrol.c   2013-02-02 16:56:06.188325771 -0800
@@ -4969,6 +4969,7 @@ out:
return ret;
 }
 
+#ifdef CONFIG_MEMCG_KMEM
 static int memcg_propagate_kmem(struct mem_cgroup *memcg)
 {
int ret = 0;
@@ -4977,7 +4978,6 @@ static int memcg_propagate_kmem(struct m
goto out;
 
memcg->kmem_account_flags = parent->kmem_account_flags;
-#ifdef CONFIG_MEMCG_KMEM
/*
 * When that happen, we need to disable the static branch only on those
 * memcgs that enabled it. To achieve this, we would be forced to
@@ -5003,10 +5003,10 @@ static int memcg_propagate_kmem(struct m
mutex_lock(_limit_mutex);
ret = memcg_update_cache_sizes(memcg);
mutex_unlock(_limit_mutex);
-#endif
 out:
return ret;
 }
+#endif /* CONFIG_MEMCG_KMEM */
 
 /*
  * The user of this function is...
--
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] Please pull powerpc.git merge branch

[Benjamin Herrenschmidt]

Hi Linus !

Just so that you don't get too bored on your Island here's a patch for
3.8 fixing a nasty bug that affects the new 64T support that was merged
in 3.7. Please apply whenever you have a chance (and an internet
connection !)

Cheers,
Ben.

The following changes since commit 689dfa894c57842a05bf6dc9f97e6bb71ec5f386:

  powerpc: Max next_tb to prevent from replaying timer interrupt (2013-01-29 
10:18:16 +1100)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge

for you to fetch changes up to eda8eebdd153c48a4e2a3a3ac3cd9e2e31f5c6b3:

  powerpc/mm: Fix hash computation function (2013-02-04 15:15:08 +1100)


Aneesh Kumar K.V (1):
  powerpc/mm: Fix hash computation function

 arch/powerpc/mm/hash_low_64.S |   62 +++--
 1 file changed, 35 insertions(+), 27 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/

Re: 3.8-rc regression with pps-ldisc due to 70ece7a731

[George Spelvin]

Just FYI, here is the (ugly and appears to crash) sort of patch
I was contemplating.

You may consider this Signed-off-by: in the narrow technical sense that I
can certify the origin of the code, but obviously I do not consider it
a candidate for upstream merging.  It is posted here in the hopes that
its sheer hideousness will inspire someone else to show that they can
do better.

diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
index 19083ef..c149c70 100644
--- a/drivers/tty/n_tty.c
+++ b/drivers/tty/n_tty.c
@@ -73,7 +73,10 @@
 #define ECHO_OP_SET_CANON_COL 0x81
 #define ECHO_OP_ERASE_TAB 0x82
 
+struct pps_device; /* Used by drivers/pps/clients/pps-ldisc.c */
+
 struct n_tty_data {
+   struct pps_device *pps; /* First so pps-ldisc doesn't have to know 
offset. */
unsigned int column;
unsigned long overrun_time;
int num_overrun;
@@ -1636,6 +1639,7 @@ static int n_tty_open(struct tty_struct *tty)
mutex_init(>output_lock);
mutex_init(>echo_lock);
spin_lock_init(>read_lock);
+   //tty->pps = NULL;  /* Done by kzalloc */
 
/* These are ugly. Currently a malloc failure here can panic */
ldata->read_buf = kzalloc(N_TTY_BUF_SIZE, GFP_KERNEL);
@@ -1646,10 +1650,10 @@ static int n_tty_open(struct tty_struct *tty)
tty->disc_data = ldata;
reset_buffer_flags(tty);
tty_unthrottle(tty);
-   ldata->column = 0;
+   //ldata->column = 0;/* Done by kzalloc */
n_tty_set_termios(tty, NULL);
tty->minimum_to_wake = 1;
-   tty->closing = 0;
+   //tty->closing = 0; /* Done by kzalloc */
 
return 0;
 err_free_bufs:
diff --git a/drivers/pps/clients/pps-ldisc.c b/drivers/pps/clients/pps-ldisc.c
index 79451f2..b5c6dd8 100644
--- a/drivers/pps/clients/pps-ldisc.c
+++ b/drivers/pps/clients/pps-ldisc.c
@@ -31,9 +31,16 @@
 static void pps_tty_dcd_change(struct tty_struct *tty, unsigned int status,
struct pps_event_time *ts)
 {
-   struct pps_device *pps = (struct pps_device *)tty->disc_data;
+   struct pps_device *pps = *(struct pps_device **)tty->disc_data;
 
-   BUG_ON(pps == NULL);
+   /* Because we set the pps field *after* the tty is opened, there's
+* a race window during which this can happen.
+*/
+   if (pps == NULL) {
+   pr_err("Race condition triggered, pps = NULL");
+   return;
+   }
+// BUG_ON(pps == NULL);
 
/* Now do the PPS event report */
pps_event(pps, ts, status ? PPS_CAPTUREASSERT :
@@ -67,7 +74,6 @@ static int pps_tty_open(struct tty_struct *tty)
pr_err("cannot register PPS source \"%s\"\n", info.path);
return -ENOMEM;
}
-   tty->disc_data = pps;
 
/* Should open N_TTY ldisc too */
ret = alias_n_tty_open(tty);
@@ -75,13 +81,13 @@ static int pps_tty_open(struct tty_struct *tty)
pr_err("cannot open tty ldisc \"%s\"\n", info.path);
goto err_unregister;
}
+   *(struct pps_device **)tty->disc_data = pps;
 
dev_info(pps->dev, "source \"%s\" added\n", info.path);
 
return 0;
 
 err_unregister:
-   tty->disc_data = NULL;
pps_unregister_source(pps);
return ret;
 }
@@ -90,11 +96,11 @@ static void (*alias_n_tty_close)(struct tty_struct *tty);
 
 static void pps_tty_close(struct tty_struct *tty)
 {
-   struct pps_device *pps = (struct pps_device *)tty->disc_data;
+   struct pps_device *pps = *(struct pps_device **)tty->disc_data;
 
+   *(struct pps_device **)tty->disc_data = NULL;
alias_n_tty_close(tty);
 
-   tty->disc_data = NULL;
dev_info(pps->dev, "removed\n");
pps_unregister_source(pps);
 }
--
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: build failure after merge of the xen-two tree

[Stephen Rothwell]

Hi Konrad,

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

arch/x86/xen/mmu.c: In function 'xen_init_mmu_ops':
arch/x86/xen/mmu.c:2213:10: error: 'struct x86_init_ops' has no member named 
'mapping'
arch/x86/xen/mmu.c:2213:39: error: 'xen_mapping_pagetable_reserve' undeclared 
(first use in this function)

Caused by commit 8154d7a6b9b9 ("xen/pvh: Implement MMU changes for PVH")
from the xen-two tree interacting with commit 6f80b68e9e51 ("x86, mm,
Xen: Remove mapping_pagetable_reserve()") from the tip tree.  The
automatic merge left the moved version of the above line intact while it
should have been removed (I assume).

I have added the following merge fix patch and can carry the fix as
necessary.

From: Stephen Rothwell 
Date: Mon, 4 Feb 2013 15:08:33 +1100
Subject: [PATCH] xen: fix bad merge of arch/x86/xen/mmu.c

Signed-off-by: Stephen Rothwell 
---
 arch/x86/xen/mmu.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 824706a..3228600 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -2210,7 +2210,6 @@ void __init xen_init_mmu_ops(void)
pv_mmu_ops.flush_tlb_others = xen_flush_tlb_others;
return;
}
-   x86_init.mapping.pagetable_reserve = xen_mapping_pagetable_reserve;
pv_mmu_ops = xen_mmu_ops;
 
memset(dummy_mapping, 0xff, PAGE_SIZE);
-- 
1.8.1

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


pgpkra6XoF2BU.pgp
Description: PGP signature

[PATCH] kdump: do not drop entire e820 in crash kernel

[Cliff Wickman]

From: Cliff Wickman 

The crash kernel is not able to find its root device if that device is not
on PCI 0.

This is because it is booted with the command line option memmap=exactmap
which currently clears the e820 table.  So ACPI processing does not
find reserved i/o spaces. 

This works for a device on PCI 0 because ACPI falls back to a legacy mode.
But the error message " [Firmware Bug]: PCI: MMCONFIG at
 [mem 0x8000-0x80cf] not reserved in ACPI motherboard resources"
is written to the log even in this functioning case.

It fails for some devices on UV2, and only for UV2, because SGI seems to
be the only manufacturer currently using the extended PCI(>0).

The fix is to not drop the entire e820 table on a memmap=exactmap, but
to preserve all the non-E820_RAM reservations that the BIOS has made.

Signed-off-by: Cliff Wickman 
---
 arch/x86/kernel/e820.c |   14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

Index: linus.current/arch/x86/kernel/e820.c
===
--- linus.current.orig/arch/x86/kernel/e820.c
+++ linus.current/arch/x86/kernel/e820.c
@@ -839,6 +839,8 @@ static int __init parse_memmap_opt(char
 {
char *oldp;
u64 start_at, mem_size;
+   int i;
+   struct e820entry *curp, *availp;
 
if (!p)
return -EINVAL;
@@ -852,7 +854,17 @@ static int __init parse_memmap_opt(char
 */
saved_max_pfn = e820_end_of_ram_pfn();
 #endif
-   e820.nr_map = 0;
+   /* keep everything that was reserved by the BIOS */
+   for (i = 0, curp = [0], availp = [0];
+   i < e820.nr_map; i++, curp++) {
+   if (curp->type != E820_RAM) {
+   if (curp != availp) {
+   *availp = *curp;
+   availp++;
+   }
+   }
+   }
+   e820.nr_map = availp - [0];
userdef = 1;
return 0;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v6 4/4] zram: get rid of lockdep warning

[Minchan Kim]

On Sun, Feb 03, 2013 at 07:50:13PM -0800, Greg Kroah-Hartman wrote:
> On Mon, Feb 04, 2013 at 12:42:08PM +0900, Minchan Kim wrote:
> > Hi Greg,
> > 
> > On Sun, Feb 03, 2013 at 05:53:33PM -0800, Greg Kroah-Hartman wrote:
> > > On Wed, Jan 30, 2013 at 11:41:42AM +0900, Minchan Kim wrote:
> > > > Lockdep complains about recursive deadlock of zram->init_lock.
> > > > [1] made it false positive because we can't request IO to zram
> > > > before setting disksize. Anyway, we should shut lockdep up to
> > > > avoid many reporting from user.
> > > > 
> > > > [1] : zram: force disksize setting before using zram
> > > > 
> > > > Acked-by: Jerome Marchand 
> > > > Acked-by: Nitin Gupta 
> > > > Signed-off-by: Minchan Kim 
> > > > ---
> > > >  drivers/staging/zram/zram_drv.c   |  189 
> > > > +++--
> > > >  drivers/staging/zram/zram_drv.h   |   12 ++-
> > > >  drivers/staging/zram/zram_sysfs.c |   11 ++-
> > > >  3 files changed, 116 insertions(+), 96 deletions(-)
> > > 
> > > This patch fails to apply to my staging-next branch, but the three
> > > others did, so I took them.  Please refresh this one and resend if you
> > > want it applied.
> > 
> > We must have missed each other.
> 
> Yes, I was on a flight with no email :)
> 
> > A few hours ago, I sent to you v7 based on next-20130202.
> > https://lkml.org/lkml/2013/2/3/319
> > 
> > v7 includes acks of Jerome and resolve conflict with latest staging.
> > I believe it is okay to apply your tree.
> > 
> > Please reapply v7 instead of v6.
> 
> Please just send the one patch I need to apply here, I added Jerome's
> acks to the previous patches already.

Thanks!

>From 4dec70e42324379730e6b4b6e41fc17f21a44917 Mon Sep 17 00:00:00 2001
From: Minchan Kim 
Date: Mon, 4 Feb 2013 08:41:24 +0900
Subject: [PATCH v7 4/4] zram: get rid of lockdep warning

Lockdep complains about recursive deadlock of zram->init_lock.
[1] made it false positive because we can't request IO to zram
before setting disksize. Anyway, we should shut lockdep up to
avoid many reporting from user.

[1] : zram: force disksize setting before using zram

Acked-by: Jerome Marchand 
Signed-off-by: Minchan Kim 
---
 drivers/staging/zram/zram_drv.c   |  189 +++--
 drivers/staging/zram/zram_drv.h   |   12 ++-
 drivers/staging/zram/zram_sysfs.c |   11 ++-
 3 files changed, 116 insertions(+), 96 deletions(-)

diff --git a/drivers/staging/zram/zram_drv.c b/drivers/staging/zram/zram_drv.c
index 85055c4..56e3203 100644
--- a/drivers/staging/zram/zram_drv.c
+++ b/drivers/staging/zram/zram_drv.c
@@ -61,22 +61,22 @@ static void zram_stat64_inc(struct zram *zram, u64 *v)
zram_stat64_add(zram, v, 1);
 }
 
-static int zram_test_flag(struct zram *zram, u32 index,
+static int zram_test_flag(struct zram_meta *meta, u32 index,
enum zram_pageflags flag)
 {
-   return zram->table[index].flags & BIT(flag);
+   return meta->table[index].flags & BIT(flag);
 }
 
-static void zram_set_flag(struct zram *zram, u32 index,
+static void zram_set_flag(struct zram_meta *meta, u32 index,
enum zram_pageflags flag)
 {
-   zram->table[index].flags |= BIT(flag);
+   meta->table[index].flags |= BIT(flag);
 }
 
-static void zram_clear_flag(struct zram *zram, u32 index,
+static void zram_clear_flag(struct zram_meta *meta, u32 index,
enum zram_pageflags flag)
 {
-   zram->table[index].flags &= ~BIT(flag);
+   meta->table[index].flags &= ~BIT(flag);
 }
 
 static int page_zero_filled(void *ptr)
@@ -96,16 +96,17 @@ static int page_zero_filled(void *ptr)
 
 static void zram_free_page(struct zram *zram, size_t index)
 {
-   unsigned long handle = zram->table[index].handle;
-   u16 size = zram->table[index].size;
+   struct zram_meta *meta = zram->meta;
+   unsigned long handle = meta->table[index].handle;
+   u16 size = meta->table[index].size;
 
if (unlikely(!handle)) {
/*
 * No memory is allocated for zero filled pages.
 * Simply clear zero page flag.
 */
-   if (zram_test_flag(zram, index, ZRAM_ZERO)) {
-   zram_clear_flag(zram, index, ZRAM_ZERO);
+   if (zram_test_flag(meta, index, ZRAM_ZERO)) {
+   zram_clear_flag(meta, index, ZRAM_ZERO);
zram->stats.pages_zero--;
}
return;
@@ -114,17 +115,17 @@ static void zram_free_page(struct zram *zram, size_t 
index)
if (unlikely(size > max_zpage_size))
zram->stats.bad_compress--;
 
-   zs_free(zram->mem_pool, handle);
+   zs_free(meta->mem_pool, handle);
 
if (size <= PAGE_SIZE / 2)
zram->stats.good_compress--;
 
zram_stat64_sub(zram, >stats.compr_size,
-   zram->table[index].size);
+   meta->table[index].size);

Re: [PATCH v6 4/4] zram: get rid of lockdep warning

[Greg Kroah-Hartman]

On Mon, Feb 04, 2013 at 12:42:08PM +0900, Minchan Kim wrote:
> Hi Greg,
> 
> On Sun, Feb 03, 2013 at 05:53:33PM -0800, Greg Kroah-Hartman wrote:
> > On Wed, Jan 30, 2013 at 11:41:42AM +0900, Minchan Kim wrote:
> > > Lockdep complains about recursive deadlock of zram->init_lock.
> > > [1] made it false positive because we can't request IO to zram
> > > before setting disksize. Anyway, we should shut lockdep up to
> > > avoid many reporting from user.
> > > 
> > > [1] : zram: force disksize setting before using zram
> > > 
> > > Acked-by: Jerome Marchand 
> > > Acked-by: Nitin Gupta 
> > > Signed-off-by: Minchan Kim 
> > > ---
> > >  drivers/staging/zram/zram_drv.c   |  189 
> > > +++--
> > >  drivers/staging/zram/zram_drv.h   |   12 ++-
> > >  drivers/staging/zram/zram_sysfs.c |   11 ++-
> > >  3 files changed, 116 insertions(+), 96 deletions(-)
> > 
> > This patch fails to apply to my staging-next branch, but the three
> > others did, so I took them.  Please refresh this one and resend if you
> > want it applied.
> 
> We must have missed each other.

Yes, I was on a flight with no email :)

> A few hours ago, I sent to you v7 based on next-20130202.
> https://lkml.org/lkml/2013/2/3/319
> 
> v7 includes acks of Jerome and resolve conflict with latest staging.
> I believe it is okay to apply your tree.
> 
> Please reapply v7 instead of v6.

Please just send the one patch I need to apply here, I added Jerome's
acks to the previous patches already.

thanks,

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

[PATCH 3/8] ethernet: Remove unnecessary alloc/OOM messages, alloc cleanups

[Joe Perches]

alloc failures already get standardized OOM
messages and a dump_stack.

Convert kzalloc's with multiplies to kcalloc.
Convert kmalloc's with multiplies to kmalloc_array.
Fix a few whitespace defects.
Convert a constant 6 to ETH_ALEN.
Use parentheses around sizeof.
Convert vmalloc/memset to vzalloc.
Remove now unused size variables.

Signed-off-by: Joe Perches 
---
 drivers/net/ethernet/atheros/atl1c/atl1c_main.c|  6 ++---
 drivers/net/ethernet/atheros/atl1e/atl1e_main.c|  2 --
 drivers/net/ethernet/broadcom/b44.c|  4 +---
 drivers/net/ethernet/broadcom/bcm63xx_enet.c   |  6 ++---
 drivers/net/ethernet/broadcom/cnic.c   |  6 ++---
 drivers/net/ethernet/broadcom/tg3.c|  4 +---
 drivers/net/ethernet/freescale/gianfar_ethtool.c   |  9 
 drivers/net/ethernet/ibm/ehea/ehea_main.c  |  4 +---
 drivers/net/ethernet/ibm/ehea/ehea_qmr.c   | 19 +--
 drivers/net/ethernet/ibm/emac/mal.c|  7 ++
 drivers/net/ethernet/ibm/ibmveth.c |  1 -
 drivers/net/ethernet/intel/igb/igb_main.c  |  5 ++--
 drivers/net/ethernet/intel/igbvf/netdev.c  |  8 +++
 drivers/net/ethernet/marvell/mv643xx_eth.c |  8 +++
 drivers/net/ethernet/marvell/mvmdio.c  |  1 -
 drivers/net/ethernet/marvell/skge.c|  5 ++--
 drivers/net/ethernet/marvell/sky2.c|  4 +---
 drivers/net/ethernet/mellanox/mlx4/en_main.c   |  4 +---
 drivers/net/ethernet/mellanox/mlx4/main.c  |  4 +---
 drivers/net/ethernet/myricom/myri10ge/myri10ge.c   |  5 ++--
 .../net/ethernet/qlogic/netxen/netxen_nic_ctx.c|  5 +---
 drivers/net/ethernet/qlogic/netxen/netxen_nic_hw.c | 18 ---
 .../net/ethernet/qlogic/netxen/netxen_nic_init.c   | 27 --
 .../net/ethernet/qlogic/netxen/netxen_nic_main.c   |  5 +---
 drivers/net/ethernet/qlogic/qla3xxx.c  | 10 
 .../net/ethernet/qlogic/qlcnic/qlcnic_83xx_init.c  | 14 ---
 drivers/net/ethernet/qlogic/qlcnic/qlcnic_hw.c |  6 ++---
 drivers/net/ethernet/qlogic/qlcnic/qlcnic_init.c   | 26 +++--
 drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c   | 19 +--
 .../net/ethernet/qlogic/qlcnic/qlcnic_minidump.c   |  7 ++
 drivers/net/ethernet/qlogic/qlge/qlge_main.c   |  1 -
 drivers/net/ethernet/rdc/r6040.c   |  3 +--
 drivers/net/ethernet/renesas/sh_eth.c  | 10 
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c  | 11 +
 drivers/net/ethernet/sun/niu.c |  2 +-
 drivers/net/ethernet/ti/cpsw.c |  8 +++
 drivers/net/ethernet/ti/davinci_mdio.c |  4 +---
 drivers/net/ethernet/xilinx/ll_temac_main.c|  6 ++---
 38 files changed, 97 insertions(+), 197 deletions(-)

diff --git a/drivers/net/ethernet/atheros/atl1c/atl1c_main.c 
b/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
index 8df02ba..571b514 100644
--- a/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
+++ b/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
@@ -982,11 +982,9 @@ static int atl1c_setup_ring_resources(struct atl1c_adapter 
*adapter)
size = sizeof(struct atl1c_buffer) * (tpd_ring->count * 2 +
rfd_ring->count);
tpd_ring->buffer_info = kzalloc(size, GFP_KERNEL);
-   if (unlikely(!tpd_ring->buffer_info)) {
-   dev_err(>dev, "kzalloc failed, size = %d\n",
-   size);
+   if (unlikely(!tpd_ring->buffer_info))
goto err_nomem;
-   }
+
for (i = 0; i < AT_MAX_TRANSMIT_QUEUE; i++) {
tpd_ring[i].buffer_info =
(tpd_ring->buffer_info + count);
diff --git a/drivers/net/ethernet/atheros/atl1e/atl1e_main.c 
b/drivers/net/ethernet/atheros/atl1e/atl1e_main.c
index cf79d93..92f4734 100644
--- a/drivers/net/ethernet/atheros/atl1e/atl1e_main.c
+++ b/drivers/net/ethernet/atheros/atl1e/atl1e_main.c
@@ -819,8 +819,6 @@ static int atl1e_setup_ring_resources(struct atl1e_adapter 
*adapter)
size = sizeof(struct atl1e_tx_buffer) * (tx_ring->count);
tx_ring->tx_buffer = kzalloc(size, GFP_KERNEL);
if (tx_ring->tx_buffer == NULL) {
-   netdev_err(adapter->netdev, "kzalloc failed, size = D%d\n",
-  size);
err = -ENOMEM;
goto failed;
}
diff --git a/drivers/net/ethernet/broadcom/b44.c 
b/drivers/net/ethernet/broadcom/b44.c
index 3ba6be6..c030274 100644
--- a/drivers/net/ethernet/broadcom/b44.c
+++ b/drivers/net/ethernet/broadcom/b44.c
@@ -1518,10 +1518,8 @@ static void b44_setup_pseudo_magicp(struct b44 *bp)
u8 pwol_mask[B44_PMASK_SIZE];
 
pwol_pattern = kzalloc(B44_PATTERN_SIZE, GFP_KERNEL);
-   if (!pwol_pattern) {
-   pr_err("Memory not available for WOL\n");
+   if (!pwol_pattern)
return;
-   }
 
/* Ipv4 magic 

Re: [PATCH 0/4] mfd/regulator: tps65090: add DT support and suspend/resume cleanups

[Laxman Dewangan]

On Monday 04 February 2013 04:03 AM, Samuel Ortiz wrote:

Hi Laxman,

On Sun, Feb 03, 2013 at 03:19:31PM +0100, Samuel Ortiz wrote:

Hi Laxman,

On Fri, Dec 28, 2012 at 02:59:37PM +0530, Laxman Dewangan wrote:

The patch series add DT support on TPS65090 device.

Also remove the suspend/resume implementation as it duplicates with
irq_suspend/irq_resume().

Laxman Dewangan (4):
   mfd: tps65090: add DT support for tps65090
   regulator: tps65090: add DT support
   mfd: tps65090: Pass irq domain when adding mfd sub devices
   mfd: tps65090: remove suspend/resume callbacks

  .../devicetree/bindings/regulator/tps65090.txt |  121 
  drivers/mfd/tps65090.c |   77 
  drivers/regulator/tps65090-regulator.c |   96 +++-
  include/linux/mfd/tps65090.h   |1 +
  4 files changed, 266 insertions(+), 29 deletions(-)
  create mode 100644 Documentation/devicetree/bindings/regulator/tps65090.txt

All 4 patches applied to my for-next branch, thanks.

Sorry for the confusion: I took v2 of your patchset, skipping the regulator
patch who will go through Mark's tree.


Thank you very much. The regulator patch is already applied in Mark's tree.

Thanks,
Laxman
--
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 v6 4/4] zram: get rid of lockdep warning

[Minchan Kim]

Hi Greg,

On Sun, Feb 03, 2013 at 05:53:33PM -0800, Greg Kroah-Hartman wrote:
> On Wed, Jan 30, 2013 at 11:41:42AM +0900, Minchan Kim wrote:
> > Lockdep complains about recursive deadlock of zram->init_lock.
> > [1] made it false positive because we can't request IO to zram
> > before setting disksize. Anyway, we should shut lockdep up to
> > avoid many reporting from user.
> > 
> > [1] : zram: force disksize setting before using zram
> > 
> > Acked-by: Jerome Marchand 
> > Acked-by: Nitin Gupta 
> > Signed-off-by: Minchan Kim 
> > ---
> >  drivers/staging/zram/zram_drv.c   |  189 
> > +++--
> >  drivers/staging/zram/zram_drv.h   |   12 ++-
> >  drivers/staging/zram/zram_sysfs.c |   11 ++-
> >  3 files changed, 116 insertions(+), 96 deletions(-)
> 
> This patch fails to apply to my staging-next branch, but the three
> others did, so I took them.  Please refresh this one and resend if you
> want it applied.

We must have missed each other.
A few hours ago, I sent to you v7 based on next-20130202.
https://lkml.org/lkml/2013/2/3/319

v7 includes acks of Jerome and resolve conflict with latest staging.
I believe it is okay to apply your tree.

Please reapply v7 instead of v6.

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

-- 
Kind regards,
Minchan Kim
--
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] idr: fix a subtle bug in idr_get_next()

[Li Zefan]

On 2013/2/3 7:10, Tejun Heo wrote:
> The iteration logic of idr_get_next() is borrowed mostly verbatim from
> idr_for_each().  It walks down the tree looking for the slot matching
> the current ID.  If the matching slot is not found, the ID is
> incremented by the distance of single slot at the given level and
> repeats.
> 
> The implementation assumes that during the whole iteration id is
> aligned to the layer boundaries of the level closest to the leaf,
> which is true for all iterations starting from zero or an existing
> element and thus is fine for idr_for_each().
> 
> However, idr_get_next() may be given any point and if the starting id
> hits in the middle of a non-existent layer, increment to the next
> layer will end up skipping the same offset into it.  For example, an
> IDR with IDs filled between [64, 127] would look like the following.
> 
>   [  0  64 ... ]
>//   |
>||
>   NULL[ 64 ... 127 ]
> 
> If idr_get_next() is called with 63 as the starting point, it will try
> to follow down the pointer from 0.  As it is NULL, it will then try to
> proceed to the next slot in the same level by adding the slot distance
> at that level which is 64 - making the next try 127.  It goes around
> the loop and finds and returns 127 skipping [64, 126].
> 
> Note that this bug also triggers in idr_for_each_entry() loop which
> deletes during iteration as deletions can make layers go away leaving
> the iteration with unaligned ID into missing layers.
> 
> Fix it by ensuring proceeding to the next slot doesn't carry over the
> unaligned offset - ie. use round_up(id + 1, slot_distance) instead of
> id += slot_distance.
> 
> Signed-off-by: Tejun Heo 

Don't we need to cc stable?

> Reported-by: David Teigland 
> Cc: KAMEZAWA Hiroyuki 
> ---
>  lib/idr.c |9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/lib/idr.c b/lib/idr.c
> index 6482390..ca5aa00 100644
> --- a/lib/idr.c
> +++ b/lib/idr.c
> @@ -625,7 +625,14 @@ void *idr_get_next(struct idr *idp, int *nextidp)
>   return p;
>   }
>  
> - id += 1 << n;
> + /*
> +  * Proceed to the next layer at the current level.  Unlike
> +  * idr_for_each(), @id isn't guaranteed to be aligned to
> +  * layer boundary at this point and adding 1 << n may
> +  * incorrectly skip IDs.  Make sure we jump to the
> +  * beginning of the next layer using round_up().
> +  */
> + id = round_up(id + 1, 1 << n);
>   while (n < fls(id)) {
>   n += IDR_BITS;
>   p = *--paa;
> --

--
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] mm: shmem: use new radix tree iterator

[Hugh Dickins]

On Sat, 2 Feb 2013, Konstantin Khlebnikov wrote:
> Johannes Weiner wrote:
> > In shmem_find_get_pages_and_swap, use the faster radix tree iterator
> > construct from 78c1d78 "radix-tree: introduce bit-optimized iterator".
> > 
> > Signed-off-by: Johannes Weiner
> 
> Hmm, ACK. shmem_unuse_inode() also can be redone in this way.
> I did something similar year ago: https://lkml.org/lkml/2012/2/10/388
> As result we can rid of radix_tree_locate_item() and
> shmem_find_get_pages_and_swap()

Indeed you did, and never got more than a "I have some reservations"
response out of me; and already we had both moved on to much more
pressing lruvec and other concerns.

My first reaction on seeing Johannes' patch was, not to ack it immediately,
but look back to your series of 6 (or 4): shmem_find_get_pages_and_swap()
doesn't get updated in yours, but vanishes in the last patch, which was
among the ones I was uneasy about.  Here's a belated account of my
reactions to your series.

[PATCH 1/4] shmem: simplify shmem_unlock_mapping
Probably good, though should also update the "only reach" comment in
find_get_pages(); and probably not worthwhile unless shmem_find_get_
pages_and_swap() is to disappear entirely.

[PATCH 2/4] shmem: tag swap entries in radix tree
Using a tag instead of and in addition to the swap exceptional entries
was certainly something I tried when I was updating shmem_unuse(): it
just didn't work as well as I'd hoped and needed, nothing worked as
"well" as the radix_tree_locate_item() thing I added, though I'd have
preferred to avoid adding it.  So I needed to test and understand why
you found tags worked where I had not: probably partly your intervening
radix_tree changes, and partly a difference in how we tested.  There
was also a little issue fo SHMEM_TAG_SWAP == PAGECACHE_TAG_DIRTY: you
were absolutely right not to enlarge the tagspace, but at that time
there was a weird issue of page migration putting a dirty tag into
the tmpfs radix_tree, which later I worked around in 752dc185.

[PATCH 3/4] shmem: use radix-tree iterator in shmem_unuse_inode()
Removes lots of code which is great, but as I said, I'd need
to investigate why tagging worked for you but not for me.

[PATCH 4/4] mm: use swap readahead at swapoff
I've tried that down the years from time to time, and never found
it useful (but I see you found it works better in a virtual machine).
I've no strong objection to the patch, but when I rewrote try_to_unuse()
twelve years ago, I was overly sensitive to readahead adding pressure in
the case where you're already swapping off under pressure, and preferred
to avoid the readahead if it didn't help.  The slowness of swapoff has
very little to do with readahead or not, or that's what I always found:
if swapoff while loaded, readahead increased the memory pressure; if
(usual case) swapoff while not loaded, apparently the disk's own
caching was good enough that kernel readahead made no difference.

[PATCH 5/4] shmem: put shmem_delete_from_page_cache under CONFIG_SWAP
I'm completely schizophrenic about #fidef CONFIG_SWAPs, sometimes I
love to add them, and sometimes I think they're ugly.  You're probably
right that mm/shmem.c should have more of them, it helps document too.

[PATCH 6/4] shmem: simplify shmem_truncate_range
Where shmem_find_get_pages_and_swap() goes away.  But
you replace (what was then) shmem_truncate_range() by two passes,
truncate_inode_pages_range() followed by shmem_truncate_swap_range().
That's not good enough, and part of what I was getting away from with
the radix_tree exceptional swap changes: there needs to be more, to
prevent pages moving to swap before the page pass finds them, then
swap moving to pages before the swap pass finds them.  The old code
used a flag to go back whenever that might happen, effective but not
pretty (and I'm not sure complete).  I ought to like your end result,
with so much code deleted; but somehow I did not, just too attached
to my own I suppose :) Intervening (fallocate) changes have moved this
code around, certainly your old patch would not apply, whether they've
made any material difficulty I've not considered.

As usual, I'm busy with other things, so not actually in any hurry
for a resend; but thought I'd better let you know what I'd thought,
in case Johannes' patch prompted you towards a resend.

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

[PATCH 8/8] drivers:net:misc: Remove unnecessary alloc/OOM messages

[Joe Perches]

alloc failures already get standardized OOM
messages and a dump_stack.

Signed-off-by: Joe Perches 
---
 drivers/net/hamradio/dmascc.c | 7 +--
 drivers/net/phy/spi_ks8995.c  | 4 +---
 drivers/net/virtio_net.c  | 4 +---
 3 files changed, 3 insertions(+), 12 deletions(-)

diff --git a/drivers/net/hamradio/dmascc.c b/drivers/net/hamradio/dmascc.c
index ce555d9..6636022 100644
--- a/drivers/net/hamradio/dmascc.c
+++ b/drivers/net/hamradio/dmascc.c
@@ -463,13 +463,8 @@ static int __init setup_adapter(int card_base, int type, 
int n)
 
/* Initialize what is necessary for write_scc and write_scc_data */
info = kzalloc(sizeof(struct scc_info), GFP_KERNEL | GFP_DMA);
-   if (!info) {
-   printk(KERN_ERR "dmascc: "
-  "could not allocate memory for %s at %#3x\n",
-  hw[type].name, card_base);
+   if (!info)
goto out;
-   }
-
 
info->dev[0] = alloc_netdev(0, "", dev_setup);
if (!info->dev[0]) {
diff --git a/drivers/net/phy/spi_ks8995.c b/drivers/net/phy/spi_ks8995.c
index 41eb8ff..5c87eef 100644
--- a/drivers/net/phy/spi_ks8995.c
+++ b/drivers/net/phy/spi_ks8995.c
@@ -275,10 +275,8 @@ static int ks8995_probe(struct spi_device *spi)
pdata = spi->dev.platform_data;
 
ks = kzalloc(sizeof(*ks), GFP_KERNEL);
-   if (!ks) {
-   dev_err(>dev, "no memory for private data\n");
+   if (!ks)
return -ENOMEM;
-   }
 
mutex_init(>lock);
ks->pdata = pdata;
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index eda2042..381a2d8 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -976,10 +976,8 @@ static void virtnet_set_rx_mode(struct net_device *dev)
buf = kzalloc(((uc_count + mc_count) * ETH_ALEN) +
  (2 * sizeof(mac_data->entries)), GFP_ATOMIC);
mac_data = buf;
-   if (!buf) {
-   dev_warn(>dev, "No memory for MAC address buffer\n");
+   if (!buf)
return;
-   }
 
sg_init_table(sg, 2);
 
-- 
1.8.0.dirty

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

[PATCH 7/8] wireless: Remove unnecessary alloc/OOM messages, alloc cleanups

[Joe Perches]

alloc failures already get standardized OOM
messages and a dump_stack.

Convert kzalloc's with multiplies to kcalloc.
Convert kmalloc's with multiplies to kmalloc_array.
Remove now unused variables.
Remove unnecessary memset after kzalloc->kcalloc.
Whitespace cleanups for these changes.

Signed-off-by: Joe Perches 
---
 drivers/net/wireless/airo_cs.c |  5 ++--
 drivers/net/wireless/at76c50x-usb.c|  4 +---
 .../net/wireless/ath/ath9k/dfs_pattern_detector.c  |  6 ++---
 drivers/net/wireless/atmel_cs.c|  5 ++--
 drivers/net/wireless/ipw2x00/ipw2100.c |  9 +++-
 drivers/net/wireless/libertas/cfg.c|  4 +---
 drivers/net/wireless/mwifiex/11n.c |  5 +---
 drivers/net/wireless/mwifiex/11n_rxreorder.c   |  5 +---
 drivers/net/wireless/mwifiex/cfg80211.c|  4 +---
 drivers/net/wireless/mwifiex/cmdevt.c  | 11 +++--
 drivers/net/wireless/mwifiex/init.c|  5 +---
 drivers/net/wireless/mwifiex/scan.c| 27 +++---
 drivers/net/wireless/mwifiex/sdio.c| 11 ++---
 drivers/net/wireless/mwifiex/sta_ioctl.c   | 11 +++--
 drivers/net/wireless/mwifiex/wmm.c |  7 ++
 drivers/net/wireless/orinoco/main.c| 16 -
 drivers/net/wireless/p54/p54usb.c  | 10 ++--
 drivers/net/wireless/prism54/islpci_mgt.c  | 14 ---
 drivers/net/wireless/rndis_wlan.c  |  5 +---
 drivers/net/wireless/ti/wlcore/sdio.c  |  4 +---
 drivers/net/wireless/ti/wlcore/spi.c   | 14 +++
 drivers/net/wireless/zd1211rw/zd_usb.c |  1 -
 22 files changed, 50 insertions(+), 133 deletions(-)

diff --git a/drivers/net/wireless/airo_cs.c b/drivers/net/wireless/airo_cs.c
index 630577d..956024a 100644
--- a/drivers/net/wireless/airo_cs.c
+++ b/drivers/net/wireless/airo_cs.c
@@ -69,10 +69,9 @@ static int airo_probe(struct pcmcia_device *p_dev)
 
/* Allocate space for private device-specific data */
local = kzalloc(sizeof(local_info_t), GFP_KERNEL);
-   if (!local) {
-   printk(KERN_ERR "airo_cs: no memory for new device\n");
+   if (!local)
return -ENOMEM;
-   }
+
p_dev->priv = local;
 
return airo_config(p_dev);
diff --git a/drivers/net/wireless/at76c50x-usb.c 
b/drivers/net/wireless/at76c50x-usb.c
index 77fa428..5ac5f7a 100644
--- a/drivers/net/wireless/at76c50x-usb.c
+++ b/drivers/net/wireless/at76c50x-usb.c
@@ -2164,10 +2164,8 @@ static int at76_alloc_urbs(struct at76_priv *priv,
 
buffer_size = sizeof(struct at76_tx_buffer) + MAX_PADDING_SIZE;
priv->bulk_out_buffer = kmalloc(buffer_size, GFP_KERNEL);
-   if (!priv->bulk_out_buffer) {
-   dev_err(>dev, "cannot allocate output buffer\n");
+   if (!priv->bulk_out_buffer)
return -ENOMEM;
-   }
 
at76_dbg(DBG_PROC_ENTRY, "%s: EXIT", __func__);
 
diff --git a/drivers/net/wireless/ath/ath9k/dfs_pattern_detector.c 
b/drivers/net/wireless/ath/ath9k/dfs_pattern_detector.c
index 24877b0..467b600 100644
--- a/drivers/net/wireless/ath/ath9k/dfs_pattern_detector.c
+++ b/drivers/net/wireless/ath/ath9k/dfs_pattern_detector.c
@@ -288,11 +288,11 @@ struct dfs_pattern_detector *
 dfs_pattern_detector_init(enum nl80211_dfs_regions region)
 {
struct dfs_pattern_detector *dpd;
+
dpd = kmalloc(sizeof(*dpd), GFP_KERNEL);
-   if (dpd == NULL) {
-   pr_err("allocation of dfs_pattern_detector failed\n");
+   if (dpd == NULL)
return NULL;
-   }
+
*dpd = default_dpd;
INIT_LIST_HEAD(>channel_detectors);
 
diff --git a/drivers/net/wireless/atmel_cs.c b/drivers/net/wireless/atmel_cs.c
index ded03d2..b42930f 100644
--- a/drivers/net/wireless/atmel_cs.c
+++ b/drivers/net/wireless/atmel_cs.c
@@ -79,10 +79,9 @@ static int atmel_probe(struct pcmcia_device *p_dev)
 
/* Allocate space for private device-specific data */
local = kzalloc(sizeof(local_info_t), GFP_KERNEL);
-   if (!local) {
-   printk(KERN_ERR "atmel_cs: no memory for new device\n");
+   if (!local)
return -ENOMEM;
-   }
+
p_dev->priv = local;
 
return atmel_config(p_dev);
diff --git a/drivers/net/wireless/ipw2x00/ipw2100.c 
b/drivers/net/wireless/ipw2x00/ipw2100.c
index d92b21a..04d5e64 100644
--- a/drivers/net/wireless/ipw2x00/ipw2100.c
+++ b/drivers/net/wireless/ipw2x00/ipw2100.c
@@ -4478,13 +4478,10 @@ static int ipw2100_tx_allocate(struct ipw2100_priv 
*priv)
return err;
}
 
-   priv->tx_buffers =
-   kmalloc(TX_PENDED_QUEUE_LENGTH * sizeof(struct ipw2100_tx_packet),
-   GFP_ATOMIC);
+   priv->tx_buffers = kmalloc_array(TX_PENDED_QUEUE_LENGTH,
+sizeof(struct 

[PATCH 6/8] wimax: Remove unnecessary alloc/OOM messages, alloc cleanups

[Joe Perches]

alloc failures already get standardized OOM
messages and a dump_stack.

Convert kzalloc's with multiplies to kcalloc.
Remove now unused size variables.

Signed-off-by: Joe Perches 
---
 drivers/net/wimax/i2400m/rx.c| 16 +---
 drivers/net/wimax/i2400m/usb-notif.c |  1 -
 2 files changed, 5 insertions(+), 12 deletions(-)

diff --git a/drivers/net/wimax/i2400m/rx.c b/drivers/net/wimax/i2400m/rx.c
index 37becfc..8077e6e 100644
--- a/drivers/net/wimax/i2400m/rx.c
+++ b/drivers/net/wimax/i2400m/rx.c
@@ -1351,24 +1351,18 @@ int i2400m_rx_setup(struct i2400m *i2400m)
i2400m->rx_reorder = i2400m_rx_reorder_disabled? 0 : 1;
if (i2400m->rx_reorder) {
unsigned itr;
-   size_t size;
struct i2400m_roq_log *rd;
 
result = -ENOMEM;
 
-   size = sizeof(i2400m->rx_roq[0]) * (I2400M_RO_CIN + 1);
-   i2400m->rx_roq = kzalloc(size, GFP_KERNEL);
-   if (i2400m->rx_roq == NULL) {
-   dev_err(dev, "RX: cannot allocate %zu bytes for "
-   "reorder queues\n", size);
+   i2400m->rx_roq = kcalloc(I2400M_RO_CIN + 1,
+sizeof(i2400m->rx_roq[0]), GFP_KERNEL);
+   if (i2400m->rx_roq == NULL)
goto error_roq_alloc;
-   }
 
-   size = sizeof(*i2400m->rx_roq[0].log) * (I2400M_RO_CIN + 1);
-   rd = kzalloc(size, GFP_KERNEL);
+   rd = kcalloc(I2400M_RO_CIN + 1, sizeof(*i2400m->rx_roq[0].log),
+GFP_KERNEL);
if (rd == NULL) {
-   dev_err(dev, "RX: cannot allocate %zu bytes for "
-   "reorder queues log areas\n", size);
result = -ENOMEM;
goto error_roq_log_alloc;
}
diff --git a/drivers/net/wimax/i2400m/usb-notif.c 
b/drivers/net/wimax/i2400m/usb-notif.c
index d44b545..fc1355d 100644
--- a/drivers/net/wimax/i2400m/usb-notif.c
+++ b/drivers/net/wimax/i2400m/usb-notif.c
@@ -199,7 +199,6 @@ int i2400mu_notification_setup(struct i2400mu *i2400mu)
d_fnstart(4, dev, "(i2400m %p)\n", i2400mu);
buf = kmalloc(I2400MU_MAX_NOTIFICATION_LEN, GFP_KERNEL | GFP_DMA);
if (buf == NULL) {
-   dev_err(dev, "notification: buffer allocation failed\n");
ret = -ENOMEM;
goto error_buf_alloc;
}
-- 
1.8.0.dirty

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

[PATCH 5/8] wan: Remove unnecessary alloc/OOM messages

[Joe Perches]

alloc failures already get standardized OOM
messages and a dump_stack.

Hoist assigns from if tests.

Signed-off-by: Joe Perches 
---
 drivers/net/wan/cosa.c| 9 -
 drivers/net/wan/farsync.c | 6 ++
 drivers/net/wan/hdlc.c| 9 -
 drivers/net/wan/x25_asy.c | 1 -
 4 files changed, 10 insertions(+), 15 deletions(-)

diff --git a/drivers/net/wan/cosa.c b/drivers/net/wan/cosa.c
index 6aed238..0179cef 100644
--- a/drivers/net/wan/cosa.c
+++ b/drivers/net/wan/cosa.c
@@ -795,8 +795,8 @@ static ssize_t cosa_read(struct file *file,
if (mutex_lock_interruptible(>rlock))
return -ERESTARTSYS;

-   if ((chan->rxdata = kmalloc(COSA_MTU, GFP_DMA|GFP_KERNEL)) == NULL) {
-   pr_info("%s: cosa_read() - OOM\n", cosa->name);
+   chan->rxdata = kmalloc(COSA_MTU, GFP_DMA|GFP_KERNEL);
+   if (chan->rxdata == NULL) {
mutex_unlock(>rlock);
return -ENOMEM;
}
@@ -874,9 +874,8 @@ static ssize_t cosa_write(struct file *file,
count = COSA_MTU;

/* Allocate the buffer */
-   if ((kbuf = kmalloc(count, GFP_KERNEL|GFP_DMA)) == NULL) {
-   pr_notice("%s: cosa_write() OOM - dropping packet\n",
- cosa->name);
+   kbuf = kmalloc(count, GFP_KERNEL|GFP_DMA);
+   if (kbuf == NULL) {
up(>wsem);
return -ENOMEM;
}
diff --git a/drivers/net/wan/farsync.c b/drivers/net/wan/farsync.c
index 56941d6..3f0c4f2 100644
--- a/drivers/net/wan/farsync.c
+++ b/drivers/net/wan/farsync.c
@@ -2448,11 +2448,9 @@ fst_add_one(struct pci_dev *pdev, const struct 
pci_device_id *ent)
}
 
/* Allocate driver private data */
-   card = kzalloc(sizeof (struct fst_card_info), GFP_KERNEL);
-   if (card == NULL) {
-   pr_err("FarSync card found but insufficient memory for driver 
storage\n");
+   card = kzalloc(sizeof(struct fst_card_info), GFP_KERNEL);
+   if (card == NULL)
return -ENOMEM;
-   }
 
/* Try to enable the device */
if ((err = pci_enable_device(pdev)) != 0) {
diff --git a/drivers/net/wan/hdlc.c b/drivers/net/wan/hdlc.c
index 10cc7df..a0a932c 100644
--- a/drivers/net/wan/hdlc.c
+++ b/drivers/net/wan/hdlc.c
@@ -280,14 +280,13 @@ int attach_hdlc_protocol(struct net_device *dev, struct 
hdlc_proto *proto,
if (!try_module_get(proto->module))
return -ENOSYS;
 
-   if (size)
-   if ((dev_to_hdlc(dev)->state = kmalloc(size,
-  GFP_KERNEL)) == NULL) {
-   netdev_warn(dev,
-   "Memory squeeze on hdlc_proto_attach()\n");
+   if (size) {
+   dev_to_hdlc(dev)->state = kmalloc(size, GFP_KERNEL);
+   if (dev_to_hdlc(dev)->state == NULL) {
module_put(proto->module);
return -ENOBUFS;
}
+   }
dev_to_hdlc(dev)->proto = proto;
return 0;
 }
diff --git a/drivers/net/wan/x25_asy.c b/drivers/net/wan/x25_asy.c
index 44db8b7..5895f19 100644
--- a/drivers/net/wan/x25_asy.c
+++ b/drivers/net/wan/x25_asy.c
@@ -128,7 +128,6 @@ static int x25_asy_change_mtu(struct net_device *dev, int 
newmtu)
rbuff = kmalloc(len + 4, GFP_ATOMIC);
 
if (xbuff == NULL || rbuff == NULL) {
-   netdev_warn(dev, "unable to grow X.25 buffers, MTU change 
cancelled\n");
kfree(xbuff);
kfree(rbuff);
return -ENOMEM;
-- 
1.8.0.dirty

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

[PATCH 4/8] drivers: net: usb: Remove unnecessary alloc/OOM messages

[Joe Perches]

alloc failures already get standardized OOM
messages and a dump_stack.

Signed-off-by: Joe Perches 
---
 drivers/net/usb/ax88172a.c   |  6 ++
 drivers/net/usb/hso.c| 25 +++--
 drivers/net/usb/sierra_net.c | 10 +++---
 drivers/net/usb/smsc75xx.c   |  6 ++
 drivers/net/usb/smsc95xx.c   |  6 ++
 drivers/net/usb/usbnet.c |  5 +
 6 files changed, 17 insertions(+), 41 deletions(-)

diff --git a/drivers/net/usb/ax88172a.c b/drivers/net/usb/ax88172a.c
index 76ee541..d012203 100644
--- a/drivers/net/usb/ax88172a.c
+++ b/drivers/net/usb/ax88172a.c
@@ -117,7 +117,6 @@ static int ax88172a_init_mdio(struct usbnet *dev)
 
priv->mdio->irq = kzalloc(sizeof(int) * PHY_MAX_ADDR, GFP_KERNEL);
if (!priv->mdio->irq) {
-   netdev_err(dev->net, "Could not allocate mdio->irq\n");
ret = -ENOMEM;
goto mfree;
}
@@ -236,10 +235,9 @@ static int ax88172a_bind(struct usbnet *dev, struct 
usb_interface *intf)
usbnet_get_endpoints(dev, intf);
 
priv = kzalloc(sizeof(*priv), GFP_KERNEL);
-   if (!priv) {
-   netdev_err(dev->net, "Could not allocate memory for private 
data\n");
+   if (!priv)
return -ENOMEM;
-   }
+
dev->driver_priv = priv;
 
/* Get the MAC address */
diff --git a/drivers/net/usb/hso.c b/drivers/net/usb/hso.c
index f902a14..e2dd324 100644
--- a/drivers/net/usb/hso.c
+++ b/drivers/net/usb/hso.c
@@ -2315,10 +2315,8 @@ static int hso_serial_common_create(struct hso_serial 
*serial, int num_urbs,
serial->rx_urb[i]->transfer_buffer_length = 0;
serial->rx_data[i] = kzalloc(serial->rx_data_length,
 GFP_KERNEL);
-   if (!serial->rx_data[i]) {
-   dev_err(dev, "%s - Out of memory\n", __func__);
+   if (!serial->rx_data[i])
goto exit;
-   }
}
 
/* TX, allocate urb and initialize */
@@ -2334,15 +2332,12 @@ static int hso_serial_common_create(struct hso_serial 
*serial, int num_urbs,
serial->tx_buffer_count = 0;
serial->tx_data_length = tx_size;
serial->tx_data = kzalloc(serial->tx_data_length, GFP_KERNEL);
-   if (!serial->tx_data) {
-   dev_err(dev, "%s - Out of memory\n", __func__);
+   if (!serial->tx_data)
goto exit;
-   }
+
serial->tx_buffer = kzalloc(serial->tx_data_length, GFP_KERNEL);
-   if (!serial->tx_buffer) {
-   dev_err(dev, "%s - Out of memory\n", __func__);
+   if (!serial->tx_buffer)
goto exit;
-   }
 
return 0;
 exit:
@@ -2578,10 +2573,8 @@ static struct hso_device *hso_create_net_device(struct 
usb_interface *interface,
}
hso_net->mux_bulk_rx_buf_pool[i] = kzalloc(MUX_BULK_RX_BUF_SIZE,
   GFP_KERNEL);
-   if (!hso_net->mux_bulk_rx_buf_pool[i]) {
-   dev_err(>dev, "Could not allocate rx buf\n");
+   if (!hso_net->mux_bulk_rx_buf_pool[i])
goto exit;
-   }
}
hso_net->mux_bulk_tx_urb = usb_alloc_urb(0, GFP_KERNEL);
if (!hso_net->mux_bulk_tx_urb) {
@@ -2589,10 +2582,8 @@ static struct hso_device *hso_create_net_device(struct 
usb_interface *interface,
goto exit;
}
hso_net->mux_bulk_tx_buf = kzalloc(MUX_BULK_TX_BUF_SIZE, GFP_KERNEL);
-   if (!hso_net->mux_bulk_tx_buf) {
-   dev_err(>dev, "Could not allocate tx buf\n");
+   if (!hso_net->mux_bulk_tx_buf)
goto exit;
-   }
 
add_net_device(hso_dev);
 
@@ -2816,10 +2807,8 @@ struct hso_shared_int *hso_create_shared_int(struct 
usb_interface *interface)
mux->shared_intr_buf =
kzalloc(le16_to_cpu(mux->intr_endp->wMaxPacketSize),
GFP_KERNEL);
-   if (!mux->shared_intr_buf) {
-   dev_err(>dev, "Could not allocate intr buf?\n");
+   if (!mux->shared_intr_buf)
goto exit;
-   }
 
mutex_init(>shared_int_lock);
 
diff --git a/drivers/net/usb/sierra_net.c b/drivers/net/usb/sierra_net.c
index 453aa6c..79ab243 100644
--- a/drivers/net/usb/sierra_net.c
+++ b/drivers/net/usb/sierra_net.c
@@ -459,11 +459,9 @@ static void sierra_net_kevent(struct work_struct *work)
 
/* Query the modem for the LSI message */
buf = kzalloc(SIERRA_NET_USBCTL_BUF_LEN, GFP_KERNEL);
-   if (!buf) {
-   netdev_err(dev->net,
-   "failed to allocate buf for LS msg\n");
+   if (!buf)
return;
-   }
+
ifnum = priv->ifnum;
len = usb_control_msg(dev->udev, usb_rcvctrlpipe(dev->udev, 0),
 

[PATCH 2/8] can: Remove unnecessary alloc/OOM messages

[Joe Perches]

alloc failures already get standardized OOM
messages and a dump_stack.

Signed-off-by: Joe Perches 
---
 drivers/net/can/sja1000/ems_pci.c| 1 -
 drivers/net/can/sja1000/peak_pci.c   | 5 +
 drivers/net/can/sja1000/peak_pcmcia.c| 1 -
 drivers/net/can/sja1000/plx_pci.c| 1 -
 drivers/net/can/usb/ems_usb.c| 4 +---
 drivers/net/can/usb/kvaser_usb.c | 2 --
 drivers/net/can/usb/peak_usb/pcan_usb_core.c | 5 -
 drivers/net/can/usb/usb_8dev.c   | 4 +---
 8 files changed, 3 insertions(+), 20 deletions(-)

diff --git a/drivers/net/can/sja1000/ems_pci.c 
b/drivers/net/can/sja1000/ems_pci.c
index 036a326..36d298d 100644
--- a/drivers/net/can/sja1000/ems_pci.c
+++ b/drivers/net/can/sja1000/ems_pci.c
@@ -238,7 +238,6 @@ static int ems_pci_add_card(struct pci_dev *pdev,
/* Allocating card structures to hold addresses, ... */
card = kzalloc(sizeof(struct ems_pci_card), GFP_KERNEL);
if (card == NULL) {
-   dev_err(>dev, "Unable to allocate memory\n");
pci_disable_device(pdev);
return -ENOMEM;
}
diff --git a/drivers/net/can/sja1000/peak_pci.c 
b/drivers/net/can/sja1000/peak_pci.c
index 600ac72..d1e7f10 100644
--- a/drivers/net/can/sja1000/peak_pci.c
+++ b/drivers/net/can/sja1000/peak_pci.c
@@ -450,11 +450,8 @@ static int peak_pciec_probe(struct pci_dev *pdev, struct 
net_device *dev)
} else {
/* create the bit banging I2C adapter structure */
card = kzalloc(sizeof(struct peak_pciec_card), GFP_KERNEL);
-   if (!card) {
-   dev_err(>dev,
-"failed allocating memory for i2c chip\n");
+   if (!card)
return -ENOMEM;
-   }
 
card->cfg_base = chan->cfg_base;
card->reg_base = priv->reg_base;
diff --git a/drivers/net/can/sja1000/peak_pcmcia.c 
b/drivers/net/can/sja1000/peak_pcmcia.c
index f117514..1a7020b 100644
--- a/drivers/net/can/sja1000/peak_pcmcia.c
+++ b/drivers/net/can/sja1000/peak_pcmcia.c
@@ -660,7 +660,6 @@ static int pcan_probe(struct pcmcia_device *pdev)
 
card = kzalloc(sizeof(struct pcan_pccard), GFP_KERNEL);
if (!card) {
-   dev_err(>dev, "couldn't allocate card memory\n");
err = -ENOMEM;
goto probe_err_2;
}
diff --git a/drivers/net/can/sja1000/plx_pci.c 
b/drivers/net/can/sja1000/plx_pci.c
index 11d1062..a042cdc 100644
--- a/drivers/net/can/sja1000/plx_pci.c
+++ b/drivers/net/can/sja1000/plx_pci.c
@@ -508,7 +508,6 @@ static int plx_pci_add_card(struct pci_dev *pdev,
/* Allocate card structures to hold addresses, ... */
card = kzalloc(sizeof(*card), GFP_KERNEL);
if (!card) {
-   dev_err(>dev, "Unable to allocate memory\n");
pci_disable_device(pdev);
return -ENOMEM;
}
diff --git a/drivers/net/can/usb/ems_usb.c b/drivers/net/can/usb/ems_usb.c
index c69f0b7..0e7bde7 100644
--- a/drivers/net/can/usb/ems_usb.c
+++ b/drivers/net/can/usb/ems_usb.c
@@ -1014,10 +1014,8 @@ static int ems_usb_probe(struct usb_interface *intf,
}
 
dev->intr_in_buffer = kzalloc(INTR_IN_BUFFER_SIZE, GFP_KERNEL);
-   if (!dev->intr_in_buffer) {
-   dev_err(>dev, "Couldn't alloc Intr buffer\n");
+   if (!dev->intr_in_buffer)
goto cleanup_intr_urb;
-   }
 
dev->tx_msg_buffer = kzalloc(CPC_HEADER_SIZE +
 sizeof(struct ems_cpc_msg), GFP_KERNEL);
diff --git a/drivers/net/can/usb/kvaser_usb.c b/drivers/net/can/usb/kvaser_usb.c
index 5b58a4d..45cb9f3 100644
--- a/drivers/net/can/usb/kvaser_usb.c
+++ b/drivers/net/can/usb/kvaser_usb.c
@@ -561,7 +561,6 @@ static int kvaser_usb_simple_msg_async(struct 
kvaser_usb_net_priv *priv,
 
buf = kmalloc(sizeof(struct kvaser_msg), GFP_ATOMIC);
if (!buf) {
-   netdev_err(netdev, "No memory left for USB buffer\n");
usb_free_urb(urb);
return -ENOMEM;
}
@@ -1268,7 +1267,6 @@ static netdev_tx_t kvaser_usb_start_xmit(struct sk_buff 
*skb,
 
buf = kmalloc(sizeof(struct kvaser_msg), GFP_ATOMIC);
if (!buf) {
-   netdev_err(netdev, "No memory left for USB buffer\n");
stats->tx_dropped++;
goto nobufmem;
}
diff --git a/drivers/net/can/usb/peak_usb/pcan_usb_core.c 
b/drivers/net/can/usb/peak_usb/pcan_usb_core.c
index d9290ea..a0f647f 100644
--- a/drivers/net/can/usb/peak_usb/pcan_usb_core.c
+++ b/drivers/net/can/usb/peak_usb/pcan_usb_core.c
@@ -386,7 +386,6 @@ static int peak_usb_start(struct peak_usb_device *dev)
 
buf = kmalloc(dev->adapter->rx_buffer_size, GFP_KERNEL);
if (!buf) {
-   netdev_err(netdev, "No memory left for USB buffer\n");

[PATCH 1/8] caif: Remove unnecessary alloc/OOM messages

[Joe Perches]

alloc failures already get standardized OOM
messages and a dump_stack.

Signed-off-by: Joe Perches 
---
 drivers/net/caif/caif_shmcore.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/net/caif/caif_shmcore.c b/drivers/net/caif/caif_shmcore.c
index bc497d7..bce8bac 100644
--- a/drivers/net/caif/caif_shmcore.c
+++ b/drivers/net/caif/caif_shmcore.c
@@ -633,9 +633,6 @@ int caif_shmcore_probe(struct shmdev_layer *pshm_dev)
kmalloc(sizeof(struct buf_list), GFP_KERNEL);
 
if (tx_buf == NULL) {
-   pr_warn("ERROR, Could not"
-   " allocate dynamic mem. for tx_buf,"
-   " Bailing out ...\n");
free_netdev(pshm_dev->pshm_netdev);
return -ENOMEM;
}
@@ -662,9 +659,6 @@ int caif_shmcore_probe(struct shmdev_layer *pshm_dev)
kmalloc(sizeof(struct buf_list), GFP_KERNEL);
 
if (rx_buf == NULL) {
-   pr_warn("ERROR, Could not"
-   " allocate dynamic mem.for rx_buf,"
-   " Bailing out ...\n");
free_netdev(pshm_dev->pshm_netdev);
return -ENOMEM;
}
-- 
1.8.0.dirty

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

[PATCH 0/8] drivers/net: Remove unnecessary alloc/OOM messages

[Joe Perches]

Remove all the OOM messages that follow kernel alloc
failures as there is already a generic equivalent to
these messages in the mm subsystem.

Joe Perches (8):
  caif: Remove unnecessary alloc/OOM messages
  can: Remove unnecessary alloc/OOM messages
  ethernet: Remove unnecessary alloc/OOM messages, alloc cleanups
  drivers: net: usb: Remove unnecessary alloc/OOM messages
  wan: Remove unnecessary alloc/OOM messages
  wimax: Remove unnecessary alloc/OOM messages, alloc cleanups
  wireless: Remove unnecessary alloc/OOM messages, alloc cleanups
  drivers:net:misc: Remove unnecessary alloc/OOM messages

 drivers/net/caif/caif_shmcore.c|  6 -
 drivers/net/can/sja1000/ems_pci.c  |  1 -
 drivers/net/can/sja1000/peak_pci.c |  5 +---
 drivers/net/can/sja1000/peak_pcmcia.c  |  1 -
 drivers/net/can/sja1000/plx_pci.c  |  1 -
 drivers/net/can/usb/ems_usb.c  |  4 +---
 drivers/net/can/usb/kvaser_usb.c   |  2 --
 drivers/net/can/usb/peak_usb/pcan_usb_core.c   |  5 
 drivers/net/can/usb/usb_8dev.c |  4 +---
 drivers/net/ethernet/atheros/atl1c/atl1c_main.c|  6 ++---
 drivers/net/ethernet/atheros/atl1e/atl1e_main.c|  2 --
 drivers/net/ethernet/broadcom/b44.c|  4 +---
 drivers/net/ethernet/broadcom/bcm63xx_enet.c   |  6 ++---
 drivers/net/ethernet/broadcom/cnic.c   |  6 ++---
 drivers/net/ethernet/broadcom/tg3.c|  4 +---
 drivers/net/ethernet/freescale/gianfar_ethtool.c   |  9 
 drivers/net/ethernet/ibm/ehea/ehea_main.c  |  4 +---
 drivers/net/ethernet/ibm/ehea/ehea_qmr.c   | 19 +--
 drivers/net/ethernet/ibm/emac/mal.c|  7 ++
 drivers/net/ethernet/ibm/ibmveth.c |  1 -
 drivers/net/ethernet/intel/igb/igb_main.c  |  5 ++--
 drivers/net/ethernet/intel/igbvf/netdev.c  |  8 +++
 drivers/net/ethernet/marvell/mv643xx_eth.c |  8 +++
 drivers/net/ethernet/marvell/mvmdio.c  |  1 -
 drivers/net/ethernet/marvell/skge.c|  5 ++--
 drivers/net/ethernet/marvell/sky2.c|  4 +---
 drivers/net/ethernet/mellanox/mlx4/en_main.c   |  4 +---
 drivers/net/ethernet/mellanox/mlx4/main.c  |  4 +---
 drivers/net/ethernet/myricom/myri10ge/myri10ge.c   |  5 ++--
 .../net/ethernet/qlogic/netxen/netxen_nic_ctx.c|  5 +---
 drivers/net/ethernet/qlogic/netxen/netxen_nic_hw.c | 18 ---
 .../net/ethernet/qlogic/netxen/netxen_nic_init.c   | 27 --
 .../net/ethernet/qlogic/netxen/netxen_nic_main.c   |  5 +---
 drivers/net/ethernet/qlogic/qla3xxx.c  | 10 
 .../net/ethernet/qlogic/qlcnic/qlcnic_83xx_init.c  | 14 ---
 drivers/net/ethernet/qlogic/qlcnic/qlcnic_hw.c |  6 ++---
 drivers/net/ethernet/qlogic/qlcnic/qlcnic_init.c   | 26 +++--
 drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c   | 19 +--
 .../net/ethernet/qlogic/qlcnic/qlcnic_minidump.c   |  7 ++
 drivers/net/ethernet/qlogic/qlge/qlge_main.c   |  1 -
 drivers/net/ethernet/rdc/r6040.c   |  3 +--
 drivers/net/ethernet/renesas/sh_eth.c  | 10 
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c  | 11 +
 drivers/net/ethernet/sun/niu.c |  2 +-
 drivers/net/ethernet/ti/cpsw.c |  8 +++
 drivers/net/ethernet/ti/davinci_mdio.c |  4 +---
 drivers/net/ethernet/xilinx/ll_temac_main.c|  6 ++---
 drivers/net/hamradio/dmascc.c  |  7 +-
 drivers/net/phy/spi_ks8995.c   |  4 +---
 drivers/net/usb/ax88172a.c |  6 ++---
 drivers/net/usb/hso.c  | 25 ++--
 drivers/net/usb/sierra_net.c   | 10 +++-
 drivers/net/usb/smsc75xx.c |  6 ++---
 drivers/net/usb/smsc95xx.c |  6 ++---
 drivers/net/usb/usbnet.c   |  5 +---
 drivers/net/virtio_net.c   |  4 +---
 drivers/net/wan/cosa.c |  9 
 drivers/net/wan/farsync.c  |  6 ++---
 drivers/net/wan/hdlc.c |  9 
 drivers/net/wan/x25_asy.c  |  1 -
 drivers/net/wimax/i2400m/rx.c  | 16 -
 drivers/net/wimax/i2400m/usb-notif.c   |  1 -
 drivers/net/wireless/airo_cs.c |  5 ++--
 drivers/net/wireless/at76c50x-usb.c|  4 +---
 .../net/wireless/ath/ath9k/dfs_pattern_detector.c  |  6 ++---
 drivers/net/wireless/atmel_cs.c|  5 ++--
 drivers/net/wireless/ipw2x00/ipw2100.c |  9 +++-
 drivers/net/wireless/libertas/cfg.c|  4 +---
 drivers/net/wireless/mwifiex/11n.c