I/O blocked while dirty pages are being flushed

[Fredrik Tolf]

Dear list,

I've got an mmapped file (a Berkeley DB region file) with an access 
pattern such that it gets some 10-40 MBs of dirtied pages a couple of 
times per minute. When the VM comes around to flush these pages to disk, 
that causes loads of problems. Since the dirty pages are rather 
interspersed in the file, the flusher posts batches of some 3000-5000 
write requests to the disk queue, and since I'm using normal hard drives, 
this might sometimes take 10-30 seconds to complete.


While this flush is running, I find that many a process goes into disk 
sleep waiting for the flush to complete. This includes the process 
manipulating the mmapped file whenever it tries to redirty a page 
currently waiting to be flushed, but also, for instance, programs that 
write() to log files (since, I guess, the buffer page backing the last 
written portion of the log file is being flushed). The common culprits, 
then, are sleep_on_page and sleep_on_buffer. All these processes commonly 
block for up to several tens of seconds, then, which gets me all kind of 
trouble, as I'm sure you can see.


I'd like to hear your opinion on this case. Is Berkeley DB at fault for 
causing these kinds of access patterns? Is the kernel at fault for 
blocking all these processes needlessly? Is the hardware at fault for 
being so hopelessly slow and I should get with the times and get me some 
SSDs? Or am I at fault for not finding the obvious configuration settings 
to avoid the problem? :)


I'm inclined to think that the kernel is at fault for blocking the 
processes needlessly. If the contents of the pages being flushed need to 
be preserved until the write is completed, shouldn't they be copied when 
written to, rather than blocking the writer for who-knows-how-long? It 
seems that if the kernel doesn't do this, then I'm always put at the mercy 
of the hardware, and as long as I have free memory, I shouldn't have to 
be.


However, I could also see that Berkeley DB is somehow at fault for this 
kind of access, causing such massive disk writes, and that perhaps it 
should be using SysV SHM regions or such instead of disk-backed files? 
Would it be possible, perhaps, to get these files treated more like 
anonymous memory, their contents not being flushed back to disk unless 
necessary?


It is worth noting, also, that this seems to be a situation introduced 
somewhere between 2.6.26 and 2.6.32, because I started noticing it when I 
upgraded from Debian 5.0 to 6.0. I've since tried it on 3.2.0, 3.5.4 and 
3.7.1, and it appears in every version. However, I can't easily go back 
and bisect, because the new init scripts don't support kernels older than 
2.6.32, unfortunately.


I'm sorry, also, if this is the completely wrong list for such 
discussions, but I couldn't find another one to match better.


Thanks for reading my wall of text!

--

Fredrik Tolf
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] x86 fixes for 3.9-rc4

[H. Peter Anvin]

Hi Linus,

A collection of minor fixes, more EFI variables paranoia
(anti-bricking) plus the ability to disable the pstore either as a
runtime default or completely, due to bricking concerns.

The following changes since commit a937536b868b8369b98967929045f1df54234323:

  Linux 3.9-rc3 (2013-03-17 15:59:32 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/urgent

for you to fetch changes up to b9726d9df8263fe756d2293ff01906f41f7d2776:

  Merge tag 'efi-for-3.9-rc4' into x86/urgent (2013-03-23 21:49:51 -0700)



Ben Hutchings (1):
  efivars: Fix check for CONFIG_EFI_VARS_PSTORE_DEFAULT_DISABLE

CQ Tang (1):
  x86-64: Fix the failure case in copy_user_handle_tail()

Fenghua Yu (1):
  x86-32, microcode_intel_early: Fix crash with CONFIG_DEBUG_VIRTUAL

H. Peter Anvin (3):
  x86, microcode_intel_early: Mark apply_microcode_early() as cpuinit
  Merge tag 'efi-for-3.9-rc3' into x86/urgent
  Merge tag 'efi-for-3.9-rc4' into x86/urgent

Matt Fleming (2):
  efivars: explicitly calculate length of VariableName
  efivars: Handle duplicate names from get_next_variable()

Seth Forshee (2):
  efivars: Allow disabling use as a pstore backend
  efivars: Add module parameter to disable use as a pstore backend

 arch/x86/kernel/microcode_intel_early.c |  30 +++
 arch/x86/lib/usercopy_64.c  |   4 +-
 drivers/firmware/Kconfig|  18 
 drivers/firmware/efivars.c  | 150 ++--
 4 files changed, 139 insertions(+), 63 deletions(-)

diff --git a/arch/x86/kernel/microcode_intel_early.c 
b/arch/x86/kernel/microcode_intel_early.c
index 7890bc8..d893e8e 100644
--- a/arch/x86/kernel/microcode_intel_early.c
+++ b/arch/x86/kernel/microcode_intel_early.c
@@ -90,13 +90,13 @@ microcode_phys(struct microcode_intel **mc_saved_tmp,
struct microcode_intel ***mc_saved;
 
mc_saved = (struct microcode_intel ***)
-  __pa_symbol(_saved_data->mc_saved);
+  __pa_nodebug(_saved_data->mc_saved);
for (i = 0; i < mc_saved_data->mc_saved_count; i++) {
struct microcode_intel *p;
 
p = *(struct microcode_intel **)
-   __pa(mc_saved_data->mc_saved + i);
-   mc_saved_tmp[i] = (struct microcode_intel *)__pa(p);
+   __pa_nodebug(mc_saved_data->mc_saved + i);
+   mc_saved_tmp[i] = (struct microcode_intel *)__pa_nodebug(p);
}
 }
 #endif
@@ -562,7 +562,7 @@ scan_microcode(unsigned long start, unsigned long end,
struct cpio_data cd;
long offset = 0;
 #ifdef CONFIG_X86_32
-   char *p = (char *)__pa_symbol(ucode_name);
+   char *p = (char *)__pa_nodebug(ucode_name);
 #else
char *p = ucode_name;
 #endif
@@ -630,8 +630,8 @@ static void __cpuinit print_ucode(struct ucode_cpu_info 
*uci)
if (mc_intel == NULL)
return;
 
-   delay_ucode_info_p = (int *)__pa_symbol(_ucode_info);
-   current_mc_date_p = (int *)__pa_symbol(_mc_date);
+   delay_ucode_info_p = (int *)__pa_nodebug(_ucode_info);
+   current_mc_date_p = (int *)__pa_nodebug(_mc_date);
 
*delay_ucode_info_p = 1;
*current_mc_date_p = mc_intel->hdr.date;
@@ -659,8 +659,8 @@ static inline void __cpuinit print_ucode(struct 
ucode_cpu_info *uci)
 }
 #endif
 
-static int apply_microcode_early(struct mc_saved_data *mc_saved_data,
-struct ucode_cpu_info *uci)
+static int __cpuinit apply_microcode_early(struct mc_saved_data *mc_saved_data,
+  struct ucode_cpu_info *uci)
 {
struct microcode_intel *mc_intel;
unsigned int val[2];
@@ -741,15 +741,15 @@ load_ucode_intel_bsp(void)
 #ifdef CONFIG_X86_32
struct boot_params *boot_params_p;
 
-   boot_params_p = (struct boot_params *)__pa_symbol(_params);
+   boot_params_p = (struct boot_params *)__pa_nodebug(_params);
ramdisk_image = boot_params_p->hdr.ramdisk_image;
ramdisk_size  = boot_params_p->hdr.ramdisk_size;
initrd_start_early = ramdisk_image;
initrd_end_early = initrd_start_early + ramdisk_size;
 
_load_ucode_intel_bsp(
-   (struct mc_saved_data *)__pa_symbol(_saved_data),
-   (unsigned long *)__pa_symbol(_saved_in_initrd),
+   (struct mc_saved_data *)__pa_nodebug(_saved_data),
+   (unsigned long *)__pa_nodebug(_saved_in_initrd),
initrd_start_early, initrd_end_early, );
 #else
ramdisk_image = boot_params.hdr.ramdisk_image;
@@ -772,10 +772,10 @@ void __cpuinit load_ucode_intel_ap(void)
unsigned long *initrd_start_p;
 
mc_saved_in_initrd_p =
-   (unsigned long *)__pa_symbol(mc_saved_in_initrd);
-   mc_saved_data_p = (struct mc_saved_data 

mfd: Core driver for Winbond chips

[Guenter Roeck]

MFD core driver for various variants of Winbond/Nuvoton SuperIO chips.

Signed-off-by: Guenter Roeck 
---
 drivers/mfd/Kconfig  |   22 +++
 drivers/mfd/Makefile |1 +
 drivers/mfd/w83627hf-core.c  |  324 ++
 include/linux/mfd/w83627hf.h |  131 +
 4 files changed, 478 insertions(+)
 create mode 100644 drivers/mfd/w83627hf-core.c
 create mode 100644 include/linux/mfd/w83627hf.h

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index c346941..a141ef6 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1119,6 +1119,28 @@ config MFD_AS3711
help
  Support for the AS3711 PMIC from AMS
 
+config MFD_W83627HF
+   tristate "Winbond W83627HF and compatibles"
+   select MFD_CORE
+   help
+ If you say yes here you add support for the Winbond W836X7 and Nuvoton
+ NCT677X series of super-IO chips. The following chips are supported:
+   W83627F/HF/G/HG/DHG/DHG-P/EHF/EHG/S/SF/THF/UHG/UG
+   W83637HF
+   W83667HG/HG-B
+   W83687THF
+   W83697HF
+   NCT6775
+   NCT6776
+   NCT6779
+
+ This is a multi functional device and this support defines a new
+ platform device only. See other configuration submenus in order to
+ enable the drivers of Winbond chip's functionalities.
+
+ This driver can also be built as a module.  If so, the module
+ will be called w83627hf-core.
+
 endmenu
 endif
 
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index b90409c..3e9e830 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -77,6 +77,7 @@ obj-$(CONFIG_MFD_MC13XXX_I2C) += mc13xxx-i2c.o
 obj-$(CONFIG_MFD_CORE) += mfd-core.o
 
 obj-$(CONFIG_EZX_PCAP) += ezx-pcap.o
+obj-$(CONFIG_MFD_W83627HF) += w83627hf-core.o
 
 obj-$(CONFIG_MCP)  += mcp-core.o
 obj-$(CONFIG_MCP_SA11X0)   += mcp-sa11x0.o
diff --git a/drivers/mfd/w83627hf-core.c b/drivers/mfd/w83627hf-core.c
new file mode 100644
index 000..d0be5b9
--- /dev/null
+++ b/drivers/mfd/w83627hf-core.c
@@ -0,0 +1,324 @@
+/*
+ *  w83627hf.c - platform device support
+ *
+ *  Copyright (c) 2013 Guenter Roeck 
+ *
+ *  Based on earlier work by Rodolfo Giometti
+ *
+ *  Copyright (c) 2009-2011 Rodolfo Giometti 
+ *
+ *  Based on drivers/hwmon/w83627hf.c
+ *
+ *  Original copyright note:
+ *Copyright (c) 1998 - 2003  Frodo Looijaard ,
+ *Philip Edelbrock ,
+ *and Mark Studebaker 
+ *Ported to 2.6 by Bernhard C. Schrenk 
+ *Copyright (c) 2007  Jean Delvare 
+ *
+ *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., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static unsigned short force_id;
+module_param(force_id, ushort, 0);
+MODULE_PARM_DESC(force_id, "Override the detected device ID");
+
+/*
+ * Devices definitions
+ */
+
+static struct platform_device *pdev;
+
+struct w83627hf_chip_data {
+   const char * const name;
+   const char * const chip;
+   const char * const hwmon_drvname;
+};
+
+static const struct w83627hf_chip_data w83627hf_chip_data[] = {
+   [w83627hf] = {
+   .name = __stringify(w83627hf),
+   .chip = "W83627HF",
+   .hwmon_drvname = W83627HF_HWMON_DRVNAME,
+   },
+   [w83627s] = {
+   .name = __stringify(w83627s),
+   .chip = "W83627S",
+   },
+   [w83627thf] = {
+   .name = __stringify(w83627thf),
+   .chip = "W83627THF",
+   .hwmon_drvname = W83627HF_HWMON_DRVNAME,
+   },
+   [w83697hf] = {
+   .name = __stringify(w83697hf),
+   .chip = "W83697HF",
+   .hwmon_drvname = W83627HF_HWMON_DRVNAME,
+   },
+   [w83697ug] = {
+   .name = __stringify(w83697ug),
+   .chip = "W83697SF/UG",
+   },
+   [w83637hf] = {
+   .name = __stringify(w83637hf),
+   .chip = "W83637HF",
+   .hwmon_drvname = W83627HF_HWMON_DRVNAME,
+   },
+   [w83687thf] = {
+   .name = __stringify(w83687thf),
+ 

Re: [BUG] bisected: PandaBoard smsc95xx ethernet driver error from USB timeout

[Ming Lei]

On Fri, Mar 22, 2013 at 4:28 AM, Frank Rowand  wrote:
>> I play upstream kernel on Pandaboard A1 frequently, looks not
>> see the failure problem before. Maybe the problem is config dependent.
>>
>> If you may share your config file, I'd like to do the test too.

3.9-rc2-20130314 doesn't have the problem observed on my Pandaboard A1,
but I only tested booting from MMC, not from NFS.


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

Linux 3.9-rc4

[Linus Torvalds]

Another week, another -rc. And things haven't calmed down, meaning
that the nice small and calm -rc2 was definitely the outlier so far.
But I'm optimistic, dammit, and I'm going to keep hoping that things
will change, and the upcoming week will be boring and devoid of any
real work what-so-ever.

It had better be, because it's spring break and the kids are around.

Anyway.

While it hasn't been as calm as I'd like things to be, it's not like
things have been hugely exciting either.  Most of this really is
pretty trivial. It's all over, with the bulk in drivers (drm, md, net,
mtd, usb, sound), but also some arch updates (powerpc, arm, sparc,
x86) and filesystem work (cifs, ext4).

Go out and test,

  Linus

---
Aaron Lu (1):
  [libata] Avoid specialized TLA's in ZPODD's Kconfig

Alan Stern (4):
  USB: EHCI: fix regression during bus resume
  usb: gadget: udc-core: fix a regression during gadget driver unbinding
  USB: gadget: net2280: remove leftover driver->unbind call in error pathway
  USB: EHCI: fix regression in QH unlinking

Alex Deucher (6):
  drm/radeon: fix S/R on VM systems (cayman/TN/SI)
  drm/radeon: fix backend map setup on 1 RB trinity boards
  drm/radeon/benchmark: make sure bo blit copy exists before using it
  drm/radeon/benchmark: allow same domains for dma copy
  drm/radeon: add support for Richland APUs
  drm/radeon: add Richland pci ids

Alexander Duyck (2):
  dma-debug: fix locking bug in check_unmap()
  dma-debug: update DMA debug API to better handle multiple
mappings of a buffer

Alexey Khoroshilov (1):
  usb: cdc-acm: fix error handling in acm_probe()

Allen Pais (1):
  sparc64: correctly recognize SPARC64-X chips

Ananth N Mavinakayanahalli (1):
  perf probe: Fix segfault

Andreas Schwab (1):
  arm64: fix padding computation in struct ucontext

Andrew Brownfield (1):
  ata_piix: Add MODULE_PARM_DESC to prefer_ms_hyperv

Andrzej Pietrasiewicz (1):
  usb: gadget: ffs: fix enable multiple instances

Andy Grover (1):
  target/iscsi: Fix mutual CHAP auth on big-endian arches

Andy Honig (3):
  KVM: x86: fix for buffer overflow in handling of
MSR_KVM_SYSTEM_TIME (CVE-2013-1796)
  KVM: x86: Convert MSR_KVM_SYSTEM_TIME to use gfn_to_hva_cache
functions (CVE-2013-1797)
  KVM: Fix bounds checking in ioapic indirect register reads (CVE-2013-1798)

Aneesh Kumar K.V (3):
  powerpc: Make VSID_BITS* dependency explicit
  powerpc: Update kernel VSID range
  powerpc: Rename USER_ESID_BITS* to ESID_BITS*

Anton Blanchard (1):
  powerpc: Fix -mcmodel=medium breakage in prom_init.c

Arnd Bergmann (7):
  clk: vt8500: Fix "fix device clock divisor calculations"
  [media] s5p-fimc: fix s5pv210 build
  input/joystick: use get_cycles on ARM
  vfio: include  for kmalloc
  isdn: hisax: netjet requires VIRT_TO_BUS
  ethernet/tulip: DE4x5 needs VIRT_TO_BUS
  ARM: fix CONFIG_VIRT_TO_BUS handling

Ashish Jangam (1):
  drivers/rtc/rtc-da9052.c: fix for rtc device registration

Asias He (3):
  tcm_vhost: Add missed lock in vhost_scsi_clear_endpoint()
  tcm_vhost: Flush vhost_work in vhost_scsi_flush()
  target/pscsi: Reject cross page boundary case in pscsi_map_sg

Ben Collins (1):
  sgy-cts1000: Remove __dev* attributes

Ben Hutchings (1):
  sfc: Only use TX push if a single descriptor is to be written

Ben Skeggs (2):
  drm/nouveau/core: fix return value of nouveau_object_del()
  drm/nv50/kms: prevent lockdep false-positive in page flipping path

Benjamin Herrenschmidt (2):
  powerpc: Fix STAB initialization
  powerpc: Fix cputable entry for 970MP rev 1.0

Bing Zhao (1):
  mwifiex: fix potential out-of-boundary access to ibss rate table

Bjørn Mork (2):
  net: qmi_wwan: set correct altsetting for Gobi 1K devices
  net: cdc_ncm, cdc_mbim: allow user to prefer NCM for backwards
compatibility

Bo Shen (1):
  usb: gadget: u_serial: fix typo which cause build warning

Brian Foster (1):
  xfs: fix potential infinite loop in xfs_iomap_prealloc_size()

Brian Norris (1):
  mtd: nand: reintroduce NAND_NO_READRDY as NAND_NEED_READRDY

Catalin Marinas (2):
  arm64: Removed unused variable in compat_setup_rt_frame()
  arm64: Fix build error with !SMP

Chen Gang (1):
  ARM:net: an issue for k which is u32, never < 0

Cong Wang (2):
  openvswitch: fix the calculation of checksum for vlan header
  openvswitch: remove some useless comments

Dan Carpenter (1):
  selinux: use GFP_ATOMIC under spin_lock

Daniel Hellstrom (1):
  sparc,leon: fix GRPCI2 device0 PCI config space access

Daniel Mack (3):
  net: ethernet: cpsw: fix usage of cpdma_check_free_tx_desc()
  ALSA: snd-usb: mixer: propagate errors up the call chain
  ALSA: snd-usb: mixer: ignore -EINVAL in snd_usb_mixer_controls()

Daniel Vetter (1):
  MAINTAINERS: intel-gfx is no longer subscribers-only

Dave Chinner 

Re: [PATCH] Fix IXP4xx coherent allocations

[David Miller]

From: Krzysztof Halasa 
Date: Sat, 23 Mar 2013 20:35:46 +0100

> ARM core code currently requires coherent DMA mask to be set. Make sure
> we limit PCI devices to 64 MiB while allowing on-chip devices to access
> the whole 4 GiB address space.
> 
> This fixes a v3.7+ regression which broke IXP4xx built-in network devices.
> 
> Signed-off-by: Krzysztof Hałasa 

This requirement is not reasonable.

The DMA API documentation clearly states what the default must be,
and what drivers are guarenteed will be the default.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] bnx2x: fix assignment of signed expression to unsigned variable

[David Miller]

From: Kumar Amit Mehta 
Date: Sat, 23 Mar 2013 11:52:55 -0700

> fix for incorrect assignment of signed expression to unsigned variable.
> 
> Signed-off-by: Kumar Amit Mehta 

Returning positive error codes is just as broken as what is there
currently.

These routines should return 0 or 1, the return value isn't even used
in any way, it is just tested against zero.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] target fixes for v3.9-rc4

[Nicholas A. Bellinger]

Hi Linus!

Here is the current set of target-pending/master fixes for v3.9-rc4.

Please go ahead and pull from:

  git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git master

These are mostly minor fixes this time around.  The iscsi-target CHAP
big-endian bugfix and bump FD_MAX_SECTORS=2048 default patch to allow
1MB sized I/Os for FILEIO backends on >= v3.5 code are both CC'ed to
stable.

Also, there is a persistent reservations regression that has recently
been reported for >= v3.8.x code, that is currently being tracked down
for v3.9.

Thank you,

--nab

Andy Grover (1):
  target/iscsi: Fix mutual CHAP auth on big-endian arches

Asias He (3):
  tcm_vhost: Add missed lock in vhost_scsi_clear_endpoint()
  tcm_vhost: Flush vhost_work in vhost_scsi_flush()
  target/pscsi: Reject cross page boundary case in pscsi_map_sg

Hannes Reinecke (1):
  target_core_sbc: use noop for SYNCHRONIZE_CACHE

Nicholas Bellinger (1):
  target/file: Bump FD_MAX_SECTORS to 2048 to handle 1M sized I/Os

Wei Yongjun (1):
  target: fix possible memory leak in core_tpg_register()

 drivers/target/iscsi/iscsi_target_auth.c |5 -
 drivers/target/target_core_file.h|2 +-
 drivers/target/target_core_pscsi.c   |   11 ---
 drivers/target/target_core_sbc.c |7 +--
 drivers/target/target_core_tpg.c |3 ++-
 drivers/vhost/tcm_vhost.c|   13 +
 6 files changed, 29 insertions(+), 12 deletions(-)

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

[PATCH] ACPI / PM: Fix potential problem in acpi_device_get_power()

[Rafael J. Wysocki]

From: Rafael J. Wysocki 

Theoretically, in some situations acpi_device_get_power() may return
an incorrect result, because the settings of the power resources
depended on by the device may indicate a power state shallower than
the actual power state of the device.

Say that two devices, A and B, depend on two power resources, X and
Y, in such a way that _PR0 for both A and B list both X and Y and
_PR3 for both A and B list power resource Y alone.  Also suppose
that _PS0 and _PS3 are present for both A and B.  Then, if devices
A and B are initially in D0, power resources X and Y are initially
"on" and their reference counters are equal to 2.  To put device A
into power state D3hot the kernel will decrement the reference
counter of power resource X, but that power resource won't be turned
off, because it is still in use by device B (its reference counter is
equal to 1).  Next, _PS3 will be executed for device A.  Afterward
the configuration of the power resources will indicate that device
A is in power state D0 (both X and Y are "on"), but in fact it is
in D3hot (because _PS3 has been executed for it).

In that situation, if acpi_device_get_power() is called to get the
power state of device A, it will first execute _PSC for it which
should return 3.  That will cause acpi_device_get_power() to run
acpi_power_get_inferred_state() for device A and the resultant power
state will be D0, which is incorrect.

To fix that change acpi_device_get_power() to first execute
acpi_power_get_inferred_state() for the given device (if it
depends on power resources) and to evaluate _PSC for it subsequently,
so that the result inferred from the power resources configuration
can be amended by the _PSC return value.

Signed-off-by: Rafael J. Wysocki 
---
 drivers/acpi/device_pm.c |   39 ---
 1 file changed, 24 insertions(+), 15 deletions(-)

Index: linux-pm/drivers/acpi/device_pm.c
===
--- linux-pm.orig/drivers/acpi/device_pm.c
+++ linux-pm/drivers/acpi/device_pm.c
@@ -145,27 +145,36 @@ int acpi_device_get_power(struct acpi_de
}
 
/*
-* Get the device's power state either directly (via _PSC) or
-* indirectly (via power resources).
+* Get the device's power state from power resources settings and _PSC,
+* if available.
 */
+   if (device->power.flags.power_resources) {
+   int error = acpi_power_get_inferred_state(device, );
+   if (error)
+   return error;
+   }
if (device->power.flags.explicit_get) {
+   acpi_handle handle = device->handle;
unsigned long long psc;
-   acpi_status status = acpi_evaluate_integer(device->handle,
-  "_PSC", NULL, );
+   acpi_status status;
+
+   status = acpi_evaluate_integer(handle, "_PSC", NULL, );
if (ACPI_FAILURE(status))
return -ENODEV;
 
-   result = psc;
-   }
-   /* The test below covers ACPI_STATE_UNKNOWN too. */
-   if (result <= ACPI_STATE_D2) {
- ; /* Do nothing. */
-   } else if (device->power.flags.power_resources) {
-   int error = acpi_power_get_inferred_state(device, );
-   if (error)
-   return error;
-   } else if (result == ACPI_STATE_D3_HOT) {
-   result = ACPI_STATE_D3;
+   /*
+* The power resources settings may indicate a power state
+* shallower than the actual power state of the device.
+*
+* Moreover, on systems predating ACPI 4.0, if the device
+* doesn't depend on any power resources and _PSC returns 3,
+* that means "power off".  We need to maintain compatibility
+* with those systems.
+*/
+   if (psc > result && psc < ACPI_STATE_D3_COLD)
+   result = psc;
+   else if (result == ACPI_STATE_UNKNOWN)
+   result = psc > ACPI_STATE_D2 ? ACPI_STATE_D3_COLD : psc;
}
 
/*

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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.9-rc3+: reports battery as 0 mWh capacity on thinkpad x60

[Rafael J. Wysocki]

On Saturday, March 23, 2013 09:21:56 PM Pavel Machek wrote:
> On Sat 2013-03-23 14:00:23, Bjørn Mork wrote:
> > "Rafael J. Wysocki"  writes:
> > > On Saturday, March 23, 2013 12:40:12 PM Pavel Machek wrote:
> > >> Hi!
> > >> 
> > >> pavel@amd:~$ cat /proc/acpi/battery/BAT0/info 
> > >> present: yes
> > >> design capacity: 0 mWh
> > >> last full capacity:  0 mWh
> > >> battery technology:  rechargeable
> > >> design voltage:  14400 mV
> > >> 
> > >> This worked before... at least it works in 2.6 kernel used by debian.
> > >
> > > This works for me in 3.9-rc3.  May I see your .config?
> > 
> > Well, if this works, then maybe the Kconfig help text should be updated:
> > 
> > config ACPI_PROCFS_POWER
> > bool "Deprecated power /proc/acpi directories"
> > depends on PROC_FS
> > help
> >   For backwards compatibility, this option allows
> >   deprecated power /proc/acpi/ directories to exist, even when
> >   they have been replaced by functions in /sys.
> >   The deprecated directories (and their replacements) include:
> >   /proc/acpi/battery/* (/sys/class/power_supply/*)
> >   /proc/acpi/ac_adapter/* (sys/class/power_supply/*)
> >   This option has no effect on /proc/acpi/ directories
> >   and functions, which do not yet exist in /sys
> >   This option, together with the proc directories, will be
> >   deleted in 2.6.39.
> > 
> > 
> > Time to call the bluff now :)
> 
> This should probably be "default y", BTW.
> 
> But problem is not in /proc, /sys has zeros, too.
> 
> pavel@amd:~$ cat /sys/class/power_supply/BAT0/energy_full
> 0
> pavel@amd:~$ cat /sys/class/power_supply/BAT0/energy_full_design 
> 0
> pavel@amd:~$ cat /sys/class/power_supply/BAT0/model_name 
> 93P5030
> pavel@amd:~$

Can you narrow the time frame when it stopped working a bit?

Rafael


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

Re: pm/linux-next cause network stop working with qemu-kvm/e1000

[Rafael J. Wysocki]

On Saturday, March 23, 2013 09:18:55 AM Yinghai Lu wrote:
> On Sat, Mar 23, 2013 at 5:30 AM, Rafael J. Wysocki  wrote:
> 
> >>
> >> Attached patch fix the problem. Please fold it into offending patch in
> >> pm/linux-next.
> >
> > I'd actually prefer to apply it as a separate patch, so can you please post
> > it with a proper changelog?
> 
> but that will break bisecting, right?

We need to keep ACPICA changes and Linux-specific modifications separate
for process-related reasons.

Thanks,
Rafael


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

snd-hda-intel problem

[Donn Washburn]

Please forward -  I am not on your email list so please CC any email to
"alsa-info.sh"

I am running openSuSE 12.3, KDE4,  alsa, pulseaudio, kernel 3.9-rc3 and 
flash (very current version)
The sound works except the volume on pavumixer  which goes up and down. 
and some times not at all.

It is a snd-hda-intel driver   Some time it even come up at full volume

Also please replace "pavumixer" with "pavucontrol above and add hwinfo 
--sound" which see the second device first and the on MB device as 2


--
73 de Donn Washburn
1803 Oaklawn  Email 
Sugar Land, TX 77498-2249  LL# 1.281.242.4807
Ham Callsign N5XWB   HAMs : 
VoIP via Skype:n5xwbg  BMWMOA #:4146 Ambassador
  " http://counter.li.org " #279316

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

mfd: Core driver for W836{2389}7[T]HF

[Guenter Roeck]

MFD core driver for various variants of Winbond/Nuvoton SuperIO chips.

Signed-off-by: Guenter Roeck 
---

My variant of an MFD core driver for Winbond chips.

Key differences to Wim's driver
- Uses mfd infrastructure
- Passes enum instead of raw device id to client drivers
- Uses request_muxed_region instead of an in-module function for
  superio_enter
  [ Using an in-module function and in-module locking may be better ]

TODO:
- Detect and instantiate superio chips on both addresses, not just one.
- Replace static variables 'pdev' and mfd_cells[].

 drivers/mfd/Kconfig  |   22 +++
 drivers/mfd/Makefile |1 +
 drivers/mfd/w83627hf-core.c  |  324 ++
 include/linux/mfd/w83627hf.h |  131 +
 4 files changed, 478 insertions(+)
 create mode 100644 drivers/mfd/w83627hf-core.c
 create mode 100644 include/linux/mfd/w83627hf.h

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index c346941..a141ef6 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1119,6 +1119,28 @@ config MFD_AS3711
help
  Support for the AS3711 PMIC from AMS
 
+config MFD_W83627HF
+   tristate "Winbond W83627HF and compatibles"
+   select MFD_CORE
+   help
+ If you say yes here you add support for the Winbond W836X7 and Nuvoton
+ NCT677X series of super-IO chips. The following chips are supported:
+   W83627F/HF/G/HG/DHG/DHG-P/EHF/EHG/S/SF/THF/UHG/UG
+   W83637HF
+   W83667HG/HG-B
+   W83687THF
+   W83697HF
+   NCT6775
+   NCT6776
+   NCT6779
+
+ This is a multi functional device and this support defines a new
+ platform device only. See other configuration submenus in order to
+ enable the drivers of Winbond chip's functionalities.
+
+ This driver can also be built as a module.  If so, the module
+ will be called w83627hf-core.
+
 endmenu
 endif
 
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index b90409c..3e9e830 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -77,6 +77,7 @@ obj-$(CONFIG_MFD_MC13XXX_I2C) += mc13xxx-i2c.o
 obj-$(CONFIG_MFD_CORE) += mfd-core.o
 
 obj-$(CONFIG_EZX_PCAP) += ezx-pcap.o
+obj-$(CONFIG_MFD_W83627HF) += w83627hf-core.o
 
 obj-$(CONFIG_MCP)  += mcp-core.o
 obj-$(CONFIG_MCP_SA11X0)   += mcp-sa11x0.o
diff --git a/drivers/mfd/w83627hf-core.c b/drivers/mfd/w83627hf-core.c
new file mode 100644
index 000..d0be5b9
--- /dev/null
+++ b/drivers/mfd/w83627hf-core.c
@@ -0,0 +1,324 @@
+/*
+ *  w83627hf.c - platform device support
+ *
+ *  Copyright (c) 2013 Guenter Roeck 
+ *
+ *  Based on earlier work by Rodolfo Giometti
+ *
+ *  Copyright (c) 2009-2011 Rodolfo Giometti 
+ *
+ *  Based on drivers/hwmon/w83627hf.c
+ *
+ *  Original copyright note:
+ *Copyright (c) 1998 - 2003  Frodo Looijaard ,
+ *Philip Edelbrock ,
+ *and Mark Studebaker 
+ *Ported to 2.6 by Bernhard C. Schrenk 
+ *Copyright (c) 2007  Jean Delvare 
+ *
+ *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., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static unsigned short force_id;
+module_param(force_id, ushort, 0);
+MODULE_PARM_DESC(force_id, "Override the detected device ID");
+
+/*
+ * Devices definitions
+ */
+
+static struct platform_device *pdev;
+
+struct w83627hf_chip_data {
+   const char * const name;
+   const char * const chip;
+   const char * const hwmon_drvname;
+};
+
+static const struct w83627hf_chip_data w83627hf_chip_data[] = {
+   [w83627hf] = {
+   .name = __stringify(w83627hf),
+   .chip = "W83627HF",
+   .hwmon_drvname = W83627HF_HWMON_DRVNAME,
+   },
+   [w83627s] = {
+   .name = __stringify(w83627s),
+   .chip = "W83627S",
+   },
+   [w83627thf] = {
+   .name = __stringify(w83627thf),
+   .chip = "W83627THF",
+   .hwmon_drvname = W83627HF_HWMON_DRVNAME,
+   },
+   [w83697hf] = {
+   .name = __stringify(w83697hf),
+   .chip = 

Re: [GIT PULL] (xen) stable/for-linus-3.9-rc3-tag

[konrad wilk]

> David Vrabel (1): xen/events: avoid race with raising an event in 
unmask_evtchn()

Unless I am looking in the wrong place, this patch is still the same one
that breaks PV on HVM and Xen ARM guests, see:

http://marc.info/?l=xen-devel=136377731913034

David is aware of the issue and I think is working on an alternative
fix.


Thank you for noticing that. Linus does not look to have pulled it - so 
we still have some time

to fix this right.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: remap kernel static memory to user space

[Eduardo Cruz]

Man, it worked!
You saved my life kkk.
Thank you very much!

2013/3/23 Hugh Dickins :
> On Wed, 20 Mar 2013, Eduardo Cruz wrote:
>
>> Hello.
>>
>> I'm trying to remap some kernel static memory to user space using
>> remap_pfn_range.
>> For that, I wrote a module that initializes a device, which later I
>> use mknod, etc.
>>
>> When I allocate the memory with kmalloc, everything works:   (where
>> user_space_shared was allocated with kmalloc)
>>
>> if ((ret = remap_pfn_range(vma, vma->vm_start,
>> virt_to_phys(user_space_shared) >> PAGE_SHIFT, length,
>> vma->vm_page_prot)) < 0)
>
> I have no ia64 experience, but my guess is that your problem is with
> that virt_to_phys(user_space_shared).
>
> virt_to_phys() expects to be given an address from the kernel's direct
> map of physical memory; whereas if you declare user_space_shared[] in
> kernel static memory, I believe ia64 places that in a different region.
>
> Try changing that to virt_to_phys(ia64_imva(user_space_shared))
> and I expect it will then work: see comment above ia64_imva()
> in arch/ia64/include/asm/processor.h.
>
> Hugh
>
>>
>> In the application in user space:
>> kstc = mmap(0, sizeof(user_space_shared_t), PROT_READ|PROT_WRITE,
>> MAP_SHARED| MAP_LOCKED, fd, 0);
>>
>> With user_space_shared allocated using kmalloc, it is working.
>> The application is able to read the data I wrote in the kernel module.
>>
>> However, when I define and allocate that var in arch/ia64/mm/fault.c:
>>
>> unsigned char user_space_shared[ sizeof(user_space_shared_t) +
>> PAGE_SIZE ] __attribute__((aligned(PAGE_SIZE)));
>> EXPORT_SYMBOL(user_space_shared);
>>
>> And access that var from the module:
>>
>> extern unsigned char user_space_shared[ sizeof(user_space_shared_t) +
>> PAGE_SIZE ];
>>
>> There is no error message, but I can't read the contents i wrote
>> inside the kernel module from the application.
>>
>> Your help would be appreciated.
>>
>> ps:
>> I am taking care of page offsets/boundaries.
>> I'm using kernel 2.6.32 for ia64.
>>
>>
>> --
>> Eduardo Henrique Molina da Cruz
>> PhD student
>> Parallel and Distributed Processing Group
>> Federal University of Rio Grande do Sul (UFRGS)



-- 
Eduardo Henrique Molina da Cruz
PhD student
Parallel and Distributed Processing Group
Federal University of Rio Grande do Sul (UFRGS)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: dm: dm-cache fails to write the cache device in writethrough mode

[Mike Snitzer]

On Sat, Mar 23 2013 at  5:08pm -0400,
Mike Snitzer  wrote:
 
> But even after having changed my test to use /dev/sdb for the origin
> device I cannot reproduce the problem you've reported.  Do you have any
> further details on how/why the bios are being altered?  Are you
> reliably hitting partial completions within the origin's driver?  If so
> how?

I can easily see bio->bi_size being 0 in writethrough_endio, here is the
stack trace from a WARN_ON_ONCE(!bio->bi_size); that I added to
writethrough_endio:

Call Trace:
   [] warn_slowpath_common+0x7f/0xc0
 [] warn_slowpath_null+0x1a/0x20
 [] writethrough_endio+0x13f/0x150 [dm_cache]
 [] bio_endio+0x3d/0x90
 [] req_bio_endio+0xa3/0xe0
 [] blk_update_request+0x10f/0x480
 [] blk_update_bidi_request+0x27/0xb0
 [] blk_end_bidi_request+0x2f/0x80
 [] blk_end_request+0x10/0x20
 [] scsi_end_request+0x40/0xb0
 [] ? entity_tick+0x97/0x420
 [] scsi_io_completion+0x9f/0x660
 [] ? raise_softirq_irqoff+0x9/0x50
 [] scsi_finish_command+0xc9/0x130
 [] scsi_softirq_done+0x147/0x170
 [] blk_done_softirq+0x82/0xa0
 [] __do_softirq+0xe7/0x260
 [] ? bio_alloc_bioset+0x65/0x120
 [] call_softirq+0x1c/0x30
 [] do_softirq+0x65/0xa0
 [] irq_exit+0xbd/0xe0
 [] do_IRQ+0x66/0xe0
 [] common_interrupt+0x6d/0x6d

No idea why I was so oblivious to a bio->bi_size of 0 reflecting
completion.  So nothing to do with partial completion at all.

Here is a version of the patch you posted that uses
dm_bio_{record,restore} like Alasdair suggested:

diff --git a/drivers/md/dm-cache-target.c b/drivers/md/dm-cache-target.c
index 66120bd..90b1dd2 100644
--- a/drivers/md/dm-cache-target.c
+++ b/drivers/md/dm-cache-target.c
@@ -5,6 +5,7 @@
  */
 
 #include "dm.h"
+#include "dm-bio-record.h"
 #include "dm-bio-prison.h"
 #include "dm-cache-metadata.h"
 
@@ -205,6 +206,7 @@ struct per_bio_data {
struct cache *cache;
dm_cblock_t cblock;
bio_end_io_t *saved_bi_end_io;
+   struct dm_bio_details bio_details;
 };
 
 struct dm_cache_migration {
@@ -643,6 +645,7 @@ static void writethrough_endio(struct bio *bio, int err)
return;
}
 
+   dm_bio_restore(>bio_details, bio);
remap_to_cache(pb->cache, bio, pb->cblock);
 
/*
@@ -668,6 +671,7 @@ static void remap_to_origin_then_cache(struct cache *cache, 
struct bio *bio,
pb->cblock = cblock;
pb->saved_bi_end_io = bio->bi_end_io;
bio->bi_end_io = writethrough_endio;
+   dm_bio_record(>bio_details, bio);
 
remap_to_origin_clear_discard(pb->cache, bio, oblock);
 }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] (xen) stable/for-linus-3.9-rc3-tag

[Linus Torvalds]

On Sat, Mar 23, 2013 at 10:08 AM, Stefano Stabellini
 wrote:
>
> Unless I am looking in the wrong place, this patch is still the same one
> that breaks PV on HVM and Xen ARM guests, see:

Konrad?

I'll hold off on the pull request for now.

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

snd-hda-intel problem

[Donn Washburn]

Please forward -  I am not on your email list so please CC any email to
"alsa-info.sh"

I am running openSuSE 12.3, KDE4,  alsa, pulseaudio, kernel 3.9-rc3 and 
flash (very current version)
The sound works except the volume on pavumixer  which goes up and down. 
and some times not at all.

It is a snd-hda-intel driver   Some time it even come up at full volume

--
73 de Donn Washburn
1803 Oaklawn  Email 
Sugar Land, TX 77498-2249  LL# 1.281.242.4807
Ham Callsign N5XWB   HAMs : 
VoIP via Skype:n5xwbg  BMWMOA #:4146 Ambassador
  " http://counter.li.org " #279316

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

Re: [PATCH v2 0/8] watchdog: w83627hf: Convert to watchdog infrastructure

[Guenter Roeck]

On Sat, Mar 23, 2013 at 01:57:42PM +0100, Wim Van Sebroeck wrote:
> Hi Guenter,
> 
> > > In 2011 I started something similar but then with the MFD approach in 
> > > mind.
> > > Goal was also to clean-up the w836* watchdog drivers and get a clean 
> > > driver that
> > > supports all Winbond super-I/O based watchdog drivers.
> > > 
> > > I dug op the development code again. I'll post it in a next e-mail so 
> > > that we can
> > > see what the best way forward is. Note: I took the MFD approach because:
> > > 1) all superio shares the similar functions for using the Super-I/O 
> > > registers.
> > > 2) Goal is to have low-level driver that support the specific super-I/O 
> > > chipsets
> > > and that does the platform stuff for hwmon, watchdog, gpio, ...
> > > 
> > Hi Wim,
> > 
> > I started with a similar approach, only I used mfd cells to pass on platform
> > specific information such as the device type and the superio base address.
> > I still have the patchset for the mfd driver, in case you are interested.
> > My code is based on the patches submitted by Rodolfo Giometti a couple
> > of years ago. Want me to post it ?
> 
> If it's not v1 then I am interested.
> I think it depends on the super-I/O chipset of what info you can pass. I would
> not use mfd cells for the winbond driver but use platform data (similar to
> drivers/mfd/adp5520.c) because you don't need more then just pass some data.
> 
Actually one can pass platform data through mfd cells, which is what I do.
I pass the SIO address, the chip type (as enum), and the chip name to the
platform driver.

> > What I noticed in my testing is that the superio address range (2e or 4e),
> > which the drivers currently take as granted, is at least on my systems
> > (all three of them) reserved by ACPI. Unfortunately that means one can not
> > use the mfd infrastructure to pass on the superio memory region,
> > since it checks for acpi conflicts. With that I gave up on the idea and
> > reverted to using request_muxed_region. That seemed simpler and accomplish
> > the same as long as all drivers actually use it.
> 
> Noticed the same. That's why passing the platform data together with the
> superio-address and type seems the best way to go. I also kept the 
> superio_enter
> and superio_exit a function in the low level driver because I used a lock to
> make sure that the hwmon code doesn't start doing things when the watchdog is
> doing things. But I think that the request_muxed_region is doing something 
> similar
> also.
> 
Yes, it does the same. Only difference is that using a function in the mfd
driver increases the use count on it when a client module is loaded.

Patch follows.

Thanks,
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/5] ARM: sun4i: Add muxing options for the ethernet controller

[Maxime Ripard]

The EMAC only has one pinset available for muxing, so hopefully, we
cover all cases.

Signed-off-by: Maxime Ripard 
---
 arch/arm/boot/dts/sun4i-a10.dtsi |   11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi b/arch/arm/boot/dts/sun4i-a10.dtsi
index a6bd36a..e5ef5e5 100644
--- a/arch/arm/boot/dts/sun4i-a10.dtsi
+++ b/arch/arm/boot/dts/sun4i-a10.dtsi
@@ -46,6 +46,17 @@
allwinner,drive = <0>;
allwinner,pull = <0>;
};
+
+   emac_pins_a: emac0@0 {
+   allwinner,pins = "PA0", "PA1", "PA2",
+   "PA3", "PA4", "PA5", "PA6",
+   "PA7", "PA8", "PA9", "PA10",
+   "PA11", "PA12", "PA13", "PA14",
+   "PA15", "PA16";
+   allwinner,function = "wemac";
+   allwinner,drive = <0>;
+   allwinner,pull = <0>;
+   };
};
 
emac: ethernet@01c0b000 {
-- 
1.7.10.4

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

[PATCH 1/5] net: Add EMAC ethernet driver found on Allwinner A10 SoC's

[Maxime Ripard]

From: Stefan Roese 

The Allwinner A10 has an ethernet controller that seem to be developped
internally by them.

The exact feature set of this controller is unknown, since there is no
public documentation for this IP, and this driver is mostly the one
published by Allwinner that has been heavily cleaned up.

Signed-off-by: Stefan Roese 
Signed-off-by: Maxime Ripard 
---
 .../bindings/net/allwinner,sun4i-emac.txt  |   19 +
 drivers/net/ethernet/Kconfig   |1 +
 drivers/net/ethernet/Makefile  |1 +
 drivers/net/ethernet/allwinner/Kconfig |   36 +
 drivers/net/ethernet/allwinner/Makefile|5 +
 drivers/net/ethernet/allwinner/sun4i-emac.c| 1033 
 drivers/net/ethernet/allwinner/sun4i-emac.h|  114 +++
 7 files changed, 1209 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt
 create mode 100644 drivers/net/ethernet/allwinner/Kconfig
 create mode 100644 drivers/net/ethernet/allwinner/Makefile
 create mode 100644 drivers/net/ethernet/allwinner/sun4i-emac.c
 create mode 100644 drivers/net/ethernet/allwinner/sun4i-emac.h

diff --git a/Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt 
b/Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt
new file mode 100644
index 000..aaf5013
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt
@@ -0,0 +1,19 @@
+* Allwinner EMAC ethernet controller
+
+Required properties:
+- compatible: should be "allwinner,sun4i-emac".
+- reg: address and length of the register set for the device.
+- interrupts: interrupt for the device
+
+Optional properties:
+- phy-supply: phandle to a regulator if the PHY needs one
+- (local-)mac-address: mac address to be used by this driver
+
+Example:
+
+emac: ethernet@01c0b000 {
+   compatible = "allwinner,sun4i-emac";
+   reg = <0x01c0b000 0x1000>;
+   phy-supply = <_emac_3v3>;
+   interrupts = <55>;
+};
diff --git a/drivers/net/ethernet/Kconfig b/drivers/net/ethernet/Kconfig
index ed956e0..18fd6fb 100644
--- a/drivers/net/ethernet/Kconfig
+++ b/drivers/net/ethernet/Kconfig
@@ -20,6 +20,7 @@ config SUNGEM_PHY
 source "drivers/net/ethernet/3com/Kconfig"
 source "drivers/net/ethernet/adaptec/Kconfig"
 source "drivers/net/ethernet/aeroflex/Kconfig"
+source "drivers/net/ethernet/allwinner/Kconfig"
 source "drivers/net/ethernet/alteon/Kconfig"
 source "drivers/net/ethernet/amd/Kconfig"
 source "drivers/net/ethernet/apple/Kconfig"
diff --git a/drivers/net/ethernet/Makefile b/drivers/net/ethernet/Makefile
index 8268d85..009da27 100644
--- a/drivers/net/ethernet/Makefile
+++ b/drivers/net/ethernet/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_NET_VENDOR_3COM) += 3com/
 obj-$(CONFIG_NET_VENDOR_8390) += 8390/
 obj-$(CONFIG_NET_VENDOR_ADAPTEC) += adaptec/
 obj-$(CONFIG_GRETH) += aeroflex/
+obj-$(CONFIG_NET_VENDOR_ALLWINNER) += allwinner/
 obj-$(CONFIG_NET_VENDOR_ALTEON) += alteon/
 obj-$(CONFIG_NET_VENDOR_AMD) += amd/
 obj-$(CONFIG_NET_VENDOR_APPLE) += apple/
diff --git a/drivers/net/ethernet/allwinner/Kconfig 
b/drivers/net/ethernet/allwinner/Kconfig
new file mode 100644
index 000..5d20fb0
--- /dev/null
+++ b/drivers/net/ethernet/allwinner/Kconfig
@@ -0,0 +1,36 @@
+#
+# Allwinner device configuration
+#
+
+config NET_VENDOR_ALLWINNER
+   bool "Allwinner devices"
+   default y
+   depends on ARCH_SUNXI
+   ---help---
+ If you have a network (Ethernet) card belonging to this
+class, say Y and read the Ethernet-HOWTO, available from
+.
+
+Note that the answer to this question doesn't directly
+affect the kernel: saying N will just cause the configurator
+to skip all the questions about Davicom cards. If you say Y,
+you will be asked for your specific card in the following
+questions.
+
+if NET_VENDOR_ALLWINNER
+
+config SUN4I_EMAC
+tristate "Allwinner A10 EMAC support"
+   depends on ARCH_SUNXI
+   depends on OF
+   select CRC32
+   select NET_CORE
+   select MII
+   select REGULATOR_FIXED_VOLTAGE
+---help---
+  Support for Allwinner A10 EMAC ethernet driver.
+
+  To compile this driver as a module, choose M here.  The module
+  will be called sun4i-emac.
+
+endif # NET_VENDOR_ALLWINNER
diff --git a/drivers/net/ethernet/allwinner/Makefile 
b/drivers/net/ethernet/allwinner/Makefile
new file mode 100644
index 000..03129f7
--- /dev/null
+++ b/drivers/net/ethernet/allwinner/Makefile
@@ -0,0 +1,5 @@
+#
+# Makefile for the Allwinner device drivers.
+#
+
+obj-$(CONFIG_SUN4I_EMAC) += sun4i-emac.o
diff --git a/drivers/net/ethernet/allwinner/sun4i-emac.c 
b/drivers/net/ethernet/allwinner/sun4i-emac.c
new file mode 100644
index 000..66bc089
--- /dev/null
+++ b/drivers/net/ethernet/allwinner/sun4i-emac.c
@@ -0,0 +1,1033 @@
+/*
+ * Allwinner EMAC Fast Ethernet driver 

[PATCH 5/5] ARM: hackberry: dt: Add Ethernet controller to the Hackberry device tree

[Maxime Ripard]

The Hackberry has a PHY that needs to be powered up through a GPIO, so
we need to use a fixed regulator here.

Signed-off-by: Maxime Ripard 
---
 arch/arm/boot/dts/sun4i-a10-hackberry.dts |   32 +
 1 file changed, 32 insertions(+)

diff --git a/arch/arm/boot/dts/sun4i-a10-hackberry.dts 
b/arch/arm/boot/dts/sun4i-a10-hackberry.dts
index f84549a..072d51f 100644
--- a/arch/arm/boot/dts/sun4i-a10-hackberry.dts
+++ b/arch/arm/boot/dts/sun4i-a10-hackberry.dts
@@ -23,8 +23,40 @@
};
 
soc {
+   pio: pinctrl@01c20800 {
+   pinctrl-names = "default";
+   pinctrl-0 = <_hogs>;
+
+   hackberry_hogs: hogs@0 {
+   allwinner,pins = "PH19";
+   allwinner,function = "gpio_out";
+   allwinner,drive = <0>;
+   allwinner,pull = <0>;
+   };
+   };
+
uart0: uart@01c28000 {
status = "okay";
};
+
+   emac: ethernet@01c0b000 {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_a>;
+   phy-supply = <_emac_3v3>;
+   status = "okay";
+   };
+   };
+
+   regulators {
+   compatible = "simple-bus";
+
+   reg_emac_3v3: emac-3v3 {
+   compatible = "regulator-fixed";
+   regulator-name = "emac-3v3";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   enable-active-high;
+   gpio = < 7 19 0>;
+   };
};
 };
-- 
1.7.10.4

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

[PATCH 4/5] ARM: cubieboard: Enable ethernet (WEMAC) support in dts

[Maxime Ripard]

From: Stefan Roese 

Signed-off-by: Stefan Roese 
---
 arch/arm/boot/dts/sun4i-a10-cubieboard.dts |6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/sun4i-a10-cubieboard.dts 
b/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
index 88e2dc1..9bf4b4f 100644
--- a/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
+++ b/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
@@ -43,6 +43,12 @@
uart1: uart@01c28400 {
status = "okay";
};
+
+   emac: ethernet@01c0b000 {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_a>;
+   status = "okay";
+   };
};
 
leds {
-- 
1.7.10.4

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

[PATCH 2/5] ARM: sunxi: Add EMAC controller node to sun4i DTSI

[Maxime Ripard]

Signed-off-by: Maxime Ripard 
---
 arch/arm/boot/dts/sun4i-a10.dtsi |7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi b/arch/arm/boot/dts/sun4i-a10.dtsi
index 03d2b53..a6bd36a 100644
--- a/arch/arm/boot/dts/sun4i-a10.dtsi
+++ b/arch/arm/boot/dts/sun4i-a10.dtsi
@@ -47,5 +47,12 @@
allwinner,pull = <0>;
};
};
+
+   emac: ethernet@01c0b000 {
+   compatible = "allwinner,sun4i-emac";
+   reg = <0x01c0b000 0x1000>;
+   interrupts = <55>;
+   status = "disabled";
+   };
};
 };
-- 
1.7.10.4

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

Re: [patch] mm: speedup in __early_pfn_to_nid

[KOSAKI Motohiro]

> --- linux.orig/mm/page_alloc.c  2013-03-19 16:09:03.736450861 -0500
> +++ linux/mm/page_alloc.c   2013-03-22 17:07:43.895405617 -0500
> @@ -4161,10 +4161,23 @@ int __meminit __early_pfn_to_nid(unsigne
>  {
> unsigned long start_pfn, end_pfn;
> int i, nid;
> +   /*
> +  NOTE: The following SMP-unsafe globals are only used early
> +  in boot when the kernel is running single-threaded.
> +*/
> +   static unsigned long last_start_pfn, last_end_pfn;
> +   static int last_nid;

Why don't you mark them __meminitdata? They seems freeable.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] wfcqueue: functions for local append and enqueue

[Mathieu Desnoyers]

* Eric Wong (normalper...@yhbt.net) wrote:
> Mathieu Desnoyers  wrote:
> > * Eric Wong (normalper...@yhbt.net) wrote:
> > >  /*
> > > + * ___wfcq_append: append one local queue to another local queue
> > > + *
> 
> > __wfcq_append() and ___wfcq_append() are meant to be private to
> > wfcqueue.h. Therefore, the comment above should be removed, since it is
> > not part of the API.
> > 
> > I notice that I should have used ___wfcq_append() for the original
> > append function for consistency (other private helpers in this header
> > are prefixed with ___).
> > 
> > So maybe we should rename __wfcq_append to ___wfcq_append (making it
> > clear that it is a private helper), and introduce your helper as
> > ___wfcq_append_local() (I don't care about having "local" in there since
> > it is not part of the exposed API).
> 
> Thanks for the explanation, I've squashed that renames into my patch
> below and removed the comment.
> 
> > > +/*
> > > + * __wfcq_enqueue: enqueue a node into a local queue
> > 
> > The concept of "local queue" is not clearly defined.
> > 
> > Perhaps it would be clearer to state:
> > 
> >  * __wfcq_enqueue: enqueue a node into a queue, requiring mutual exclusion.
> 
> Sounds good to me.  Updated patch below:
> 
> ---8<-
> From: Eric Wong 
> Date: Sat, 23 Mar 2013 19:07:26 +
> Subject: [PATCH] wfcqueue: functions for local append and enqueue
> 
> With level-triggered epoll, append/enqueue operations to the
> local/locked queues increase performance by avoiding unnecessary atomic
> operations and barriers.  These are necessary to avoid performance
> regressions when looping through ep_send_events and appending many items
> to a local queue where the caller already manages mutual exclusion.

Looks good to me. Thanks!

Acked-by: Mathieu Desnoyers 

> 
> Changes since v1 and v2:
> * Function renaming and documentation updates
> * rename the existing private __wfcq_append to ___wfcq_append
> 
> Signed-off-by: Eric Wong 
> Cc: Mathieu Desnoyers 
> Cc: Lai Jiangshan 
> Cc: Paul E. McKenney 
> Cc: Stephen Hemminger 
> Cc: Davide Libenzi 
> ---
>  include/linux/wfcqueue.h | 56 
> +++-
>  1 file changed, 46 insertions(+), 10 deletions(-)
> 
> diff --git a/include/linux/wfcqueue.h b/include/linux/wfcqueue.h
> index 9464a0c..a452ab9 100644
> --- a/include/linux/wfcqueue.h
> +++ b/include/linux/wfcqueue.h
> @@ -55,14 +55,16 @@
>   * [4] __wfcq_splice (source queue)
>   * [5] __wfcq_first
>   * [6] __wfcq_next
> + * [7] __wfcq_enqueue
>   *
> - * [1] [2] [3] [4] [5] [6]
> - * [1]  -   -   -   -   -   -
> - * [2]  -   -   -   -   -   -
> - * [3]  -   -   X   X   X   X
> - * [4]  -   -   X   -   X   X
> - * [5]  -   -   X   X   -   -
> - * [6]  -   -   X   X   -   -
> + * [1] [2] [3] [4] [5] [6] [7]
> + * [1]  -   -   -   -   -   -   X
> + * [2]  -   -   -   -   -   -   X
> + * [3]  -   -   X   X   X   X   X
> + * [4]  -   -   X   -   X   X   X
> + * [5]  -   -   X   X   -   -   X
> + * [6]  -   -   X   X   -   -   X
> + * [7]  X   X   X   X   X   X   X
>   *
>   * Besides locking, mutual exclusion of dequeue, splice and iteration
>   * can be ensured by performing all of those operations from a single
> @@ -147,7 +149,7 @@ static inline bool wfcq_empty(struct wfcq_head *head,
>   && CMM_LOAD_SHARED(tail->p) == >node;
>  }
>  
> -static inline bool __wfcq_append(struct wfcq_head *head,
> +static inline bool ___wfcq_append(struct wfcq_head *head,
>   struct wfcq_tail *tail,
>   struct wfcq_node *new_head,
>   struct wfcq_node *new_tail)
> @@ -201,7 +203,41 @@ static inline bool wfcq_enqueue(struct wfcq_head *head,
>   struct wfcq_tail *tail,
>   struct wfcq_node *new_tail)
>  {
> - return __wfcq_append(head, tail, new_tail, new_tail);
> + return ___wfcq_append(head, tail, new_tail, new_tail);
> +}
> +
> +static inline bool ___wfcq_append_local(struct wfcq_head *head,
> + struct wfcq_tail *tail,
> + struct wfcq_node *new_head,
> + struct wfcq_node *new_tail)
> +{
> + struct wfcq_node *old_tail;
> +
> + old_tail = tail->p;
> + tail->p = new_tail;
> + old_tail->next = new_head;
> +
> + /*
> +  * Return false if queue was empty prior to adding the node,
> +  * else return true.
> +  */
> + return old_tail != >node;
> +}
> +
> +/*
> + * __wfcq_enqueue: enqueue a node into a queue, requiring mutual exclusion.
> + *
> + * No memory barriers are issued.  Mutual exclusion is the responsibility
> + * of the caller.
> + *
> + * Returns false if the queue was empty prior to adding the node.
> + * Returns true otherwise.
> + */
> +static inline bool __wfcq_enqueue(struct wfcq_head *head,
> + struct wfcq_tail *tail,
> + struct wfcq_node *new_tail)
> +{
> + return ___wfcq_append_local(head, tail, new_tail, new_tail);
>  }
>  
>  /*
> 

Re: remap kernel static memory to user space

[Hugh Dickins]

On Wed, 20 Mar 2013, Eduardo Cruz wrote:

> Hello.
> 
> I'm trying to remap some kernel static memory to user space using
> remap_pfn_range.
> For that, I wrote a module that initializes a device, which later I
> use mknod, etc.
> 
> When I allocate the memory with kmalloc, everything works:   (where
> user_space_shared was allocated with kmalloc)
> 
> if ((ret = remap_pfn_range(vma, vma->vm_start,
> virt_to_phys(user_space_shared) >> PAGE_SHIFT, length,
> vma->vm_page_prot)) < 0)

I have no ia64 experience, but my guess is that your problem is with
that virt_to_phys(user_space_shared).

virt_to_phys() expects to be given an address from the kernel's direct
map of physical memory; whereas if you declare user_space_shared[] in
kernel static memory, I believe ia64 places that in a different region.

Try changing that to virt_to_phys(ia64_imva(user_space_shared))
and I expect it will then work: see comment above ia64_imva()
in arch/ia64/include/asm/processor.h.

Hugh

> 
> In the application in user space:
> kstc = mmap(0, sizeof(user_space_shared_t), PROT_READ|PROT_WRITE,
> MAP_SHARED| MAP_LOCKED, fd, 0);
> 
> With user_space_shared allocated using kmalloc, it is working.
> The application is able to read the data I wrote in the kernel module.
> 
> However, when I define and allocate that var in arch/ia64/mm/fault.c:
> 
> unsigned char user_space_shared[ sizeof(user_space_shared_t) +
> PAGE_SIZE ] __attribute__((aligned(PAGE_SIZE)));
> EXPORT_SYMBOL(user_space_shared);
> 
> And access that var from the module:
> 
> extern unsigned char user_space_shared[ sizeof(user_space_shared_t) +
> PAGE_SIZE ];
> 
> There is no error message, but I can't read the contents i wrote
> inside the kernel module from the application.
> 
> Your help would be appreciated.
> 
> ps:
> I am taking care of page offsets/boundaries.
> I'm using kernel 2.6.32 for ia64.
> 
> 
> -- 
> Eduardo Henrique Molina da Cruz
> PhD student
> Parallel and Distributed Processing Group
> Federal University of Rio Grande do Sul (UFRGS)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] early_printk: consolidate random copies of identical code

[Geert Uytterhoeven]

On Fri, Mar 8, 2013 at 5:11 PM, Paul Gortmaker
 wrote:
> From: Thomas Gleixner 
>
> The early console implementations are the same all over the place.  Move
> the print function to kernel/printk and get rid of the copies.
>
> Signed-off-by: Thomas Gleixner 
> Cc: Russell King 
> Acked-by: Mike Frysinger 
> Cc: Michal Simek 
> Cc: Ralf Baechle 
> Cc: Benjamin Herrenschmidt 
> Cc: Paul Mundt 
> Cc: "David S. Miller" 
> Cc: Chris Metcalf 
> Cc: Richard Weinberger 
> Reviewed-by: Ingo Molnar 
> Signed-off-by: Paul Gortmaker 
> ---
>
> [v3: drop sparc bits as suggested by tglx, redo build tests on sparc
>  sparc32, Randy's randconfig, ppc, mips, arm...]
>
> [v2: essentially unchanged since v1, so I've left the acked/reviewed
>  tags.  There was a compile fail[1] for a randconfig with EARLY_PRINTK=y
>  and PRINTK=n, because the early_console struct and early_printk calls
>  were nested within an #ifdef CONFIG_PRINTK -- moving that whole block
>  exactly as-is to be outside the #ifdef CONFIG_PRINTK fixes the randconfig
>  and still works for everyday sane configs too.]
>  [1] http://marc.info/?l=linux-next=136219350914998=2

> --- a/arch/sh/kernel/sh_bios.c
> +++ b/arch/sh/kernel/sh_bios.c
> @@ -144,8 +144,6 @@ static struct console bios_console = {
> .index  = -1,
>  };
>
> -static struct console *early_console;

This one wasn't protected by #ifdef CONFIG_EARLY_PRINTK...

> --- a/kernel/printk.c
> +++ b/kernel/printk.c
> @@ -1724,6 +1717,29 @@ static size_t cont_print_text(char *text, size_t size) 
> { return 0; }
>
>  #endif /* CONFIG_PRINTK */
>
> +#ifdef CONFIG_EARLY_PRINTK
> +struct console *early_console;

... but this one is, causing

arch/sh/kernel/built-in.o: In function `setup_early_printk':
sh_bios.c:(.init.text+0xc80): undefined reference to `early_console'

Cfr. e.g. http://kisskb.ellerman.id.au/kisskb/buildresult/8433720/

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] bnx2x: fix assignment of signed expression to unsigned variable

[Dan Carpenter]

On Sat, Mar 23, 2013 at 01:45:11PM -0700, Kumar amit mehta wrote:
> On Sat, Mar 23, 2013 at 10:56:47PM +0300, Dan Carpenter wrote:
> >
> > The fix for this is more involved.  The function prototype should
> > be changed to return an int.  The caller should be updated to check
> > for errors.
> >
> I wonder, why these callbacks are restricting the lower layers to return
> only unsigned values, However Updating the prototype doesn't seem a good idea 
> as
> then it would require changes in various existing drivers.

Yes.  Everything will need to be updated.  I've known this code is
buggy for years but I've never tried patching it because I'm very
lazy.  :)

But actually it's only three drivers I think: bnx2x, ixgbe, and
mlx4.   I suspect that most of the functions always return zero and
won't need to be modified.

regards,
dan carpenter

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

Re: [dm-devel] dm: dm-cache fails to write the cache device in writethrough mode

[Alasdair G Kergon]

On Fri, Mar 22, 2013 at 10:15:49PM -0700, Darrick J. Wong wrote:
> Interesting ... if I set up this:
> # echo "0 67108864 linear /dev/sda 0" | dmsetup create origin
> And then repeat the test, but using /dev/mapper/origin as the origin instead
> of /dev/sda, the problem goes away.
 
So that looks like an easy and correct workaround for now.

Alasdair

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: dm: dm-cache fails to write the cache device in writethrough mode

[Mike Snitzer]

On Sat, Mar 23 2013 at  1:15am -0400,
Darrick J. Wong  wrote:

> On Fri, Mar 22, 2013 at 11:27:16PM -0400, Mike Snitzer wrote:
> > On Fri, Mar 22 2013 at  7:16pm -0400,
> > Darrick J. Wong  wrote:
> > 
> > > On Fri, Mar 22, 2013 at 06:34:28PM -0400, Mike Snitzer wrote:
> > > > On Fri, Mar 22 2013 at  4:11pm -0400,
> > > > Darrick J. Wong  wrote:
> > > > 
> > > > > The new writethrough strategy for dm-cache issues a bio to the origin 
> > > > > device,
> > > > > remaps the bio to the cache device, and issues the bio to the cache 
> > > > > device.
> > > > > However, the block layer modifies bi_sector and bi_size, so we need 
> > > > > to preserve
> > > > > these or else nothing gets written to the cache (bi_size == 0).  This 
> > > > > fixes the
> > > > > problem where someone writes a block through the cache, but a 
> > > > > subsequent reread
> > > > > (from the cache) returns old contents.
> > > > 
> > > > Your writethrough blkid test results are certainly strange.  But I'm not
> > > > aware of where the block layer would modify bi_size and bi_sector;
> > > > please elaborate.
> > > > 
> > > > I cannot reproduce your original report.  I developed
> > > > 'test_writethrough_ext4_uuids_match', apologies for the ruby code:
> > > 
> > > Hmm... I'm building my kernels off 
> > > 0a7e453103b9718d357688b83bb968ee108cc874 in
> > > Linus' tree (post 3.9-rc3).  This is the full output of dmsetup table:
> > > 
> > > moocache-blocks: 0 1039360 linear 8:16 9088
> > > moocache-metadata: 0 8704 linear 8:16 384
> > > moocache: 0 67108864 cache 253:0 253:1 8:0 512 1 writethrough default 4 
> > > random_threshold 4 sequential_threshold 32768
> > > 
> > > 253:0 -> moocache-metadata and 253:1 -> moocache-blocks.
> > > 
> > > I'm curious what your setup is...
> > 
> > Here are the tables:
> > test-dev-238267: 0 8192 linear /dev/stec/metadata 0
> > test-dev-255913: 0 2097152 linear /dev/stec/metadata 8192
> > test-dev-655144: 0 20480 linear /dev/spindle/data 0
> > 0 20480 cache /dev/mapper/test-dev-238267 /dev/mapper/test-dev-255913 
> > /dev/mapper/test-dev-655144 512 1 writethrough default 0
> > 
> > And I tweaked 'test_writethrough_ext4_uuids_match' to make sure to use the
> > same thresholds you're using, full status output:
> > 0 20480 cache 15/1024 0 19 0 0 0 0 0 0 1 writethrough 2 migration_threshold 
> > 32768 4 random_threshold 4 sequential_threshold 512
> > 
> > So the big difference is the thinp-test-suite uses intermediate linear
> > DM layers above the slower sd device (spindle/data) -- whereas in your
> > setup the origin device is direct to sd (8:0).
> > 
> > I'll re-run with the origin directly on sd in the morning and will
> > report back.
> 
> Interesting ... if I set up this:
> 
> # echo "0 67108864 linear /dev/sda 0" | dmsetup create origin
> 
> And then repeat the test, but using /dev/mapper/origin as the origin instead
> of /dev/sda, the problem goes away.

Using the extra dm-linear layer is implicitly leveraging the DM core's
bio cloning to restore the original bio that was sent to the linear
target.

But even after having changed my test to use /dev/sdb for the origin
device I cannot reproduce the problem you've reported.  Do you have any
further details on how/why the bios are being altered?  Are you
reliably hitting partial completions within the origin's driver?  If so
how?

Having looked at this for a bit it seems pretty clear writethrough_endio
is missing partial completion handling, e.g.:
   if (!bio_flagged(bio, BIO_UPTODATE) && !err)
  err = -EIO;

But I haven't yet come to terms with what the partial completion
handling implementation needs to be for the writethrough support.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] bnx2x: fix assignment of signed expression to unsigned variable

[Kumar amit mehta]

On Sat, Mar 23, 2013 at 10:56:47PM +0300, Dan Carpenter wrote:
> On Sat, Mar 23, 2013 at 11:52:55AM -0700, Kumar Amit Mehta wrote:
> > fix for incorrect assignment of signed expression to unsigned variable.
> > 
> 
> This fix isn't right.
> 
> > Signed-off-by: Kumar Amit Mehta 
> > ---
> >  drivers/net/ethernet/broadcom/bnx2x/bnx2x_dcb.c |   20 ++--
> >  1 file changed, 10 insertions(+), 10 deletions(-)
> > 
> > diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_dcb.c 
> > b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_dcb.c
> > index 5682054..b90533a 100644
> > --- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_dcb.c
> > +++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_dcb.c
> > @@ -2139,12 +2139,12 @@ static u8 bnx2x_dcbnl_get_cap(struct net_device 
> > *netdev, int capid, u8 *cap)
> > break;
> > default:
> > BNX2X_ERR("Non valid capability ID\n");
> > -   rval = -EINVAL;
> > +   rval = EINVAL;
> > break;
> > }
> > } else {
> > DP(BNX2X_MSG_DCB, "DCB disabled\n");
> > -   rval = -EINVAL;
> > +   rval = EINVAL;
> 
> This function is called from dcbnl_getcap().  It returns zero on
> success, but it's not clear what it should return on failure.  But
> certainly it's not a positive EINVAL.
> 
> > }
> >  
> > DP(BNX2X_MSG_DCB, "capid %d:%x\n", capid, *cap);
> > @@ -2154,7 +2154,7 @@ static u8 bnx2x_dcbnl_get_cap(struct net_device 
> > *netdev, int capid, u8 *cap)
> >  static int bnx2x_dcbnl_get_numtcs(struct net_device *netdev, int tcid, u8 
> > *num)
> >  {
> > struct bnx2x *bp = netdev_priv(netdev);
> > -   u8 rval = 0;
> > +   s8 rval = 0;
> 
> Just use "int" here.
> 
> >  
> > DP(BNX2X_MSG_DCB, "tcid %d\n", tcid);
> >  
> > @@ -2188,7 +2188,7 @@ static int bnx2x_dcbnl_set_numtcs(struct net_device 
> > *netdev, int tcid, u8 num)
> > return -EINVAL;
> >  }
> >  
> > -static u8  bnx2x_dcbnl_get_pfc_state(struct net_device *netdev)
> > +static u8 bnx2x_dcbnl_get_pfc_state(struct net_device *netdev)
> >  {
> > struct bnx2x *bp = netdev_priv(netdev);
> > DP(BNX2X_MSG_DCB, "state = %d\n", bp->dcbx_local_feat.pfc.enabled);
> > @@ -2282,7 +2282,7 @@ static int bnx2x_set_admin_app_up(struct bnx2x *bp, 
> > u8 idtype, u16 idval, u8 up)
> > else {
> > /* app table is full */
> > BNX2X_ERR("Application table is too large\n");
> > -   return -EBUSY;
> > +   return EBUSY;
> > }
> 
> The fix for this is more involved.  The function prototype should
> be changed to return an int.  The caller should be updated to check
> for errors.
>
I wonder, why these callbacks are restricting the lower layers to return
only unsigned values, However Updating the prototype doesn't seem a good idea as
then it would require changes in various existing drivers.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3] wfcqueue: functions for local append and enqueue

[Eric Wong]

Mathieu Desnoyers  wrote:
> * Eric Wong (normalper...@yhbt.net) wrote:
> >  /*
> > + * ___wfcq_append: append one local queue to another local queue
> > + *

> __wfcq_append() and ___wfcq_append() are meant to be private to
> wfcqueue.h. Therefore, the comment above should be removed, since it is
> not part of the API.
> 
> I notice that I should have used ___wfcq_append() for the original
> append function for consistency (other private helpers in this header
> are prefixed with ___).
> 
> So maybe we should rename __wfcq_append to ___wfcq_append (making it
> clear that it is a private helper), and introduce your helper as
> ___wfcq_append_local() (I don't care about having "local" in there since
> it is not part of the exposed API).

Thanks for the explanation, I've squashed that renames into my patch
below and removed the comment.

> > +/*
> > + * __wfcq_enqueue: enqueue a node into a local queue
> 
> The concept of "local queue" is not clearly defined.
> 
> Perhaps it would be clearer to state:
> 
>  * __wfcq_enqueue: enqueue a node into a queue, requiring mutual exclusion.

Sounds good to me.  Updated patch below:

---8<-
From: Eric Wong 
Date: Sat, 23 Mar 2013 19:07:26 +
Subject: [PATCH] wfcqueue: functions for local append and enqueue

With level-triggered epoll, append/enqueue operations to the
local/locked queues increase performance by avoiding unnecessary atomic
operations and barriers.  These are necessary to avoid performance
regressions when looping through ep_send_events and appending many items
to a local queue where the caller already manages mutual exclusion.

Changes since v1 and v2:
* Function renaming and documentation updates
* rename the existing private __wfcq_append to ___wfcq_append

Signed-off-by: Eric Wong 
Cc: Mathieu Desnoyers 
Cc: Lai Jiangshan 
Cc: Paul E. McKenney 
Cc: Stephen Hemminger 
Cc: Davide Libenzi 
---
 include/linux/wfcqueue.h | 56 +++-
 1 file changed, 46 insertions(+), 10 deletions(-)

diff --git a/include/linux/wfcqueue.h b/include/linux/wfcqueue.h
index 9464a0c..a452ab9 100644
--- a/include/linux/wfcqueue.h
+++ b/include/linux/wfcqueue.h
@@ -55,14 +55,16 @@
  * [4] __wfcq_splice (source queue)
  * [5] __wfcq_first
  * [6] __wfcq_next
+ * [7] __wfcq_enqueue
  *
- * [1] [2] [3] [4] [5] [6]
- * [1]  -   -   -   -   -   -
- * [2]  -   -   -   -   -   -
- * [3]  -   -   X   X   X   X
- * [4]  -   -   X   -   X   X
- * [5]  -   -   X   X   -   -
- * [6]  -   -   X   X   -   -
+ * [1] [2] [3] [4] [5] [6] [7]
+ * [1]  -   -   -   -   -   -   X
+ * [2]  -   -   -   -   -   -   X
+ * [3]  -   -   X   X   X   X   X
+ * [4]  -   -   X   -   X   X   X
+ * [5]  -   -   X   X   -   -   X
+ * [6]  -   -   X   X   -   -   X
+ * [7]  X   X   X   X   X   X   X
  *
  * Besides locking, mutual exclusion of dequeue, splice and iteration
  * can be ensured by performing all of those operations from a single
@@ -147,7 +149,7 @@ static inline bool wfcq_empty(struct wfcq_head *head,
&& CMM_LOAD_SHARED(tail->p) == >node;
 }
 
-static inline bool __wfcq_append(struct wfcq_head *head,
+static inline bool ___wfcq_append(struct wfcq_head *head,
struct wfcq_tail *tail,
struct wfcq_node *new_head,
struct wfcq_node *new_tail)
@@ -201,7 +203,41 @@ static inline bool wfcq_enqueue(struct wfcq_head *head,
struct wfcq_tail *tail,
struct wfcq_node *new_tail)
 {
-   return __wfcq_append(head, tail, new_tail, new_tail);
+   return ___wfcq_append(head, tail, new_tail, new_tail);
+}
+
+static inline bool ___wfcq_append_local(struct wfcq_head *head,
+   struct wfcq_tail *tail,
+   struct wfcq_node *new_head,
+   struct wfcq_node *new_tail)
+{
+   struct wfcq_node *old_tail;
+
+   old_tail = tail->p;
+   tail->p = new_tail;
+   old_tail->next = new_head;
+
+   /*
+* Return false if queue was empty prior to adding the node,
+* else return true.
+*/
+   return old_tail != >node;
+}
+
+/*
+ * __wfcq_enqueue: enqueue a node into a queue, requiring mutual exclusion.
+ *
+ * No memory barriers are issued.  Mutual exclusion is the responsibility
+ * of the caller.
+ *
+ * Returns false if the queue was empty prior to adding the node.
+ * Returns true otherwise.
+ */
+static inline bool __wfcq_enqueue(struct wfcq_head *head,
+   struct wfcq_tail *tail,
+   struct wfcq_node *new_tail)
+{
+   return ___wfcq_append_local(head, tail, new_tail, new_tail);
 }
 
 /*
@@ -398,7 +434,7 @@ static inline enum wfcq_ret __wfcq_splice(
 * Append the spliced content of src_q into dest_q. Does not
 * require mutual exclusion on dest_q (wait-free).
 */
-   if (__wfcq_append(dest_q_head, dest_q_tail, head, tail))
+   if (___wfcq_append(dest_q_head, dest_q_tail, head, tail))

Re: [patch] mm: speedup in __early_pfn_to_nid

[Yinghai Lu]

On Sat, Mar 23, 2013 at 8:29 AM, Russ Anderson  wrote:
> On Fri, Mar 22, 2013 at 08:25:32AM +0100, Ingo Molnar wrote:
> 
> When booting on a large memory system, the kernel spends
> considerable time in memmap_init_zone() setting up memory zones.
> Analysis shows significant time spent in __early_pfn_to_nid().
>
> The routine memmap_init_zone() checks each PFN to verify the
> nid is valid.  __early_pfn_to_nid() sequentially scans the list of
> pfn ranges to find the right range and returns the nid.  This does
> not scale well.  On a 4 TB (single rack) system there are 308
> memory ranges to scan.  The higher the PFN the more time spent
> sequentially spinning through memory ranges.
>
> Since memmap_init_zone() increments pfn, it will almost always be
> looking for the same range as the previous pfn, so check that
> range first.  If it is in the same range, return that nid.
> If not, scan the list as before.
>
> A 4 TB (single rack) UV1 system takes 512 seconds to get through
> the zone code.  This performance optimization reduces the time
> by 189 seconds, a 36% improvement.
>
> A 2 TB (single rack) UV2 system goes from 212.7 seconds to 99.8 seconds,
> a 112.9 second (53%) reduction.

Interesting. but only have 308 entries in memblock...

Did you try to extend memblock_search() to search nid back?
Something like attached patch. That should save more time.

>
> Signed-off-by: Russ Anderson 
> ---
>  arch/ia64/mm/numa.c |   15 ++-
>  mm/page_alloc.c |   15 ++-
>  2 files changed, 28 insertions(+), 2 deletions(-)
>
> Index: linux/mm/page_alloc.c
> ===
> --- linux.orig/mm/page_alloc.c  2013-03-19 16:09:03.736450861 -0500
> +++ linux/mm/page_alloc.c   2013-03-22 17:07:43.895405617 -0500
> @@ -4161,10 +4161,23 @@ int __meminit __early_pfn_to_nid(unsigne
>  {
> unsigned long start_pfn, end_pfn;
> int i, nid;
> +   /*
> +  NOTE: The following SMP-unsafe globals are only used early
> +  in boot when the kernel is running single-threaded.
> +*/
> +   static unsigned long last_start_pfn, last_end_pfn;
> +   static int last_nid;
> +
> +   if (last_start_pfn <= pfn && pfn < last_end_pfn)
> +   return last_nid;
>
> for_each_mem_pfn_range(i, MAX_NUMNODES, _pfn, _pfn, )
> -   if (start_pfn <= pfn && pfn < end_pfn)
> +   if (start_pfn <= pfn && pfn < end_pfn) {
> +   last_start_pfn = start_pfn;
> +   last_end_pfn = end_pfn;
> +   last_nid = nid;
> return nid;
> +   }
> /* This is a memory hole */
> return -1;
>  }
> Index: linux/arch/ia64/mm/numa.c
> ===
> --- linux.orig/arch/ia64/mm/numa.c  2013-02-25 15:49:44.0 -0600
> +++ linux/arch/ia64/mm/numa.c   2013-03-22 16:09:44.662268239 -0500
> @@ -61,13 +61,26 @@ paddr_to_nid(unsigned long paddr)
>  int __meminit __early_pfn_to_nid(unsigned long pfn)
>  {
> int i, section = pfn >> PFN_SECTION_SHIFT, ssec, esec;
> +   /*
> +  NOTE: The following SMP-unsafe globals are only used early
> +  in boot when the kernel is running single-threaded.
> +   */
> +   static unsigned long last_start_pfn, last_end_pfn;

last_ssec, last_esec?


> +   static int last_nid;
> +
> +   if (section >= last_ssec && section < last_esec)
> +   return last_nid;
>
> for (i = 0; i < num_node_memblks; i++) {
> ssec = node_memblk[i].start_paddr >> PA_SECTION_SHIFT;
> esec = (node_memblk[i].start_paddr + node_memblk[i].size +
> ((1L << PA_SECTION_SHIFT) - 1)) >> PA_SECTION_SHIFT;
> -   if (section >= ssec && section < esec)
> +   if (section >= ssec && section < esec) {
> +   last_ssec = ssec;
> +   last_esec = esec;
> +   last_nid = node_memblk[i].nid
> return node_memblk[i].nid;
> +   }
> }
>
> return -1;
>

also looks like you forget to put IA maintainers in the To list.

may just put ia64 part in separated patch?

Thanks

Yinghai


memblock_search_pfn_nid.patch
Description: Binary data

Re: remap kernel static memory to user space

[Eduardo Cruz]

I'm adding some asm code in arch/ia64/kernel/ivt.S
to gather some memory usage statistics.

>From whatever reason, when I allocate the memory using
kmalloc/vmalloc, my assembly code cashes the machine when I load the
allocated memory.

If I use static allocated memory, the asm code works.

I know the problem is not the assembly code.

The problem is that I want to be able to read this data from user space.
Since the code performance critical, I don't want to do a
copy_to_user, I prefer to mmap this data into user space.

The problem is, if I use kmalloc/vmalloc, I managed to map the memory
to user space.
However, the asm interrupt handler crashs.

On the other hand, if I use static data, the asm interrupt handler
works, while the mmap fails.

Do you have any clues?

2013/3/22 Clemens Ladisch :
> Eduardo Cruz wrote:
>> Please, anyone knows how to solve this problem?
>>
>> 2013/3/20 Eduardo Cruz :
>>> I'm trying to remap some kernel static memory to user space using
>>> remap_pfn_range.
>
> Well, don't do that.
>
> What is the actual problem you're trying to solve?
>
>
> Regards,
> Clemens



-- 
Eduardo Henrique Molina da Cruz
PhD student
Parallel and Distributed Processing Group
Federal University of Rio Grande do Sul (UFRGS)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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.9-rc3+: reports battery as 0 mWh capacity on thinkpad x60

[Pavel Machek]

On Sat 2013-03-23 14:00:23, Bjørn Mork wrote:
> "Rafael J. Wysocki"  writes:
> > On Saturday, March 23, 2013 12:40:12 PM Pavel Machek wrote:
> >> Hi!
> >> 
> >> pavel@amd:~$ cat /proc/acpi/battery/BAT0/info 
> >> present: yes
> >> design capacity: 0 mWh
> >> last full capacity:  0 mWh
> >> battery technology:  rechargeable
> >> design voltage:  14400 mV
> >> 
> >> This worked before... at least it works in 2.6 kernel used by debian.
> >
> > This works for me in 3.9-rc3.  May I see your .config?
> 
> Well, if this works, then maybe the Kconfig help text should be updated:
> 
> config ACPI_PROCFS_POWER
> bool "Deprecated power /proc/acpi directories"
> depends on PROC_FS
> help
>   For backwards compatibility, this option allows
>   deprecated power /proc/acpi/ directories to exist, even when
>   they have been replaced by functions in /sys.
>   The deprecated directories (and their replacements) include:
>   /proc/acpi/battery/* (/sys/class/power_supply/*)
>   /proc/acpi/ac_adapter/* (sys/class/power_supply/*)
>   This option has no effect on /proc/acpi/ directories
>   and functions, which do not yet exist in /sys
>   This option, together with the proc directories, will be
>   deleted in 2.6.39.
> 
> 
> Time to call the bluff now :)

This should probably be "default y", BTW.

But problem is not in /proc, /sys has zeros, too.

pavel@amd:~$ cat /sys/class/power_supply/BAT0/energy_full
0
pavel@amd:~$ cat /sys/class/power_supply/BAT0/energy_full_design 
0
pavel@amd:~$ cat /sys/class/power_supply/BAT0/model_name 
93P5030
pavel@amd:~$ 


 Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] bnx2x: fix assignment of signed expression to unsigned variable

[Dan Carpenter]

On Sat, Mar 23, 2013 at 11:52:55AM -0700, Kumar Amit Mehta wrote:
> fix for incorrect assignment of signed expression to unsigned variable.
> 

This fix isn't right.

> Signed-off-by: Kumar Amit Mehta 
> ---
>  drivers/net/ethernet/broadcom/bnx2x/bnx2x_dcb.c |   20 ++--
>  1 file changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_dcb.c 
> b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_dcb.c
> index 5682054..b90533a 100644
> --- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_dcb.c
> +++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_dcb.c
> @@ -2139,12 +2139,12 @@ static u8 bnx2x_dcbnl_get_cap(struct net_device 
> *netdev, int capid, u8 *cap)
>   break;
>   default:
>   BNX2X_ERR("Non valid capability ID\n");
> - rval = -EINVAL;
> + rval = EINVAL;
>   break;
>   }
>   } else {
>   DP(BNX2X_MSG_DCB, "DCB disabled\n");
> - rval = -EINVAL;
> + rval = EINVAL;

This function is called from dcbnl_getcap().  It returns zero on
success, but it's not clear what it should return on failure.  But
certainly it's not a positive EINVAL.

>   }
>  
>   DP(BNX2X_MSG_DCB, "capid %d:%x\n", capid, *cap);
> @@ -2154,7 +2154,7 @@ static u8 bnx2x_dcbnl_get_cap(struct net_device 
> *netdev, int capid, u8 *cap)
>  static int bnx2x_dcbnl_get_numtcs(struct net_device *netdev, int tcid, u8 
> *num)
>  {
>   struct bnx2x *bp = netdev_priv(netdev);
> - u8 rval = 0;
> + s8 rval = 0;

Just use "int" here.

>  
>   DP(BNX2X_MSG_DCB, "tcid %d\n", tcid);
>  
> @@ -2188,7 +2188,7 @@ static int bnx2x_dcbnl_set_numtcs(struct net_device 
> *netdev, int tcid, u8 num)
>   return -EINVAL;
>  }
>  
> -static u8  bnx2x_dcbnl_get_pfc_state(struct net_device *netdev)
> +static u8 bnx2x_dcbnl_get_pfc_state(struct net_device *netdev)
>  {
>   struct bnx2x *bp = netdev_priv(netdev);
>   DP(BNX2X_MSG_DCB, "state = %d\n", bp->dcbx_local_feat.pfc.enabled);
> @@ -2282,7 +2282,7 @@ static int bnx2x_set_admin_app_up(struct bnx2x *bp, u8 
> idtype, u16 idval, u8 up)
>   else {
>   /* app table is full */
>   BNX2X_ERR("Application table is too large\n");
> - return -EBUSY;
> + return EBUSY;
>   }

The fix for this is more involved.  The function prototype should
be changed to return an int.  The caller should be updated to check
for errors.

Etc.

regards,
dan carpenter

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

Re: [PATCH 1/2] KMS: fix EDID detailed timing vsync parsing

[Torsten Duwe]

On Sat, 23 Mar 2013, Linus Torvalds wrote:

> How the heck did you get your *own* email address wrong in your mail
> headers? "tors...@lst.de" bounces, 

Of course I had to goof up somehow :(
This is not my everyday mail setup, the configuration is suboptimal, 
admittedly. Sorry for the inconvenience.

Torsten

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: ipc,sem: sysv semaphore scalability

[Linus Torvalds]

On Fri, Mar 22, 2013 at 8:19 PM, Emmanuel Benisty  wrote:
>
> I could reproduce it but could you please let me know what would be
> the right tools I should use to catch the original oops?
> This is what I got but I doubt it will be helpful:
> http://i.imgur.com/Mewi1hC.jpg

In this case, I think the best thing to do would be to comment out all
of drm_warn_on_modeset_not_all_locked(), because those warnings make
the original problem (that probably caused the lock problem in the
first place that it is warning about) scroll away.

That said, you should also take the oneliner fix that Rik posted to
patch 7 (subject line: "[PATCH 7/7 part3] fix for sem_lock") and apply
that, just to make sure that you aren't possibly hitting a bug with
the shared-memory locking introduced by that (unusual) case.

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

Re: [PATCH v2] wfcqueue: functions for local append and enqueue

[Mathieu Desnoyers]

* Eric Wong (normalper...@yhbt.net) wrote:
> With level-triggered epoll, append/enqueue operations to the
> local/locked queues increase performance by avoiding unnecessary atomic
> operations and barriers.  These are necessary to avoid performance
> regressions when looping through ep_send_events and appending many
> items to a local queue.
> 
> Signed-off-by: Eric Wong 
> Cc: Mathieu Desnoyers 
> Cc: Lai Jiangshan 
> Cc: Paul E. McKenney 
> Cc: Stephen Hemminger 
> Cc: Davide Libenzi 
> ---
>  I noticed the original __wfcq_append function was not in the
>  synchronization table, so I left out ___wfcq_append from the table
>  as well.
> 
>  include/linux/wfcqueue.h | 59 
> ++--
>  1 file changed, 52 insertions(+), 7 deletions(-)
> 
> diff --git a/include/linux/wfcqueue.h b/include/linux/wfcqueue.h
> index 9464a0c..800b1dd 100644
> --- a/include/linux/wfcqueue.h
> +++ b/include/linux/wfcqueue.h
> @@ -55,14 +55,16 @@
>   * [4] __wfcq_splice (source queue)
>   * [5] __wfcq_first
>   * [6] __wfcq_next
> + * [7] __wfcq_enqueue
>   *
> - * [1] [2] [3] [4] [5] [6]
> - * [1]  -   -   -   -   -   -
> - * [2]  -   -   -   -   -   -
> - * [3]  -   -   X   X   X   X
> - * [4]  -   -   X   -   X   X
> - * [5]  -   -   X   X   -   -
> - * [6]  -   -   X   X   -   -
> + * [1] [2] [3] [4] [5] [6] [7]
> + * [1]  -   -   -   -   -   -   X
> + * [2]  -   -   -   -   -   -   X
> + * [3]  -   -   X   X   X   X   X
> + * [4]  -   -   X   -   X   X   X
> + * [5]  -   -   X   X   -   -   X
> + * [6]  -   -   X   X   -   -   X
> + * [7]  X   X   X   X   X   X   X
>   *
>   * Besides locking, mutual exclusion of dequeue, splice and iteration
>   * can be ensured by performing all of those operations from a single
> @@ -205,6 +207,49 @@ static inline bool wfcq_enqueue(struct wfcq_head *head,
>  }
>  
>  /*
> + * ___wfcq_append: append one local queue to another local queue
> + *
> + * No memory barriers are issued.  Mutual exclusion is the responsibility
> + * of the caller.
> + *
> + * Returns false if the queue was empty prior to adding the node.
> + * Returns true otherwise.
> + */

__wfcq_append() and ___wfcq_append() are meant to be private to
wfcqueue.h. Therefore, the comment above should be removed, since it is
not part of the API.

I notice that I should have used ___wfcq_append() for the original
append function for consistency (other private helpers in this header
are prefixed with ___).

So maybe we should rename __wfcq_append to ___wfcq_append (making it
clear that it is a private helper), and introduce your helper as
___wfcq_append_local() (I don't care about having "local" in there since
it is not part of the exposed API).

> +static inline bool ___wfcq_append(struct wfcq_head *head,
> + struct wfcq_tail *tail,
> + struct wfcq_node *new_head,
> + struct wfcq_node *new_tail)
> +{
> + struct wfcq_node *old_tail;
> +
> + old_tail = tail->p;
> + tail->p = new_tail;
> + old_tail->next = new_head;
> +
> + /*
> +  * Return false if queue was empty prior to adding the node,
> +  * else return true.
> +  */
> + return old_tail != >node;
> +}
> +
> +/*
> + * __wfcq_enqueue: enqueue a node into a local queue

The concept of "local queue" is not clearly defined.

Perhaps it would be clearer to state:

 * __wfcq_enqueue: enqueue a node into a queue, requiring mutual exclusion.

Thoughts ?

Thanks,

Mathieu


> + *
> + * No memory barriers are issued.  Mutual exclusion is the responsibility
> + * of the caller.
> + *
> + * Returns false if the queue was empty prior to adding the node.
> + * Returns true otherwise.
> + */
> +static inline bool __wfcq_enqueue(struct wfcq_head *head,
> + struct wfcq_tail *tail,
> + struct wfcq_node *new_tail)
> +{
> + return ___wfcq_append(head, tail, new_tail, new_tail);
> +}
> +
> +/*
>   * ___wfcq_busy_wait: busy-wait.
>   */
>  static inline void ___wfcq_busy_wait(void)
> -- 
> 1.8.2.rc3.2.geae6cf5
> 

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

[PATCH] Fix IXP4xx coherent allocations

[Krzysztof Halasa]

ARM core code currently requires coherent DMA mask to be set. Make sure
we limit PCI devices to 64 MiB while allowing on-chip devices to access
the whole 4 GiB address space.

This fixes a v3.7+ regression which broke IXP4xx built-in network devices.

Signed-off-by: Krzysztof Hałasa 
Cc: 

diff --git a/arch/arm/mach-ixp4xx/common-pci.c 
b/arch/arm/mach-ixp4xx/common-pci.c
index ea1933d..8629fc9 100644
--- a/arch/arm/mach-ixp4xx/common-pci.c
+++ b/arch/arm/mach-ixp4xx/common-pci.c
@@ -454,10 +454,15 @@ int ixp4xx_setup(int nr, struct pci_sys_data *sys)
 
 int dma_set_coherent_mask(struct device *dev, u64 mask)
 {
-   if (mask >= SZ_64M - 1)
-   return 0;
+   if ((mask & DMA_BIT_MASK(26)) != DMA_BIT_MASK(26))
+   return -EIO;
+
+   /* PCI devices are limited to 64 MiB */
+   if (dev_is_pci(dev))
+   mask &= DMA_BIT_MASK(26); /* Use DMA region */
 
-   return -EIO;
+   dev->coherent_dma_mask = mask;
+   return 0;
 }
 
 EXPORT_SYMBOL(ixp4xx_pci_read);
diff --git a/drivers/net/ethernet/xscale/ixp4xx_eth.c 
b/drivers/net/ethernet/xscale/ixp4xx_eth.c
index 6958a5e..7c08269 100644
--- a/drivers/net/ethernet/xscale/ixp4xx_eth.c
+++ b/drivers/net/ethernet/xscale/ixp4xx_eth.c
@@ -1423,7 +1423,7 @@ static int eth_init_one(struct platform_device *pdev)
dev->netdev_ops = _netdev_ops;
dev->ethtool_ops = _ethtool_ops;
dev->tx_queue_len = 100;
-
+   dma_set_coherent_mask(>dev, DMA_BIT_MASK(32));
netif_napi_add(dev, >napi, eth_poll, NAPI_WEIGHT);
 
if (!(port->npe = npe_request(NPE_ID(port->id {
diff --git a/drivers/net/wan/ixp4xx_hss.c b/drivers/net/wan/ixp4xx_hss.c
index 95d0451..83b4597 100644
--- a/drivers/net/wan/ixp4xx_hss.c
+++ b/drivers/net/wan/ixp4xx_hss.c
@@ -1367,6 +1367,7 @@ static int hss_init_one(struct platform_device *pdev)
port->id = pdev->id;
port->dev = >dev;
port->plat = pdev->dev.platform_data;
+   dma_set_coherent_mask(>dev, DMA_BIT_MASK(32));
netif_napi_add(dev, >napi, hss_hdlc_poll, NAPI_WEIGHT);
 
if ((err = register_hdlc_device(dev)))
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 1/8] staging: zcache: introduce zero-filled pages handler

[Geert Uytterhoeven]

On Tue, Mar 19, 2013 at 10:25 AM, Wanpeng Li  wrote:
> Introduce zero-filled pages handler to capture and handle zero pages.
>
> Acked-by: Dan Magenheimer 
> Signed-off-by: Wanpeng Li 
> ---
>  drivers/staging/zcache/zcache-main.c |   26 ++
>  1 files changed, 26 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/staging/zcache/zcache-main.c 
> b/drivers/staging/zcache/zcache-main.c
> index 328898e..d73dd4b 100644
> --- a/drivers/staging/zcache/zcache-main.c
> +++ b/drivers/staging/zcache/zcache-main.c

> +static void handle_zero_filled_page(void *page)
> +{
> +   void *user_mem;
> +
> +   user_mem = kmap_atomic(page);

kmap_atomic() takes a "struct page *", not a "void *".

> +   memset(user_mem, 0, PAGE_SIZE);
> +   kunmap_atomic(user_mem);
> +
> +   flush_dcache_page(page);

While flush_dcache_page() is a no-op on many architectures, it also
takes a "struct page *", not a "void *":

m68k/allmodconfig:

drivers/staging/zcache/zcache-main.c:309:2: error: request for member
'virtual' in something not a structure or union

Cfr. http://kisskb.ellerman.id.au/kisskb/buildresult/8433711/

> +}

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ACPI: Set length even for TYPE_END_TAG acpi resource

[Yinghai Lu]

Found with pm/linux-next, network device in QEMU/KVM guest does not
work anymore.

Bisected to commit c13085e5
ACPICA: Resource Mgr: Prevent infinite loops in resource walks

That commit will check acpi_resource length strictly.
it cause acpi_set_current_resources return failure and irq for pci device
is not set properly.

Set length for all those TYPE_END_TAG acpi_resources.

Bisected-by: Yinghai Lu 
Signed-off-by: Yinghai Lu 
Cc: Mattia Dongili 
Cc: Matthew Garrett 
Cc: Adam Belay 
Cc: Bjorn Helgaas 
Cc: platform-driver-...@vger.kernel.org

---
 drivers/acpi/pci_link.c|1 +
 drivers/platform/x86/sony-laptop.c |3 ++-
 drivers/pnp/pnpacpi/rsparser.c |1 +
 3 files changed, 4 insertions(+), 1 deletion(-)

Index: linux-2.6/drivers/acpi/pci_link.c
===
--- linux-2.6.orig/drivers/acpi/pci_link.c
+++ linux-2.6/drivers/acpi/pci_link.c
@@ -354,6 +354,7 @@ static int acpi_pci_link_set(struct acpi
 
}
resource->end.type = ACPI_RESOURCE_TYPE_END_TAG;
+   resource->end.length = sizeof(struct acpi_resource);
 
/* Attempt to set the resource */
status = acpi_set_current_resources(link->device->handle, );
Index: linux-2.6/drivers/platform/x86/sony-laptop.c
===
--- linux-2.6.orig/drivers/platform/x86/sony-laptop.c
+++ linux-2.6/drivers/platform/x86/sony-laptop.c
@@ -4121,7 +4121,7 @@ static int sony_pic_enable(struct acpi_d
resource->res3.data.irq.sharable = ACPI_SHARED;
 
resource->res4.type = ACPI_RESOURCE_TYPE_END_TAG;
-
+   resource->res4.length = sizeof(struct acpi_resource);
}
/* setup Type 2/3 resources */
else {
@@ -4140,6 +4140,7 @@ static int sony_pic_enable(struct acpi_d
resource->res2.data.irq.sharable = ACPI_SHARED;
 
resource->res3.type = ACPI_RESOURCE_TYPE_END_TAG;
+   resource->res3.length = sizeof(struct acpi_resource);
}
 
/* Attempt to set the resource */
Index: linux-2.6/drivers/pnp/pnpacpi/rsparser.c
===
--- linux-2.6.orig/drivers/pnp/pnpacpi/rsparser.c
+++ linux-2.6/drivers/pnp/pnpacpi/rsparser.c
@@ -634,6 +634,7 @@ int pnpacpi_build_resource_template(stru
}
/* resource will pointer the end resource now */
resource->type = ACPI_RESOURCE_TYPE_END_TAG;
+   resource->length = sizeof(struct acpi_resource);
 
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/

[PATCH v2] wfcqueue: functions for local append and enqueue

[Eric Wong]

With level-triggered epoll, append/enqueue operations to the
local/locked queues increase performance by avoiding unnecessary atomic
operations and barriers.  These are necessary to avoid performance
regressions when looping through ep_send_events and appending many
items to a local queue.

Signed-off-by: Eric Wong 
Cc: Mathieu Desnoyers 
Cc: Lai Jiangshan 
Cc: Paul E. McKenney 
Cc: Stephen Hemminger 
Cc: Davide Libenzi 
---
 I noticed the original __wfcq_append function was not in the
 synchronization table, so I left out ___wfcq_append from the table
 as well.

 include/linux/wfcqueue.h | 59 ++--
 1 file changed, 52 insertions(+), 7 deletions(-)

diff --git a/include/linux/wfcqueue.h b/include/linux/wfcqueue.h
index 9464a0c..800b1dd 100644
--- a/include/linux/wfcqueue.h
+++ b/include/linux/wfcqueue.h
@@ -55,14 +55,16 @@
  * [4] __wfcq_splice (source queue)
  * [5] __wfcq_first
  * [6] __wfcq_next
+ * [7] __wfcq_enqueue
  *
- * [1] [2] [3] [4] [5] [6]
- * [1]  -   -   -   -   -   -
- * [2]  -   -   -   -   -   -
- * [3]  -   -   X   X   X   X
- * [4]  -   -   X   -   X   X
- * [5]  -   -   X   X   -   -
- * [6]  -   -   X   X   -   -
+ * [1] [2] [3] [4] [5] [6] [7]
+ * [1]  -   -   -   -   -   -   X
+ * [2]  -   -   -   -   -   -   X
+ * [3]  -   -   X   X   X   X   X
+ * [4]  -   -   X   -   X   X   X
+ * [5]  -   -   X   X   -   -   X
+ * [6]  -   -   X   X   -   -   X
+ * [7]  X   X   X   X   X   X   X
  *
  * Besides locking, mutual exclusion of dequeue, splice and iteration
  * can be ensured by performing all of those operations from a single
@@ -205,6 +207,49 @@ static inline bool wfcq_enqueue(struct wfcq_head *head,
 }
 
 /*
+ * ___wfcq_append: append one local queue to another local queue
+ *
+ * No memory barriers are issued.  Mutual exclusion is the responsibility
+ * of the caller.
+ *
+ * Returns false if the queue was empty prior to adding the node.
+ * Returns true otherwise.
+ */
+static inline bool ___wfcq_append(struct wfcq_head *head,
+   struct wfcq_tail *tail,
+   struct wfcq_node *new_head,
+   struct wfcq_node *new_tail)
+{
+   struct wfcq_node *old_tail;
+
+   old_tail = tail->p;
+   tail->p = new_tail;
+   old_tail->next = new_head;
+
+   /*
+* Return false if queue was empty prior to adding the node,
+* else return true.
+*/
+   return old_tail != >node;
+}
+
+/*
+ * __wfcq_enqueue: enqueue a node into a local queue
+ *
+ * No memory barriers are issued.  Mutual exclusion is the responsibility
+ * of the caller.
+ *
+ * Returns false if the queue was empty prior to adding the node.
+ * Returns true otherwise.
+ */
+static inline bool __wfcq_enqueue(struct wfcq_head *head,
+   struct wfcq_tail *tail,
+   struct wfcq_node *new_tail)
+{
+   return ___wfcq_append(head, tail, new_tail, new_tail);
+}
+
+/*
  * ___wfcq_busy_wait: busy-wait.
  */
 static inline void ___wfcq_busy_wait(void)
-- 
1.8.2.rc3.2.geae6cf5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] bnx2x: fix assignment of signed expression to unsigned variable

[Kumar Amit Mehta]

fix for incorrect assignment of signed expression to unsigned variable.

Signed-off-by: Kumar Amit Mehta 
---
 drivers/net/ethernet/broadcom/bnx2x/bnx2x_dcb.c |   20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_dcb.c 
b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_dcb.c
index 5682054..b90533a 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_dcb.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_dcb.c
@@ -2139,12 +2139,12 @@ static u8 bnx2x_dcbnl_get_cap(struct net_device 
*netdev, int capid, u8 *cap)
break;
default:
BNX2X_ERR("Non valid capability ID\n");
-   rval = -EINVAL;
+   rval = EINVAL;
break;
}
} else {
DP(BNX2X_MSG_DCB, "DCB disabled\n");
-   rval = -EINVAL;
+   rval = EINVAL;
}
 
DP(BNX2X_MSG_DCB, "capid %d:%x\n", capid, *cap);
@@ -2154,7 +2154,7 @@ static u8 bnx2x_dcbnl_get_cap(struct net_device *netdev, 
int capid, u8 *cap)
 static int bnx2x_dcbnl_get_numtcs(struct net_device *netdev, int tcid, u8 *num)
 {
struct bnx2x *bp = netdev_priv(netdev);
-   u8 rval = 0;
+   s8 rval = 0;
 
DP(BNX2X_MSG_DCB, "tcid %d\n", tcid);
 
@@ -2188,7 +2188,7 @@ static int bnx2x_dcbnl_set_numtcs(struct net_device 
*netdev, int tcid, u8 num)
return -EINVAL;
 }
 
-static u8  bnx2x_dcbnl_get_pfc_state(struct net_device *netdev)
+static u8 bnx2x_dcbnl_get_pfc_state(struct net_device *netdev)
 {
struct bnx2x *bp = netdev_priv(netdev);
DP(BNX2X_MSG_DCB, "state = %d\n", bp->dcbx_local_feat.pfc.enabled);
@@ -2282,7 +2282,7 @@ static int bnx2x_set_admin_app_up(struct bnx2x *bp, u8 
idtype, u16 idval, u8 up)
else {
/* app table is full */
BNX2X_ERR("Application table is too large\n");
-   return -EBUSY;
+   return EBUSY;
}
 
/* up configured, if not 0 make sure feature is enabled */
@@ -2312,7 +2312,7 @@ static u8 bnx2x_dcbnl_set_app_up(struct net_device 
*netdev, u8 idtype,
break;
default:
DP(BNX2X_MSG_DCB, "Wrong ID type\n");
-   return -EINVAL;
+   return EINVAL;
}
return bnx2x_set_admin_app_up(bp, idtype, idval, up);
 }
@@ -2390,12 +2390,12 @@ static u8 bnx2x_dcbnl_get_featcfg(struct net_device 
*netdev, int featid,
break;
default:
BNX2X_ERR("Non valid featrue-ID\n");
-   rval = -EINVAL;
+   rval = EINVAL;
break;
}
} else {
DP(BNX2X_MSG_DCB, "DCB disabled\n");
-   rval = -EINVAL;
+   rval = EINVAL;
}
 
return rval;
@@ -2431,12 +2431,12 @@ static u8 bnx2x_dcbnl_set_featcfg(struct net_device 
*netdev, int featid,
break;
default:
BNX2X_ERR("Non valid featrue-ID\n");
-   rval = -EINVAL;
+   rval = EINVAL;
break;
}
} else {
DP(BNX2X_MSG_DCB, "dcbnl call not valid\n");
-   rval = -EINVAL;
+   rval = EINVAL;
}
 
return rval;
-- 
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/

kernel version 3.8.4 crashed while fuzzying with trinity

[Toralf Förster]

That kernel crashed today at a stable 32 bit Gentoo Linux.
The screen shot (just a photo, b/c nothing was in the syslog) can be downloaded 
here [1].

The last action before I left the machine for a while was to start a user mode 
linux
(stale 32 bit Gentoo, kernel v3.9-rc3-324-g5da273) and run trinity within that 
system.

Please note that the host kernel crashed (UML probably too).

To feed trinity with victim files I NFSv4 mounted a directory located at the 
host system
under /tmp onto a mount point of the UML system (all file systems are EXT4).
That directory contained 100 files and 100 directory.
The trinity command line I used in the UML was :

$> trinity --children 4 --victims /mnt/nfs/n22/forT -x mremap -x clock_nanosleep

FWIW :  mremap gives within an UML guest with kernel 3.9-rcX this [2] using SLAB
and with SLUB this [3];
clock_nanosleep only slows down the tests

[1] http://ompldr.org/vaHV6YQ
[2] http://thread.gmane.org/gmane.linux.kernel/1462272
[3] 
http://sourceforge.net/mailarchive/forum.php?thread_name=5140E36D.2080606%40gmx.de_name=user-mode-linux-user

-- 
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/4] uprobes: add trap variant helper

[Oleg Nesterov]

On 03/22, Ananth N Mavinakayanahalli wrote:
>
> Some architectures like powerpc have multiple variants of the trap
> instruction. Introduce an additional helper is_trap_insn() for run-time
> handling of non-uprobe traps on such architectures.

Looks fine to me.

I am going to take this into my tree, hopefully Ben won't object. The
main change is arch-agnostic and the changes in arch/powerpc are trivial.

Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/7] uretprobes: return probes implementation

[Oleg Nesterov]

On 03/23, Anton Arapov wrote:
>
>   IIUC, Oleg have stressed that perf and trace events requires
> additional code to leverage the return probes. IOW this patchset
> implements core only and to use it we need to teach the perf about
> rp_handler().

Yes,

>   And I don't see why we would need additional parameter for
> rp_handler() as well.

trace_uprobe should use the same fmt = "(%lx <- %lx)" to teport
"entry <- exit" info, like trace_kprobe does.

And note that, unlike kprobe, the same function can be mmapped at
different address by different (or even the same) tasks.



But mostly I just wanted to say that yes, we will also teach
trace_uprobe to use the new feature before we ask to merge this
code.

Oleg.

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

Re: RFC: Kernel lock elision for TSX

[Andi Kleen]

On Sat, Mar 23, 2013 at 07:00:10PM +0100, Andi Kleen wrote:
> 
> Hi Linux,

Also I debut on finally making that famous typo too. Sorry.

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

Re: [PATCH 12/29] x86, tsx: Add a per thread transaction disable count

[Andi Kleen]

> That said, making it just a byte sounds more than enough. How deep
> would anybody want to nest it? Do we care?

Byte should be fine. I'll change that.

-Andi

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

Re: [PATCH 0/7] uretprobes: return probes implementation

[Oleg Nesterov]

On 03/22, Josh Stone wrote:
>
> On 03/22/2013 08:10 AM, Oleg Nesterov wrote:
> > This looks simple, but probably we need to add the additional "ulong 
> > bp_vaddr"
> > argument for rp_handler().
>
> FWIW, in SystemTap we don't currently do anything that would need
> bp_vaddr.

I know. This is not for systemtap.

> The uprobe_consumer already gives the context, so I'm not
> sure what else you would do with the *entry* address of the function
> that just returned.

context - yes, but not address (by the time ret_handler is called).

Oleg.

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

Re: RFC: Kernel lock elision for TSX

[Andi Kleen]

Hi Linux,

Thanks.  Other code/design review would be still appreciated, even
under the current constraints.

> The other comment I have is that since it does touch non-x86 header
> files etc (although not a lot), you really need to talk to the POWER8
> people about naming of the thing. Calling it  and having
> "generic" helpers called _xtest() used by the generic spinlock code
> sounds a bit suspect.

I can make up another name for _xtest()/_xabort() and linux/rtm.h,
(any suggestions?)

The basic concepts implemented there should be pretty universal.
If others have a equivalent of "is this a transaction" and "abort
this tranction" they can just plug it in. Otherwise they will nop it,
as it's only hints anyways.

The only things used outside x86 code is _xtest()/_xabort(), can
remove the rest from linux/*. Without transactions this is all nops.
The primary interface for the lock code is the much higher level
elide()/elide_lock_adapt() interface anyways.

-Andi

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

clk: x86: build failure

[Corey Richardson]

With the attached config, I get the following build failure:

  LD  init/built-in.o
drivers/built-in.o:clk-lpt.c:function v4l2_device_unregister: error:
undefined reference to 'i2c_unregister_device'

This is after a make oldconfig, perhaps a missed dependency in Kconfig?


config-napo.gz
Description: GNU Zip compressed data

Re: [PATCH 1/2] KMS: fix EDID detailed timing vsync parsing

[Linus Torvalds]

How the heck did you get your *own* email address wrong in your mail
headers? "tors...@lst.de" bounces, apparently your email address is
"d...@lst.org". Let's see if that bounces..

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

Re: [PATCH 4/7] uretprobes: return probe entry, prepare_uretprobe()

[Oleg Nesterov]

On 03/22, Anton Arapov wrote:
>
> @@ -1513,20 +1596,26 @@ static void handler_chain(struct uprobe *uprobe, 
> struct pt_regs *regs)
>  {
>   struct uprobe_consumer *uc;
>   int remove = UPROBE_HANDLER_REMOVE;
> + bool prep = false; /* prepare return uprobe, when needed */
>   int rc = 0;
>  
>   down_read(>register_rwsem);
>   for (uc = uprobe->consumers; uc; uc = uc->next) {
>   if (uc->handler)
>   rc = uc->handler(uc, regs);
> - else
> + else {
> + prep |= true;
>   remove = 0;
> + }

This looks wrong (see also my reply to 1/7).

What if uc->handler != NULL and uc->ret_handler != NULL ? We need

if (uc->rer_handler)
need_prep = true;

Oleg.

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

Re: [PATCH 1/2] KMS: fix EDID detailed timing vsync parsing

[Linus Torvalds]

On Sat, Mar 23, 2013 at 7:38 AM, Torsten Duwe  wrote:
>
> EDID spreads some values across multiple bytes; bit-fiddling is needed
> to retrieve these. The current code to parse "detailed timings" has a
> cut error that results in a vsync offset of at most 15 lines
> instead of 63.

Yeah, it clearly just mixes the bits together with that bitwise rather
than actually spreading them out correctly.

Applied.

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

Re: [PATCH 1/7] uretprobes: preparation patch

[Oleg Nesterov]

On 03/22, Anton Arapov wrote:
>
> @@ -1488,10 +1496,14 @@ static void handler_chain(struct uprobe *uprobe, 
> struct pt_regs *regs)
>  {
>   struct uprobe_consumer *uc;
>   int remove = UPROBE_HANDLER_REMOVE;
> + int rc = 0;
>  
>   down_read(>register_rwsem);
>   for (uc = uprobe->consumers; uc; uc = uc->next) {
> - int rc = uc->handler(uc, regs);
> + if (uc->handler)
> + rc = uc->handler(uc, regs);
> + else
> + remove = 0;

Well, this doesn't look good. Yes, we need to conditionalize uc->handler()
and rc checks, but the code looks ugly. We touch remove twice, and the value
of rc inside the loop is bogus if ->handler == NULL.

I wouldn't have argued, but, but 4/7 changes the "else" branch and this change
is wrong (I'll write another email). We do not need this "else" at all.

I'd suggest the patch below.

Oleg.

--- x/kernel/events/uprobes.c
+++ x/kernel/events/uprobes.c
@@ -1491,10 +1491,13 @@ static void handler_chain(struct uprobe 
 
down_read(>register_rwsem);
for (uc = uprobe->consumers; uc; uc = uc->next) {
-   int rc = uc->handler(uc, regs);
+   int rc = 0;
 
-   WARN(rc & ~UPROBE_HANDLER_MASK,
-   "bad rc=0x%x from %pf()\n", rc, uc->handler);
+   if (uc->handler) {
+   rc = uc->handler(uc, regs);
+   WARN(rc & ~UPROBE_HANDLER_MASK,
+   "bad rc=0x%x from %pf()\n", rc, uc->handler);
+   }
remove &= rc;
}
 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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.3 build error, compiler segfault

[Gene Heskett]

Greetings all;

Trying to build a working 3.8.3 kernel, on a *buntu 10.04-4 LTS system here

My usual 'makeit' script didn't report any errors at the end, but the end 
trace on screen was obviously incomplete.

Adding a few more echo's to the script, and verifying that every line in it 
was terminated with " && \\r"  I reran it, and see an error that should 
have stopped it right there, but did not:
==
  CC  net/ipv6/icmp.o
net/ipv4/icmp.c:1115: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[2]: *** [net/ipv4/icmp.o] Error 1
make[1]: *** [net/ipv4] Error 2
make[1]: *** Waiting for unfinished jobs
  CC  drivers/md/bitmap.o
===
as can be seen it kept marching, the error never made it to bash.

Much later in the screen trace:
===
  LD  net/ipv6/built-in.o
make: *** [net] Error 2
make: *** Waiting for unfinished jobs
  CC  drivers/of/of_mdio.o


And eventually the screen trace ends with the report from the 'time -p'
from the invocation "time -p ./makeit"

I am using ccache, and cc -v says:
gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5.1) 

My major problem in trying to build a newer kernel that the 2.6.32-122-43-
rtai currently running is that at least 50% of the time I run a make 
xconfig, the resultant .config saved has had the ext4 support, which this / 
partition is, has been removed, so the boot fails with the can't find the 
blkid of this partition error message.

Obviously I have more than one error, so how should I proceed?

The system is completely up to date for a 10.04-4 LTS install as of 2 or 3 
hours ago.

Thank you.

Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
My web page:  is up!
My views 

Our swords shall play the orators for us.
-- Christopher Marlowe
I was taught to respect my elders, but its getting 
harder and harder to find any...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [-next] fs/eventpoll.c:545 suspicious rcu_dereference_check() usage

[Eric Wong]

Sergey Senozhatsky  wrote:
> [3.163894] ===
> [3.163895] [ INFO: suspicious RCU usage. ]
> [3.163897] 3.9.0-rc3-next-20130322-dbg-dirty #1 Not tainted
> [3.163898] ---
> [3.163900] fs/eventpoll.c:545 suspicious rcu_dereference_check() usage!

Sorry about this, I've fixed this and it is in the latest -mm

http://mid.gmane.org/20130321192748.6d86f31c...@corp2gmr1-1.hot.corp.google.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ARM: Kirkwood: fix unused mvsdio gpio pins

[Sebastian Hesselbarth]

On 03/23/2013 05:30 PM, Thomas Petazzoni wrote:

Dear Sebastian Hesselbarth,

On Sat, 23 Mar 2013 16:25:54 +0100, Sebastian Hesselbarth wrote:


I understand that you proposed patch fixes mvsdio grab mpp0 by accident.
But what if you have a kirkwood board where cd-gpio _is_ connected to mpp0?


It didn't work with the existing mvsdio driver, so the purpose of my
patch was merely to restore the old behavior, in order to avoid having
to change all the instances of mvsdio_platform_data, knowing that those
would anyway go away as we convert boards to the Device Tree.


Thomas,

I agree both approaches fix the same issue. I haven't seen your patch
earlier and was just proposing a patch for the same issue. You or Jason
are free to choose whatever patch you like.


Not that there is one I know of, but IMHO the only useful patch is to
set passed values to an invalid gpio number.


To me, it remains a fragile way of doing things. Let's say tomorrow you
add a new "int foo_gpio" field in mvsdio_platform_data. The whole
purpose of C99 struct initializers is that you don't have to change all
instances of the structure because all fields that are not initialized
with .  =  are guaranteed to be zero. If you need to set
foo_gpio to -1 everywhere when you add this field, it becomes quite
annoying.


I understand that struct initialization with zero is done for a purpose.
But gpio = 0 is a valid gpio number and engineers will always count from
zero ;)

Given the fact that .gpio = 0 is valid, you would have to add some
.really_use_that_number_i_was_too_lazy_to_set = 1.. but mvsdio_plaform_data
won't stay long as you already pointed out, and I am happy with any fix
for the issue.


That said, I have nothing against explicitly setting those GPIO values
to an invalid value. Maybe -EINVAL would make more sense than just -1 ?


Every invalid gpio number will be sufficient. But -EINVAL doesn't make
more sense than -1 does. Having no cd-gpio is not an "Invalid argument".


It's just that I've seen -EINVAL being used on some other platforms, at
least mach-at91/, but I agree it's not an invalid argument per se.


If you don't like -1, you can choose -ENOENT. But -1 has been used for ages
as "invalid" or "unused" so it was my first guess.

Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 12/29] x86, tsx: Add a per thread transaction disable count

[Borislav Petkov]

On Sat, Mar 23, 2013 at 10:16:28AM -0700, Linus Torvalds wrote:
> On Sat, Mar 23, 2013 at 8:52 AM, Borislav Petkov  wrote:
> >
> > Really? Let's see:
> 
> Your test seems to assume that a single bit is sufficient, which
> sounds unlikely. If you have any kind of nesting going on, you need
> more than one bit. Then add/sub isn't a single "xor" of a bit any
> more.

Right, but does nesting even apply here? I mean, AFAICR the commit
message, we're talking about per-thread transaction disabling. IOW, this
is an on/off button used in a boolean context.

Or is this going to be used as a mechanism to tisable TSX when max
nesting level has been reached?

Hmmm.

Btw, the disable/reenable_txn() aren't used anywhere in the patchset and
I'd actually like to get an idea where/how those are used.

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/

[PATCH] firewire: Fix 'failed to read phy reg' on FW643 rev8

[Peter Hurley]

With the LSI FW643 rev 8 [1], the first commanded bus reset at
the conclusion of ohci_enable() has been observed to fail with
the following messages:

[4.884015] firewire_ohci :01:00.0: failed to read phy reg

[5.684012] firewire_ohci :01:00.0: failed to read phy reg

With drivers/firewire/ohci.c instrumented, the error condition [2]
indicates the PHY arbitration state machine has timed out prior to
enabling PHY LCtrl.

Clear the PHY arbitration timeout condition prior to enabling LCtrl.

NB: The problem appears to be timing-related as well, since clearing
the timeout status before configure_1394a_enhancements() has no effect.

[1]  lspci -v

01:00.0 FireWire (IEEE 1394): LSI Corporation FW643 [TrueFire] PCIe 1394b 
Controller (rev 08) (prog-if 10 [OHCI])
Subsystem: LSI Corporation FW643 [TrueFire] PCIe 1394b Controller
Flags: bus master, fast devsel, latency 0, IRQ 92
Memory at fbeff000 (64-bit, non-prefetchable) [size=4K]
Capabilities: [44] Power Management version 3
Capabilities: [4c] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [60] Express Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Virtual Channel
Capabilities: [170] Device Serial Number 08-14-43-82-00-00-41-fc
Kernel driver in use: firewire_ohci
Kernel modules: firewire-ohci

[2] instrumented WARNING in read_phy_reg()

[4.576010] [ cut here ]
[4.576035] WARNING: at ./drivers/firewire/ohci.c:570 read_phy_reg+0x93/0xe0 
[firewire_ohci]()
[4.576050] Hardware name: Precision WorkStation T5400
[4.576058] failed to read phy reg:1 (phy(5) @ config enhance:19)
[4.576068] Modules linked in: hid_logitech_dj hid_generic(+) usbhid 
<...snip...>
[4.576140] Pid: 61, comm: kworker/2:1 Not tainted 3.8.0-2+fwtest-xeon 
#2+fwtest
[4.576149] Call Trace:
[4.576160]  [] warn_slowpath_common+0x7f/0xc0
[4.576168]  [] warn_slowpath_fmt+0x46/0x50
[4.576178]  [] read_phy_reg+0x93/0xe0 [firewire_ohci]
[4.576188]  [] ohci_read_phy_reg+0x39/0x60 [firewire_ohci]
[4.576203]  [] fw_send_phy_config+0xbf/0xe0 
[firewire_core]
[4.576214]  [] br_work+0x46/0xb0 [firewire_core]
[4.576225]  [] process_one_work+0x13c/0x500
[4.576238]  [] ? fw_card_initialize+0x180/0x180 
[firewire_core]
[4.576248]  [] worker_thread+0x16d/0x470
[4.576257]  [] ? busy_worker_rebind_fn+0x100/0x100
[4.576266]  [] kthread+0xc0/0xd0
[4.576275]  [] ? pcpu_dump_alloc_info+0x1cb/0x2c4
[4.576284]  [] ? kthread_create_on_node+0x130/0x130
[4.576297]  [] ret_from_fork+0x7c/0xb0
[4.576305]  [] ? kthread_create_on_node+0x130/0x130
[4.576313] ---[ end trace cbc940994b300302 ]---

Reported-by: Tim Jordan 
Signed-off-by: Peter Hurley 
---
 drivers/firewire/core.h | 1 +
 drivers/firewire/ohci.c | 7 ---
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/firewire/core.h b/drivers/firewire/core.h
index 515a42c..9c69848 100644
--- a/drivers/firewire/core.h
+++ b/drivers/firewire/core.h
@@ -38,6 +38,7 @@ void fw_notice(const struct fw_card *card, const char *fmt, 
...);
 #define PHY_EXTENDED_REGISTERS 0xe0
 #define PHY_BUS_SHORT_RESET0x40
 #define PHY_INT_STATUS_BITS0x3c
+#define PHY_ARB_TIMEOUT0x08
 #define PHY_ENABLE_ACCEL   0x02
 #define PHY_ENABLE_MULTI   0x01
 #define PHY_PAGE_SELECT0xe0
diff --git a/drivers/firewire/ohci.c b/drivers/firewire/ohci.c
index 6ce6e07..371fb74 100644
--- a/drivers/firewire/ohci.c
+++ b/drivers/firewire/ohci.c
@@ -2195,13 +2195,14 @@ static int configure_1394a_enhancements(struct fw_ohci 
*ohci)
if (ohci->quirks & QUIRK_NO_1394A)
enable_1394a = false;
 
-   /* Configure PHY and link consistently. */
+   /* Configure PHY and link consistently and reset the
+* PHY arbitration timeout status */
if (enable_1394a) {
clear = 0;
-   set = PHY_ENABLE_ACCEL | PHY_ENABLE_MULTI;
+   set = PHY_ENABLE_ACCEL | PHY_ENABLE_MULTI | PHY_ARB_TIMEOUT;
} else {
clear = PHY_ENABLE_ACCEL | PHY_ENABLE_MULTI;
-   set = 0;
+   set = PHY_ARB_TIMEOUT;
}
ret = update_phy_reg(ohci, 5, clear, set);
if (ret < 0)
-- 
1.8.1.2

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

[PATCH] gitignore: ignore hz.bc

[Vincent]

Signed-off-by: Vincent Stehlé 
---
 kernel/.gitignore |1 +
 1 file changed, 1 insertion(+)

diff --git a/kernel/.gitignore b/kernel/.gitignore
index ab4f109..b3097bd 100644
--- a/kernel/.gitignore
+++ b/kernel/.gitignore
@@ -4,3 +4,4 @@
 config_data.h
 config_data.gz
 timeconst.h
+hz.bc
-- 
1.7.10.4

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

Re: [PATCH 12/29] x86, tsx: Add a per thread transaction disable count

[Linus Torvalds]

On Sat, Mar 23, 2013 at 8:52 AM, Borislav Petkov  wrote:
>
> Really? Let's see:

Your test seems to assume that a single bit is sufficient, which
sounds unlikely. If you have any kind of nesting going on, you need
more than one bit. Then add/sub isn't a single "xor" of a bit any
more.

That said, making it just a byte sounds more than enough. How deep
would anybody want to nest it? Do we care?

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

Re: RFC: Kernel lock elision for TSX

[Linus Torvalds]

On Fri, Mar 22, 2013 at 6:24 PM, Andi Kleen  wrote:
>
> Some questions and answers:
>
> - How much does it improve performance?
> I cannot share any performance numbers at this point unfortunately.
> Also please keep in mind that the tuning is very preliminary and
> will be revised.

Quite frankly, since the *only* reason for RTM is performance, this
fundamentally makes the patch-set pointless.

If we don't know how much it helps, we can't judge whether it's worth
even discussing this patch. It adds enough complexity that it had
better be worth it, and without knowing the performance side, all we
can see are the negatives.

Talk to your managers about this. Tell them that without performance
numbers, any patch-series like this is totally pointless.

Does it make non-contended code slower? We don't know. Does it improve
anything but micro-benchmarks? We don't know. Is there any point to
this? WE DON"T KNOW.

Inside of intel, it might be useful for testing and validating the
hardware. Outside of intel, it is totally useless without performance
numbers.

The other comment I have is that since it does touch non-x86 header
files etc (although not a lot), you really need to talk to the POWER8
people about naming of the thing. Calling it  and having
"generic" helpers called _xtest() used by the generic spinlock code
sounds a bit suspect.

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

Re: [GIT PULL] (xen) stable/for-linus-3.9-rc3-tag

[Stefano Stabellini]

On Fri, 22 Mar 2013, Konrad Rzeszutek Wilk wrote:
> Hey Linus,
> 
> Please git pull the following tag:
> 
>  git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git 
> stable/for-linus-3.9-rc3-tag
> 
> which is full of fixes. The signed tag has the details (as always) but
> this is mostly just the last stragglers of the regression bugs that this
> merge window had. There are also two normal bug-fixes in the lot.
> 
> P.S.
> We are working out the kinks in an early warning #linux-next testing framework
> so that it can give us heads up in the future - so the when the next merge
> window opens we shouldn't have surprises.
> 
> Please pull!
> 
>  arch/x86/include/asm/xen/hypercall.h |  4 +--
>  arch/x86/xen/mmu.c   |  3 +-
>  drivers/xen/Kconfig  |  2 +-
>  drivers/xen/events.c | 10 +++---
>  drivers/xen/fallback.c   |  3 +-
>  drivers/xen/xen-acpi-processor.c |  3 ++
>  drivers/xen/xen-pciback/pci_stub.c   | 59 
> +++-
>  include/xen/interface/physdev.h  |  6 
>  8 files changed, 64 insertions(+), 26 deletions(-)
> 
> David Vrabel (1):
>   xen/events: avoid race with raising an event in unmask_evtchn()

Unless I am looking in the wrong place, this patch is still the same one
that breaks PV on HVM and Xen ARM guests, see:

http://marc.info/?l=xen-devel=136377731913034

David is aware of the issue and I think is working on an alternative
fix.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] init: raise log level

[Richard Weinberger]

If the kernel was booted with the "quiet" boot option we have currently no
chance to see why an initrd failes.
Change KERN_WARNING to KERN_ERR to see what is going on.

Signed-off-by: Richard Weinberger 
---
 init/main.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/init/main.c b/init/main.c
index 63534a1..1d63387 100644
--- a/init/main.c
+++ b/init/main.c
@@ -832,7 +832,7 @@ static int __ref kernel_init(void *unused)
if (ramdisk_execute_command) {
if (!run_init_process(ramdisk_execute_command))
return 0;
-   printk(KERN_WARNING "Failed to execute %s\n",
+   printk(KERN_ERR "Failed to execute %s\n",
ramdisk_execute_command);
}
 
@@ -845,7 +845,7 @@ static int __ref kernel_init(void *unused)
if (execute_command) {
if (!run_init_process(execute_command))
return 0;
-   printk(KERN_WARNING "Failed to execute %s.  Attempting "
+   printk(KERN_ERR "Failed to execute %s.  Attempting "
"defaults...\n", execute_command);
}
if (!run_init_process("/sbin/init") ||
@@ -891,7 +891,7 @@ static noinline void __init kernel_init_freeable(void)
 
/* Open the /dev/console on the rootfs, this should never fail */
if (sys_open((const char __user *) "/dev/console", O_RDWR, 0) < 0)
-   printk(KERN_WARNING "Warning: unable to open an initial 
console.\n");
+   printk(KERN_ERR "Warning: unable to open an initial 
console.\n");
 
(void) sys_dup(0);
(void) sys_dup(0);
-- 
1.8.1.4

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

Re: [PATCH] ARM: Kirkwood: fix unused mvsdio gpio pins

[Thomas Petazzoni]

Dear Sebastian Hesselbarth,

On Sat, 23 Mar 2013 16:25:54 +0100, Sebastian Hesselbarth wrote:

> I understand that you proposed patch fixes mvsdio grab mpp0 by accident.
> But what if you have a kirkwood board where cd-gpio _is_ connected to mpp0?

It didn't work with the existing mvsdio driver, so the purpose of my
patch was merely to restore the old behavior, in order to avoid having
to change all the instances of mvsdio_platform_data, knowing that those
would anyway go away as we convert boards to the Device Tree.

> Not that there is one I know of, but IMHO the only useful patch is to
> set passed values to an invalid gpio number.

To me, it remains a fragile way of doing things. Let's say tomorrow you
add a new "int foo_gpio" field in mvsdio_platform_data. The whole
purpose of C99 struct initializers is that you don't have to change all
instances of the structure because all fields that are not initialized
with . =  are guaranteed to be zero. If you need to set
foo_gpio to -1 everywhere when you add this field, it becomes quite
annoying.

> > That said, I have nothing against explicitly setting those GPIO values
> > to an invalid value. Maybe -EINVAL would make more sense than just -1 ?
> 
> Every invalid gpio number will be sufficient. But -EINVAL doesn't make
> more sense than -1 does. Having no cd-gpio is not an "Invalid argument".

It's just that I've seen -EINVAL being used on some other platforms, at
least mach-at91/, but I agree it's not an invalid argument per se.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 12/29] x86, tsx: Add a per thread transaction disable count

[Borislav Petkov]

On Sat, Mar 23, 2013 at 04:52:56PM +0100, Borislav Petkov wrote:
> And wow, the XOR is *actually* faster. That's whopping three cycles on
> AMD. Similar observation on SNB.

Ok, correction: I was looking at the wrong row in the table. The XOR
version with an immediate and mem access is actually as fast as the
INC/DEC mem versions: 4 cycles on AMD F10h and 6 on SNB, according to
the docs. I should've realized that there's still a mem access there...

Anyway, the rest stands.

-- 
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] PCI / ACPI: Always resume devices on ACPI wakeup notifications

[Matthew Garrett]

Looks good to me.

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

Re: pm/linux-next cause network stop working with qemu-kvm/e1000

[Yinghai Lu]

On Sat, Mar 23, 2013 at 5:30 AM, Rafael J. Wysocki  wrote:

>>
>> Attached patch fix the problem. Please fold it into offending patch in
>> pm/linux-next.
>
> I'd actually prefer to apply it as a separate patch, so can you please post
> it with a proper changelog?

but that will break bisecting, right?

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

Re: [PATCH 01/10] migrate: add migrate_entry_wait_huge()

[Rik van Riel]

On 03/22/2013 04:23 PM, Naoya Horiguchi wrote:

When we have a page fault for the address which is backed by a hugepage
under migration, the kernel can't wait correctly until the migration
finishes. This is because pte_offset_map_lock() can't get a correct
migration entry for hugepage. This patch adds migration_entry_wait_huge()
to separate code path between normal pages and hugepages.

ChangeLog v2:
  - remove dup in migrate_entry_wait_huge()

Signed-off-by: Naoya Horiguchi 


Reviewed-by: Rik van Riel 

--
All rights reversed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 12/29] x86, tsx: Add a per thread transaction disable count

[Borislav Petkov]

On Sat, Mar 23, 2013 at 02:51:56PM +0100, Andi Kleen wrote:
> Bit fields are slower and larger in code and unlike the others this is
> on hot paths.

Really? Let's see:

unsigned:
=

.file 8 "/w/kernel/linux-2.6/arch/x86/include/asm/thread_info.h"
.loc 8 211 0
#APP
# 211 "/w/kernel/linux-2.6/arch/x86/include/asm/thread_info.h" 1
movq %gs:kernel_stack,%rax  #, pfo_ret__
# 0 "" 2
.LVL238:
#NO_APP

... # AMD 
F10h  SNB

disable:
incl-8056(%rax) # ti_25->notxn  # INC 
mem: 4; 6

test:
cmpl$0, -8056(%rax) #, ti_24->notxn # CMP 
mem, imm: 4   ; 1

reenable:
decl-8056(%rax) # ti_25->notxn  # DEC 
mem: 4; 6


bitfield:
=

.file 8 "/w/kernel/linux-2.6/arch/x86/include/asm/thread_info.h"
.loc 8 211 0
#APP
# 211 "/w/kernel/linux-2.6/arch/x86/include/asm/thread_info.h" 1
movq %gs:kernel_stack,%rax  #, pfo_ret__
# 0 "" 2
.LVL238:
#NO_APP

disable:
xorb$4, -8056(%rax) #,  # XOR 
mem, imm: 1   ; 0

test:
testb   $4, -8056(%rax) #,  # TEST 
mem, imm: 4  ; -

reenable:
xorb$4, -8056(%rax) #,  # XOR 
mem, imm: 1   ; 0


So let's explain. The AMD F10h column shows the respective instruction
latencies on AMD F10h. All instructions are DirectPath single.

The SNB column is something similar which I could find for Intel
Sandybridge: http://www.agner.org/optimize/instruction_tables.pdf. I'm
assuming Agner Fog's measurements are more or less accurate.

And wow, the XOR is *actually* faster. That's whopping three cycles on
AMD. Similar observation on SNB.

Now let's look at decoding bandwidth:

unsigned:
=

disable:
  13:   ff 80 88 e0 ff ff   incl   -0x1f78(%rax)

test:
   9:   83 b8 88 e0 ff ff 00cmpl   $0x0,-0x1f78(%rax)

reenable:
  13:   ff 88 88 e0 ff ff   decl   -0x1f78(%rax)


bitfield:
=

disable:
  13:   80 b0 88 e0 ff ff 04xorb   $0x4,-0x1f78(%rax)

test:
   9:   f6 80 88 e0 ff ff 04testb  $0x4,-0x1f78(%rax)

reenable:
  13:   80 b0 88 e0 ff ff 04xorb   $0x4,-0x1f78(%rax)

This particular XOR encoding is 1 byte longer, the rest is on-par.

Oh, and compiler is gcc (Debian 4.7.2-5) 4.7.2.

So you were saying?

-- 
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] mm: speedup in __early_pfn_to_nid

[Russ Anderson]

On Fri, Mar 22, 2013 at 08:25:32AM +0100, Ingo Molnar wrote:
> 
> * David Rientjes  wrote:
> 
> > On Thu, 21 Mar 2013, Ingo Molnar wrote:
> > 
> > > > Index: linux/mm/page_alloc.c
> > > > ===
> > > > --- linux.orig/mm/page_alloc.c  2013-03-18 10:52:11.510988843 -0500
> > > > +++ linux/mm/page_alloc.c   2013-03-18 10:52:14.214931348 -0500
> > > > @@ -4161,10 +4161,19 @@ int __meminit __early_pfn_to_nid(unsigne
> > > >  {
> > > > unsigned long start_pfn, end_pfn;
> > > > int i, nid;
> > > > +   static unsigned long last_start_pfn, last_end_pfn;
> > > > +   static int last_nid;
> > > 
> > > Please move these globals out of function local scope, to make it more 
> > > apparent that they are not on-stack. I only noticed it in the second pass.
> > 
> > The way they're currently defined places these in meminit.data as 
> > appropriate; if they are moved out, please make sure to annotate their 
> > definitions with __meminitdata.
> 
> I'm fine with having them within the function as well in this special 
> case, as long as a heavy /* NOTE: ... */ warning is put before them - 
> which explains why these SMP-unsafe globals are safe.
> 
> ( That warning will also act as a visual delimiter that breaks the 
>   normally confusing and misleading 'globals mixed amongst stack 
>   variables' pattern. )

Thanks Ingo.  Here is an updated patch with heavy warning added.

As for the wrapper function, I was unable to find an obvious
way to add a wrapper without significanly changing both
versions of __early_pfn_to_nid().  It seems cleaner to add
the change in both versions.  I'm sure someone will point 
out if this conclusion is wrong.  :-)




When booting on a large memory system, the kernel spends
considerable time in memmap_init_zone() setting up memory zones.
Analysis shows significant time spent in __early_pfn_to_nid().

The routine memmap_init_zone() checks each PFN to verify the
nid is valid.  __early_pfn_to_nid() sequentially scans the list of
pfn ranges to find the right range and returns the nid.  This does
not scale well.  On a 4 TB (single rack) system there are 308
memory ranges to scan.  The higher the PFN the more time spent
sequentially spinning through memory ranges.

Since memmap_init_zone() increments pfn, it will almost always be
looking for the same range as the previous pfn, so check that
range first.  If it is in the same range, return that nid.
If not, scan the list as before.

A 4 TB (single rack) UV1 system takes 512 seconds to get through
the zone code.  This performance optimization reduces the time
by 189 seconds, a 36% improvement.

A 2 TB (single rack) UV2 system goes from 212.7 seconds to 99.8 seconds,
a 112.9 second (53%) reduction.

Signed-off-by: Russ Anderson 
---
 arch/ia64/mm/numa.c |   15 ++-
 mm/page_alloc.c |   15 ++-
 2 files changed, 28 insertions(+), 2 deletions(-)

Index: linux/mm/page_alloc.c
===
--- linux.orig/mm/page_alloc.c  2013-03-19 16:09:03.736450861 -0500
+++ linux/mm/page_alloc.c   2013-03-22 17:07:43.895405617 -0500
@@ -4161,10 +4161,23 @@ int __meminit __early_pfn_to_nid(unsigne
 {
unsigned long start_pfn, end_pfn;
int i, nid;
+   /*
+  NOTE: The following SMP-unsafe globals are only used early
+  in boot when the kernel is running single-threaded.
+*/
+   static unsigned long last_start_pfn, last_end_pfn;
+   static int last_nid;
+
+   if (last_start_pfn <= pfn && pfn < last_end_pfn)
+   return last_nid;
 
for_each_mem_pfn_range(i, MAX_NUMNODES, _pfn, _pfn, )
-   if (start_pfn <= pfn && pfn < end_pfn)
+   if (start_pfn <= pfn && pfn < end_pfn) {
+   last_start_pfn = start_pfn;
+   last_end_pfn = end_pfn;
+   last_nid = nid;
return nid;
+   }
/* This is a memory hole */
return -1;
 }
Index: linux/arch/ia64/mm/numa.c
===
--- linux.orig/arch/ia64/mm/numa.c  2013-02-25 15:49:44.0 -0600
+++ linux/arch/ia64/mm/numa.c   2013-03-22 16:09:44.662268239 -0500
@@ -61,13 +61,26 @@ paddr_to_nid(unsigned long paddr)
 int __meminit __early_pfn_to_nid(unsigned long pfn)
 {
int i, section = pfn >> PFN_SECTION_SHIFT, ssec, esec;
+   /*
+  NOTE: The following SMP-unsafe globals are only used early
+  in boot when the kernel is running single-threaded.
+   */
+   static unsigned long last_start_pfn, last_end_pfn;
+   static int last_nid;
+
+   if (section >= last_ssec && section < last_esec)
+   return last_nid;
 
for (i = 0; i < num_node_memblks; i++) {
ssec = 

Re: [PATCH] ARM: Kirkwood: fix unused mvsdio gpio pins

[Sebastian Hesselbarth]

On 03/23/2013 04:17 PM, Thomas Petazzoni wrote:

On Sat, 23 Mar 2013 13:56:58 +0100, Sebastian Hesselbarth wrote:

mvsdio_platform_data allows to pass card detect and write protect gpio
numbers to the driver. Some kirkwood boards don't use both pins as
they are not connected, and don't set the corresponding value in
platform_data.

This will leave the unset values in platform_data initialized as 0,
which is in fact a valid gpio pin. mvsdio will grab that pin and
configure it as gpio, which in turn breaks nand controller as mpp0
also carries nand_io2.

This patch fixes the above by initializing unused gpio functions in
the platform_data with an invalid (-1) value.

Signed-off-by: Sebastian Hesselbarth
Reported-by: Soeren Moch


This somewhat "conflicts" with the patch I've submitted on the mvsdio
driver to exclude 0 as a valid GPIO, see
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-March/157157.html.
This patch ensures that the mvsdio driver behaves as it was behaving
before 3.9 as far as legacy probing is concerned.


Thomas,

I understand that you proposed patch fixes mvsdio grab mpp0 by accident.
But what if you have a kirkwood board where cd-gpio _is_ connected to mpp0?

Not that there is one I know of, but IMHO the only useful patch is to
set passed values to an invalid gpio number.


That said, I have nothing against explicitly setting those GPIO values
to an invalid value. Maybe -EINVAL would make more sense than just -1 ?


Every invalid gpio number will be sufficient. But -EINVAL doesn't make
more sense than -1 does. Having no cd-gpio is not an "Invalid argument".

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

Re: [PATCH] ARM: Kirkwood: fix unused mvsdio gpio pins

[Thomas Petazzoni]

Dear Sebastian Hesselbarth,

On Sat, 23 Mar 2013 13:56:58 +0100, Sebastian Hesselbarth wrote:
> mvsdio_platform_data allows to pass card detect and write protect gpio
> numbers to the driver. Some kirkwood boards don't use both pins as
> they are not connected, and don't set the corresponding value in
> platform_data.
> 
> This will leave the unset values in platform_data initialized as 0,
> which is in fact a valid gpio pin. mvsdio will grab that pin and
> configure it as gpio, which in turn breaks nand controller as mpp0
> also carries nand_io2.
> 
> This patch fixes the above by initializing unused gpio functions in
> the platform_data with an invalid (-1) value.
> 
> Signed-off-by: Sebastian Hesselbarth 
> Reported-by: Soeren Moch 

This somewhat "conflicts" with the patch I've submitted on the mvsdio
driver to exclude 0 as a valid GPIO, see
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-March/157157.html.
This patch ensures that the mvsdio driver behaves as it was behaving
before 3.9 as far as legacy probing is concerned.

That said, I have nothing against explicitly setting those GPIO values
to an invalid value. Maybe -EINVAL would make more sense than just -1 ?

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] tracing: Expose event tracing infrastructure

[Steven Rostedt]

On Sat, 2013-03-23 at 18:42 +0800, zhangwei(Jovi) wrote:


> Do I need to resend this patch based on your new work?(and testing) to make 
> you can merge this patch easily.
> 

Yes please,

Thanks,

-- Steve


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ARM: dove: fix Dove cpu type from V7 to PJ4

[Sebastian Hesselbarth]

The CPU used in Marvell Dove SoCs is a PJ4 Sheeva core. Using
CONFIG_CPU_PJ4 instead of CONFIG_CPU_V7 will also allow to enable
iWMMXt extensions on Dove.

Signed-off-by: Sebastian Hesselbarth 
---
Cc: Russell King 
Cc: Jason Cooper 
Cc: Andrew Lunn 
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
 arch/arm/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 2c3bdce..4fc9bca 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -556,7 +556,7 @@ config ARCH_IXP4XX
 config ARCH_DOVE
bool "Marvell Dove"
select ARCH_REQUIRE_GPIOLIB
-   select CPU_V7
+   select CPU_PJ4
select GENERIC_CLOCKEVENTS
select MIGHT_HAVE_PCI
select PINCTRL
-- 
1.7.10.4

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

[PATCH v4] clk: add si5351 i2c common clock driver

[Sebastian Hesselbarth]

This patch adds a common clock driver for Silicon Labs Si5351a/b/c
i2c programmable clock generators. Currently, the driver supports
DT kernels only and VXCO feature of si5351b is not implemented. DT
bindings selectively allow to overwrite stored Si5351 configuration
which is very helpful for clock generators with empty eeprom
configuration. Corresponding device tree binding documentation is
also added.

Signed-off-by: Sebastian Hesselbarth 
Tested-by: Daniel Mack 
---
Changes from v3:
- add silabs prefix to custom DT properties (Reported by Lars-Peter Clausen)
- use sizeof(*foo) instead of sizeof(struct bar) (Reported by Lars-Peter 
Clausen)
- check return value of of_clk_add_provider (Reported by Lars-Peter Clausen)
- clean up i2c client init (Reported by Lars-Peter Clausen)
- silence successful probe (Suggested by Lars-Peter Clausen)
- make CONFIG_CLK_SI5351 depend on CONFIG_OF

Changes from v2:
- add curly brackets to if-else-statements (Reported by Daniel Mack)
- fix div-by-zero for clk6/clk7 (Reported by Daniel Mack)
- fix parameter address calculation for clk6/clk7

Changes from v1:
- remove .is_enabled functions as they read from i2c
  (Reported by Daniel Mack)
- add CLK_SET_RATE_PARENT on clkout reparent if clkout uses
  its own multisync

Cc: Grant Likely 
Cc: Rob Herring 
Cc: Rob Landley 
Cc: Mike Turquette 
Cc: Stephen Warren 
Cc: Thierry Reding 
Cc: Dom Cobley 
Cc: Linus Walleij 
Cc: Arnd Bergmann 
Cc: Andrew Morton 
Cc: Russell King - ARM Linux 
Cc: Rabeeh Khoury 
Cc: Daniel Mack 
Cc: Jean-Francois Moine 
Cc: Lars-Peter Clausen 
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
---
 .../devicetree/bindings/clock/silabs,si5351.txt|  114 ++
 .../devicetree/bindings/vendor-prefixes.txt|1 +
 drivers/clk/Kconfig|   10 +
 drivers/clk/Makefile   |1 +
 drivers/clk/clk-si5351.c   | 1411 
 drivers/clk/clk-si5351.h   |  155 +++
 6 files changed, 1692 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/silabs,si5351.txt
 create mode 100644 drivers/clk/clk-si5351.c
 create mode 100644 drivers/clk/clk-si5351.h

diff --git a/Documentation/devicetree/bindings/clock/silabs,si5351.txt 
b/Documentation/devicetree/bindings/clock/silabs,si5351.txt
new file mode 100644
index 000..cc37465
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/silabs,si5351.txt
@@ -0,0 +1,114 @@
+Binding for Silicon Labs Si5351a/b/c programmable i2c clock generator.
+
+Reference
+[1] Si5351A/B/C Data Sheet
+http://www.silabs.com/Support%20Documents/TechnicalDocs/Si5351.pdf
+
+The Si5351a/b/c are programmable i2c clock generators with upto 8 output
+clocks. Si5351a also has a reduced pin-count package (MSOP10) where only
+3 output clocks are accessible. The internal structure of the clock
+generators can be found in [1].
+
+==I2C device node==
+
+Required properties:
+- compatible: shall be one of "silabs,si5351{a,a-msop,b,c}".
+- reg: i2c device address, shall be 0x60 or 0x61.
+- #clock-cells: from common clock binding; shall be set to 1.
+- clocks: from common clock binding; list of parent clock
+  handles, shall be xtal reference clock or xtal and clkin for
+  si5351c only.
+- #address-cells: shall be set to 1.
+- #size-cells: shall be set to 0.
+
+Optional properties:
+- silabs,pll-source: pair of (number, source) for each pll. Allows
+  to overwrite clock source of pll A (number=0) or B (number=1).
+
+==Child nodes==
+
+Each of the clock outputs can be overwritten individually by
+using a child node to the I2C device node. If a child node for a clock
+output is not set, the eeprom configuration is not overwritten.
+
+Required child node properties:
+- reg: number of clock output.
+
+Optional child node properties:
+- silabs,clock-source: source clock of the output divider stage N, shall be
+  0 = multisynth N
+  1 = multisynth 0 for output clocks 0-3, else multisynth4
+  2 = xtal
+  3 = clkin (si5351c only)
+- silabs,drive-strength: output drive strength in mA, shall be one of 
{2,4,6,8}.
+- silabs,multisynth-source: source pll A(0) or B(1) of corresponding multisynth
+  divider.
+- silabs,pll-master: boolean, multisynth can change pll frequency.
+
+==Example==
+
+/* 25MHz reference crystal */
+ref25: ref25M {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <2500>;
+};
+
+i2c-master-node {
+
+   /* Si5351a msop10 i2c clock generator */
+   si5351a: clock-generator@60 {
+   compatible = "silabs,si5351a-msop";
+   reg = <0x60>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   #clock-cells = <1>;
+
+   /* connect xtal input to 25MHz reference */
+   clocks = <>;
+
+   /* connect xtal input as source of pll0 

[PATCH 2/2] KMS: fix EDID detailed timing frame rate

[Torsten Duwe]

When KMS has parsed an EDID "detailed timing", it leaves the frame
rate zeroed. Consecutive (debug-) output of that mode thus yields 0
for vsync. This simple fix also speeds up future invocations of
drm_mode_vrefresh(). While it is debatable whether this qualifies
as a -stable fix I'd apply it for consistency's sake;
drm_helper_probe_single_connector_modes() does the same thing already
for all probed modes.

Cc: sta...@vger.kernel.org
Signed-off-by: Torsten Duwe 

--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -977,6 +977,7 @@ set_size:
}
 
mode->type = DRM_MODE_TYPE_DRIVER;
+   mode->vrefresh = drm_mode_vrefresh(mode);
drm_mode_set_name(mode);
 
return mode;

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

[PATCH 0/2] KMS: fix EDID parsing of "detailed timing"

[Torsten Duwe]

Hi all,

I'm describing a PAL CRT to my HTPC. Since it uses a 50Hz frame
rate, I had to use a "detailed timing" entry when I crafted an EDID
blob. User space tools properly reproduce the mode line I used
originally, but the kernel gets the vsync position and the frame
rate wrong. Fixes follow.

Torsten

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

[PATCH 1/2] KMS: fix EDID detailed timing vsync parsing

[Torsten Duwe]

EDID spreads some values across multiple bytes; bit-fiddling is needed
to retrieve these. The current code to parse "detailed timings" has a
cut error that results in a vsync offset of at most 15 lines
instead of 63. en.wikipedia.org/wiki/EDID "detailed timing" bytes
10+11 show why that needs to be a left shift.

Cc: sta...@vger.kernel.org
Signed-off-by: Torsten Duwe 

--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -896,7 +896,7 @@ static struct drm_display_mode *drm_mode
unsigned vblank = (pt->vactive_vblank_hi & 0xf) << 8 | pt->vblank_lo;
unsigned hsync_offset = (pt->hsync_vsync_offset_pulse_width_hi & 0xc0) 
<< 2 | pt->hsync_offset_lo;
unsigned hsync_pulse_width = (pt->hsync_vsync_offset_pulse_width_hi & 
0x30) << 4 | pt->hsync_pulse_width_lo;
-   unsigned vsync_offset = (pt->hsync_vsync_offset_pulse_width_hi & 0xc) 
>> 2 | pt->vsync_offset_pulse_width_lo >> 4;
+   unsigned vsync_offset = (pt->hsync_vsync_offset_pulse_width_hi & 0xc) 
<< 2 | pt->vsync_offset_pulse_width_lo >> 4;
unsigned vsync_pulse_width = (pt->hsync_vsync_offset_pulse_width_hi & 
0x3) << 4 | (pt->vsync_offset_pulse_width_lo & 0xf);
 
/* ignore tiny modes */

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] clocksource: exynos_mct: Add terminating entry for exynos_mct_ids table

[Axel Lin]

The of_device_id table is supposed to be zero-terminated.

Signed-off-by: Axel Lin 
---
 drivers/clocksource/exynos_mct.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clocksource/exynos_mct.c b/drivers/clocksource/exynos_mct.c
index 203ac05..3cdafc0 100644
--- a/drivers/clocksource/exynos_mct.c
+++ b/drivers/clocksource/exynos_mct.c
@@ -514,6 +514,7 @@ static void __init exynos4_timer_resources(struct 
device_node *np)
 static const struct of_device_id exynos_mct_ids[] = {
{ .compatible = "samsung,exynos4210-mct", .data = (void *)MCT_INT_SPI },
{ .compatible = "samsung,exynos4412-mct", .data = (void *)MCT_INT_PPI },
+   { }
 };
 
 void __init mct_init(void)
-- 
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] PCI / ACPI: Always resume devices on ACPI wakeup notifications

[Rafael J. Wysocki]

From: Rafael J. Wysocki 

It turns out that _Lxx control methods provided by some BIOSes clear
the PME Status bit of PCI devices they handle, which means that
pci_acpi_wake_dev() cannot really use that bit to check whether or
not the device has signalled wakeup.

For this reason, make pci_acpi_wake_dev() always attempt to resume
the device it is called for regardless of the device's PME Status bit
value (that bit still has to be cleared if set at this point,
though).

Reported-by: Sarah Sharp 
Signed-off-by: Rafael J. Wysocki 
---
 drivers/pci/pci-acpi.c |   15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

Index: linux-pm/drivers/pci/pci-acpi.c
===
--- linux-pm.orig/drivers/pci/pci-acpi.c
+++ linux-pm/drivers/pci/pci-acpi.c
@@ -53,14 +53,15 @@ static void pci_acpi_wake_dev(acpi_handl
return;
}
 
-   if (!pci_dev->pm_cap || !pci_dev->pme_support
-|| pci_check_pme_status(pci_dev)) {
-   if (pci_dev->pme_poll)
-   pci_dev->pme_poll = false;
+   /* Clear PME Status if set. */
+   if (pci_dev->pme_support)
+   pci_check_pme_status(pci_dev);
 
-   pci_wakeup_event(pci_dev);
-   pm_runtime_resume(_dev->dev);
-   }
+   if (pci_dev->pme_poll)
+   pci_dev->pme_poll = false;
+
+   pci_wakeup_event(pci_dev);
+   pm_runtime_resume(_dev->dev);
 
if (pci_dev->subordinate)
pci_pme_wakeup_bus(pci_dev->subordinate);

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] tile: ns2cycles should use __raw_get_cpu_var

[Chris Metcalf]

On 3/23/2013 3:23 AM, Henrik Austad wrote:
> + /* we don't have to disable preemptions here as each core has the same
> +  * clock-frequency */

Looks OK except the comment is in the wrong style.  Kernel multiline comments

/*
 * Should look
 * like this.
 */

and use full sentences with punctuation.  (Also, don't hyphenate clock 
frequency here.)  Thanks!

-- 
Chris Metcalf, Tilera Corp.
http://www.tilera.com

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

[PATCH V7 5/5] virtio-scsi: reset virtqueue affinity when doing cpu hotplug

[Wanlong Gao]

Add hot cpu notifier to reset the request virtqueue affinity
when doing cpu hotplug.

Cc: linux-s...@vger.kernel.org
Signed-off-by: Paolo Bonzini 
Signed-off-by: Wanlong Gao 
Reviewed-by: Asias He 
---
 drivers/scsi/virtio_scsi.c | 29 +
 1 file changed, 29 insertions(+)

diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
index 8dcdef0..2168258 100644
--- a/drivers/scsi/virtio_scsi.c
+++ b/drivers/scsi/virtio_scsi.c
@@ -110,6 +110,9 @@ struct virtio_scsi {
/* If the affinity hint is set for virtqueues */
bool affinity_hint_set;
 
+   /* CPU hotplug notifier */
+   struct notifier_block nb;
+
struct virtio_scsi_vq ctrl_vq;
struct virtio_scsi_vq event_vq;
struct virtio_scsi_vq req_vqs[];
@@ -762,6 +765,23 @@ static void virtscsi_set_affinity(struct virtio_scsi 
*vscsi, bool affinity)
put_online_cpus();
 }
 
+static int virtscsi_cpu_callback(struct notifier_block *nfb,
+unsigned long action, void *hcpu)
+{
+   struct virtio_scsi *vscsi = container_of(nfb, struct virtio_scsi, nb);
+   switch(action) {
+   case CPU_ONLINE:
+   case CPU_ONLINE_FROZEN:
+   case CPU_DEAD:
+   case CPU_DEAD_FROZEN:
+   __virtscsi_set_affinity(vscsi, true);
+   break;
+   default:
+   break;
+   }
+   return NOTIFY_OK;
+}
+
 static void virtscsi_init_vq(struct virtio_scsi_vq *virtscsi_vq,
 struct virtqueue *vq)
 {
@@ -884,6 +904,13 @@ static int virtscsi_probe(struct virtio_device *vdev)
if (err)
goto virtscsi_init_failed;
 
+   vscsi->nb.notifier_call = _cpu_callback;
+   err = register_hotcpu_notifier(>nb);
+   if (err) {
+   pr_err("registering cpu notifier failed\n");
+   goto scsi_add_host_failed;
+   }
+
cmd_per_lun = virtscsi_config_get(vdev, cmd_per_lun) ?: 1;
shost->cmd_per_lun = min_t(u32, cmd_per_lun, shost->can_queue);
shost->max_sectors = virtscsi_config_get(vdev, max_sectors) ?: 0x;
@@ -921,6 +948,8 @@ static void virtscsi_remove(struct virtio_device *vdev)
 
scsi_remove_host(shost);
 
+   unregister_hotcpu_notifier(>nb);
+
virtscsi_remove_vqs(vdev);
scsi_host_put(shost);
 }
-- 
1.8.2.rc2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 V7 1/5] virtio-scsi: redo allocation of target data

[Wanlong Gao]

virtio_scsi_target_state is now empty.  We will find new uses for it in
the next few patches, so this patch does not drop it completely.

And as James suggested, we use entries target_alloc and target_destroy
in the host template to allocate and destroy the virtio_scsi_target_state
of each target, attach this struct to scsi_target->hostdata. Now
we can get at it from the sdev with scsi_target(sdev)->hostdata.
No messing around with fixed size arrays and bulk memory allocation
and no need to pass in the maximum target size as a parameter because
everything should now happen dynamically.

Cc: James Bottomley 
Cc: linux-s...@vger.kernel.org
Signed-off-by: Paolo Bonzini 
Signed-off-by: Wanlong Gao 
Reviewed-by: Asias He 
---
 drivers/scsi/virtio_scsi.c | 71 --
 1 file changed, 25 insertions(+), 46 deletions(-)

diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
index b53ba9e..ffa03e8 100644
--- a/drivers/scsi/virtio_scsi.c
+++ b/drivers/scsi/virtio_scsi.c
@@ -75,8 +75,6 @@ struct virtio_scsi {
 
/* Get some buffers ready for event vq */
struct virtio_scsi_event_node event_list[VIRTIO_SCSI_EVENT_LEN];
-
-   struct virtio_scsi_target_state *tgt[];
 };
 
 static struct kmem_cache *virtscsi_cmd_cache;
@@ -530,6 +528,25 @@ static int virtscsi_abort(struct scsi_cmnd *sc)
return virtscsi_tmf(vscsi, cmd);
 }
 
+static int virtscsi_target_alloc(struct scsi_target *starget)
+{
+   struct virtio_scsi_target_state *tgt =
+   kmalloc(sizeof(*tgt), GFP_KERNEL);
+   if (!tgt)
+   return -ENOMEM;
+
+   spin_lock_init(>tgt_lock);
+
+   starget->hostdata = tgt;
+   return 0;
+}
+
+static void virtscsi_target_destroy(struct scsi_target *starget)
+{
+   struct virtio_scsi_target_state *tgt = starget->hostdata;
+   kfree(tgt);
+}
+
 static struct scsi_host_template virtscsi_host_template = {
.module = THIS_MODULE,
.name = "Virtio SCSI HBA",
@@ -542,6 +559,8 @@ static struct scsi_host_template virtscsi_host_template = {
.can_queue = 1024,
.dma_boundary = UINT_MAX,
.use_clustering = ENABLE_CLUSTERING,
+   .target_alloc = virtscsi_target_alloc,
+   .target_destroy = virtscsi_target_destroy,
 };
 
 #define virtscsi_config_get(vdev, fld) \
@@ -568,20 +587,6 @@ static void virtscsi_init_vq(struct virtio_scsi_vq 
*virtscsi_vq,
virtscsi_vq->vq = vq;
 }
 
-static struct virtio_scsi_target_state *virtscsi_alloc_tgt(
-   struct virtio_device *vdev)
-{
-   struct virtio_scsi_target_state *tgt;
-   gfp_t gfp_mask = GFP_KERNEL;
-
-   tgt = kmalloc(sizeof(*tgt), gfp_mask);
-   if (!tgt)
-   return NULL;
-
-   spin_lock_init(>tgt_lock);
-   return tgt;
-}
-
 static void virtscsi_scan(struct virtio_device *vdev)
 {
struct Scsi_Host *shost = (struct Scsi_Host *)vdev->priv;
@@ -591,28 +596,17 @@ static void virtscsi_scan(struct virtio_device *vdev)
 
 static void virtscsi_remove_vqs(struct virtio_device *vdev)
 {
-   struct Scsi_Host *sh = virtio_scsi_host(vdev);
-   struct virtio_scsi *vscsi = shost_priv(sh);
-   u32 i, num_targets;
-
/* Stop all the virtqueues. */
vdev->config->reset(vdev);
 
-   num_targets = sh->max_id;
-   for (i = 0; i < num_targets; i++) {
-   kfree(vscsi->tgt[i]);
-   vscsi->tgt[i] = NULL;
-   }
-
vdev->config->del_vqs(vdev);
 }
 
 static int virtscsi_init(struct virtio_device *vdev,
-struct virtio_scsi *vscsi, int num_targets)
+struct virtio_scsi *vscsi)
 {
int err;
struct virtqueue *vqs[3];
-   u32 i;
 
vq_callback_t *callbacks[] = {
virtscsi_ctrl_done,
@@ -640,18 +634,6 @@ static int virtscsi_init(struct virtio_device *vdev,
if (virtio_has_feature(vdev, VIRTIO_SCSI_F_HOTPLUG))
virtscsi_kick_event_all(vscsi);
 
-   for (i = 0; i < num_targets; i++) {
-   vscsi->tgt[i] = virtscsi_alloc_tgt(vdev);
-   if (!vscsi->tgt[i]) {
-   err = -ENOMEM;
-   goto out;
-   }
-   }
-   err = 0;
-
-out:
-   if (err)
-   virtscsi_remove_vqs(vdev);
return err;
 }
 
@@ -663,12 +645,9 @@ static int virtscsi_probe(struct virtio_device *vdev)
u32 sg_elems, num_targets;
u32 cmd_per_lun;
 
-   /* Allocate memory and link the structs together.  */
num_targets = virtscsi_config_get(vdev, max_target) + 1;
-   shost = scsi_host_alloc(_host_template,
-   sizeof(*vscsi)
-   + num_targets * sizeof(struct virtio_scsi_target_state));
 
+   shost = scsi_host_alloc(_host_template, sizeof(*vscsi));
if (!shost)
return -ENOMEM;
 
@@ -678,7 +657,7 @@ static int virtscsi_probe(struct virtio_device *vdev)
vscsi->vdev = 

Re: [PATCH V6 5/5] virtio-scsi: reset virtqueue affinity when doing cpu hotplug

[Wanlong Gao]

On 03/23/2013 02:36 PM, Paolo Bonzini wrote:
> Il 20/03/2013 08:56, Wanlong Gao ha scritto:
>>> This one does not apply on top of virtio-next + patch 1-4 in this series.
>>
>> I'm very sorry.
>>
>> This fault is because I modified the 4/5 from 
>> "/* if the affinity hint is set for virtqueues */"
>> to
>> "/* If the affinity hint is set for virtqueues */"
>> by hand.
>>
>> You can also change "If" to "if" in 5/5 to apply this patch without 3-way 
>> merge.
> 
> Can you respin?
> 
> So we can ask James for his Acked-by and get this merged in the next window.

Sure.

Thanks,
Wanlong Gao

> 
> Paolo
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 V7 4/5] virtio-scsi: introduce multiqueue support

[Wanlong Gao]

From: Paolo Bonzini 

This patch adds queue steering to virtio-scsi.  When a target is sent
multiple requests, we always drive them to the same queue so that FIFO
processing order is kept.  However, if a target was idle, we can choose
a queue arbitrarily.  In this case the queue is chosen according to the
current VCPU, so the driver expects the number of request queues to be
equal to the number of VCPUs.  This makes it easy and fast to select
the queue, and also lets the driver optimize the IRQ affinity for the
virtqueues (each virtqueue's affinity is set to the CPU that "owns"
the queue).

The speedup comes from improving cache locality and giving CPU affinity
to the virtqueues, which is why this scheme was selected.  Assuming that
the thread that is sending requests to the device is I/O-bound, it is
likely to be sleeping at the time the ISR is executed, and thus executing
the ISR on the same processor that sent the requests is cheap.

However, the kernel will not execute the ISR on the "best" processor
unless you explicitly set the affinity.  This is because in practice
you will have many such I/O-bound processes and thus many otherwise
idle processors.  Then the kernel will execute the ISR on a random
processor, rather than the one that is sending requests to the device.

The alternative to per-CPU virtqueues is per-target virtqueues.  To
achieve the same locality, we could dynamically choose the virtqueue's
affinity based on the CPU of the last task that sent a request.  This
is less appealing because we do not set the affinity directly---we only
provide a hint to the irqbalanced running in userspace.  Dynamically
changing the affinity only works if the userspace applies the hint
fast enough.

Cc: linux-s...@vger.kernel.org
Signed-off-by: Paolo Bonzini 
Signed-off-by: Wanlong Gao 
Reviewed-by: Asias He 
Tested-by: Venkatesh Srinivas 
---
 drivers/scsi/virtio_scsi.c | 282 -
 1 file changed, 254 insertions(+), 28 deletions(-)

diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
index dc2daec..8dcdef0 100644
--- a/drivers/scsi/virtio_scsi.c
+++ b/drivers/scsi/virtio_scsi.c
@@ -22,12 +22,14 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 
 #define VIRTIO_SCSI_MEMPOOL_SZ 64
 #define VIRTIO_SCSI_EVENT_LEN 8
+#define VIRTIO_SCSI_VQ_BASE 2
 
 /* Command queue element */
 struct virtio_scsi_cmd {
@@ -59,22 +61,58 @@ struct virtio_scsi_vq {
struct virtqueue *vq;
 };
 
-/* Per-target queue state */
+/*
+ * Per-target queue state.
+ *
+ * This struct holds the data needed by the queue steering policy.  When a
+ * target is sent multiple requests, we need to drive them to the same queue so
+ * that FIFO processing order is kept.  However, if a target was idle, we can
+ * choose a queue arbitrarily.  In this case the queue is chosen according to
+ * the current VCPU, so the driver expects the number of request queues to be
+ * equal to the number of VCPUs.  This makes it easy and fast to select the
+ * queue, and also lets the driver optimize the IRQ affinity for the virtqueues
+ * (each virtqueue's affinity is set to the CPU that "owns" the queue).
+ *
+ * An interesting effect of this policy is that only writes to req_vq need to
+ * take the tgt_lock.  Read can be done outside the lock because:
+ *
+ * - writes of req_vq only occur when atomic_inc_return(>reqs) returns 1.
+ *   In that case, no other CPU is reading req_vq: even if they were in
+ *   virtscsi_queuecommand_multi, they would be spinning on tgt_lock.
+ *
+ * - reads of req_vq only occur when the target is not idle (reqs != 0).
+ *   A CPU that enters virtscsi_queuecommand_multi will not modify req_vq.
+ *
+ * Similarly, decrements of reqs are never concurrent with writes of req_vq.
+ * Thus they can happen outside the tgt_lock, provided of course we make reqs
+ * an atomic_t.
+ */
 struct virtio_scsi_target_state {
-   /* Never held at the same time as vq_lock.  */
+   /* This spinlock never held at the same time as vq_lock. */
spinlock_t tgt_lock;
+
+   /* Count of outstanding requests. */
+   atomic_t reqs;
+
+   /* Currently active virtqueue for requests sent to this target. */
+   struct virtio_scsi_vq *req_vq;
 };
 
 /* Driver instance state */
 struct virtio_scsi {
struct virtio_device *vdev;
 
-   struct virtio_scsi_vq ctrl_vq;
-   struct virtio_scsi_vq event_vq;
-   struct virtio_scsi_vq req_vq;
-
/* Get some buffers ready for event vq */
struct virtio_scsi_event_node event_list[VIRTIO_SCSI_EVENT_LEN];
+
+   u32 num_queues;
+
+   /* If the affinity hint is set for virtqueues */
+   bool affinity_hint_set;
+
+   struct virtio_scsi_vq ctrl_vq;
+   struct virtio_scsi_vq event_vq;
+   struct virtio_scsi_vq req_vqs[];
 };
 
 static struct kmem_cache *virtscsi_cmd_cache;
@@ -109,6 +147,8 @@ static void virtscsi_complete_cmd(struct virtio_scsi 
*vscsi, void 

[PATCH V7 2/5] virtio-scsi: pass struct virtio_scsi to virtqueue completion function

[Wanlong Gao]

From: Paolo Bonzini 

This will be needed soon in order to retrieve the per-target
struct.

Cc: linux-s...@vger.kernel.org
Signed-off-by: Paolo Bonzini 
Signed-off-by: Wanlong Gao 
Reviewed-by: Asias He 
---
 drivers/scsi/virtio_scsi.c | 17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
index ffa03e8..c23560c 100644
--- a/drivers/scsi/virtio_scsi.c
+++ b/drivers/scsi/virtio_scsi.c
@@ -104,7 +104,7 @@ static void virtscsi_compute_resid(struct scsi_cmnd *sc, 
u32 resid)
  *
  * Called with vq_lock held.
  */
-static void virtscsi_complete_cmd(void *buf)
+static void virtscsi_complete_cmd(struct virtio_scsi *vscsi, void *buf)
 {
struct virtio_scsi_cmd *cmd = buf;
struct scsi_cmnd *sc = cmd->sc;
@@ -165,7 +165,8 @@ static void virtscsi_complete_cmd(void *buf)
sc->scsi_done(sc);
 }
 
-static void virtscsi_vq_done(struct virtqueue *vq, void (*fn)(void *buf))
+static void virtscsi_vq_done(struct virtio_scsi *vscsi, struct virtqueue *vq,
+void (*fn)(struct virtio_scsi *vscsi, void *buf))
 {
void *buf;
unsigned int len;
@@ -173,7 +174,7 @@ static void virtscsi_vq_done(struct virtqueue *vq, void 
(*fn)(void *buf))
do {
virtqueue_disable_cb(vq);
while ((buf = virtqueue_get_buf(vq, )) != NULL)
-   fn(buf);
+   fn(vscsi, buf);
} while (!virtqueue_enable_cb(vq));
 }
 
@@ -184,11 +185,11 @@ static void virtscsi_req_done(struct virtqueue *vq)
unsigned long flags;
 
spin_lock_irqsave(>req_vq.vq_lock, flags);
-   virtscsi_vq_done(vq, virtscsi_complete_cmd);
+   virtscsi_vq_done(vscsi, vq, virtscsi_complete_cmd);
spin_unlock_irqrestore(>req_vq.vq_lock, flags);
 };
 
-static void virtscsi_complete_free(void *buf)
+static void virtscsi_complete_free(struct virtio_scsi *vscsi, void *buf)
 {
struct virtio_scsi_cmd *cmd = buf;
 
@@ -205,7 +206,7 @@ static void virtscsi_ctrl_done(struct virtqueue *vq)
unsigned long flags;
 
spin_lock_irqsave(>ctrl_vq.vq_lock, flags);
-   virtscsi_vq_done(vq, virtscsi_complete_free);
+   virtscsi_vq_done(vscsi, vq, virtscsi_complete_free);
spin_unlock_irqrestore(>ctrl_vq.vq_lock, flags);
 };
 
@@ -329,7 +330,7 @@ static void virtscsi_handle_event(struct work_struct *work)
virtscsi_kick_event(vscsi, event_node);
 }
 
-static void virtscsi_complete_event(void *buf)
+static void virtscsi_complete_event(struct virtio_scsi *vscsi, void *buf)
 {
struct virtio_scsi_event_node *event_node = buf;
 
@@ -344,7 +345,7 @@ static void virtscsi_event_done(struct virtqueue *vq)
unsigned long flags;
 
spin_lock_irqsave(>event_vq.vq_lock, flags);
-   virtscsi_vq_done(vq, virtscsi_complete_event);
+   virtscsi_vq_done(vscsi, vq, virtscsi_complete_event);
spin_unlock_irqrestore(>event_vq.vq_lock, flags);
 };
 
-- 
1.8.2.rc2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 V7 3/5] virtio-scsi: push vq lock/unlock into virtscsi_vq_done

[Wanlong Gao]

From: Paolo Bonzini 

Avoid duplicated code in all of the callers.

Cc: linux-s...@vger.kernel.org
Signed-off-by: Paolo Bonzini 
Signed-off-by: Wanlong Gao 
Reviewed-by: Asias He 
---
 drivers/scsi/virtio_scsi.c | 22 +-
 1 file changed, 9 insertions(+), 13 deletions(-)

diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
index c23560c..dc2daec 100644
--- a/drivers/scsi/virtio_scsi.c
+++ b/drivers/scsi/virtio_scsi.c
@@ -165,28 +165,30 @@ static void virtscsi_complete_cmd(struct virtio_scsi 
*vscsi, void *buf)
sc->scsi_done(sc);
 }
 
-static void virtscsi_vq_done(struct virtio_scsi *vscsi, struct virtqueue *vq,
+static void virtscsi_vq_done(struct virtio_scsi *vscsi,
+struct virtio_scsi_vq *virtscsi_vq,
 void (*fn)(struct virtio_scsi *vscsi, void *buf))
 {
void *buf;
unsigned int len;
+   unsigned long flags;
+   struct virtqueue *vq = virtscsi_vq->vq;
 
+   spin_lock_irqsave(_vq->vq_lock, flags);
do {
virtqueue_disable_cb(vq);
while ((buf = virtqueue_get_buf(vq, )) != NULL)
fn(vscsi, buf);
} while (!virtqueue_enable_cb(vq));
+   spin_unlock_irqrestore(_vq->vq_lock, flags);
 }
 
 static void virtscsi_req_done(struct virtqueue *vq)
 {
struct Scsi_Host *sh = virtio_scsi_host(vq->vdev);
struct virtio_scsi *vscsi = shost_priv(sh);
-   unsigned long flags;
 
-   spin_lock_irqsave(>req_vq.vq_lock, flags);
-   virtscsi_vq_done(vscsi, vq, virtscsi_complete_cmd);
-   spin_unlock_irqrestore(>req_vq.vq_lock, flags);
+   virtscsi_vq_done(vscsi, >req_vq, virtscsi_complete_cmd);
 };
 
 static void virtscsi_complete_free(struct virtio_scsi *vscsi, void *buf)
@@ -203,11 +205,8 @@ static void virtscsi_ctrl_done(struct virtqueue *vq)
 {
struct Scsi_Host *sh = virtio_scsi_host(vq->vdev);
struct virtio_scsi *vscsi = shost_priv(sh);
-   unsigned long flags;
 
-   spin_lock_irqsave(>ctrl_vq.vq_lock, flags);
-   virtscsi_vq_done(vscsi, vq, virtscsi_complete_free);
-   spin_unlock_irqrestore(>ctrl_vq.vq_lock, flags);
+   virtscsi_vq_done(vscsi, >ctrl_vq, virtscsi_complete_free);
 };
 
 static int virtscsi_kick_event(struct virtio_scsi *vscsi,
@@ -342,11 +341,8 @@ static void virtscsi_event_done(struct virtqueue *vq)
 {
struct Scsi_Host *sh = virtio_scsi_host(vq->vdev);
struct virtio_scsi *vscsi = shost_priv(sh);
-   unsigned long flags;
 
-   spin_lock_irqsave(>event_vq.vq_lock, flags);
-   virtscsi_vq_done(vscsi, vq, virtscsi_complete_event);
-   spin_unlock_irqrestore(>event_vq.vq_lock, flags);
+   virtscsi_vq_done(vscsi, >event_vq, virtscsi_complete_event);
 };
 
 /**
-- 
1.8.2.rc2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 V7 0/5] virtio-scsi multiqueue

[Wanlong Gao]

This series implements virtio-scsi queue steering, which gives
performance improvements of up to 50% (measured both with QEMU and
tcm_vhost backends).

This version rebased on Rusty's virtio ring rework patches, which
has already gone into virtio-next today.
We hope this can go into virtio-next together with the virtio ring
rework pathes.

V7: respin to fix the patch apply error

V6: rework "redo allocation of target data" (James)
fix comments (Venkatesh)
rebase to virtio-next

V5: improving the grammar of 1/5 (Paolo)
move the dropping of sg_elems to 'virtio-scsi: use virtqueue_add_sgs for 
command buffers'. (Asias)

V4: rebase on virtio ring rework patches (rusty's pending-rebases branch)

V3 and be found http://marc.info/?l=linux-virtualization=136067440717154=2


It would probably be easier to get it in via Rusty's tree
because of the prerequisites.  James, can we get your Acked-by?

Paolo Bonzini (3):
  virtio-scsi: pass struct virtio_scsi to virtqueue completion function
  virtio-scsi: push vq lock/unlock into virtscsi_vq_done
  virtio-scsi: introduce multiqueue support

Wanlong Gao (2):
  virtio-scsi: redo allocation of target data
  virtio-scsi: reset virtqueue affinity when doing cpu hotplug

 drivers/scsi/virtio_scsi.c | 387 -
 1 file changed, 309 insertions(+), 78 deletions(-)

-- 
1.8.2.rc2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 12/29] x86, tsx: Add a per thread transaction disable count

[Andi Kleen]

> 
> This surely can be a bitfield like the other two below. It is basically
> begging to be one.

Bit fields are slower and larger in code and unlike the others this is on hot
paths.

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

[PATCH 1/2] x86: mm: Fix vmalloc_fault oops during lazy MMU updates.

[Konrad Rzeszutek Wilk]

From: Samu Kallio 

In paravirtualized x86_64 kernels, vmalloc_fault may cause an oops
when lazy MMU updates are enabled, because set_pgd effects are being
deferred.

One instance of this problem is during process mm cleanup with memory
cgroups enabled. The chain of events is as follows:

- zap_pte_range enables lazy MMU updates
- zap_pte_range eventually calls mem_cgroup_charge_statistics,
  which accesses the vmalloc'd mem_cgroup per-cpu stat area
- vmalloc_fault is triggered which tries to sync the corresponding
  PGD entry with set_pgd, but the update is deferred
- vmalloc_fault oopses due to a mismatch in the PUD entries

The OOPs usually looks as so:

[ cut here ]
kernel BUG at arch/x86/mm/fault.c:396!
invalid opcode:  [#1] SMP
.. snip ..
CPU 1
Pid: 10866, comm: httpd Not tainted 3.6.10-4.fc18.x86_64 #1
RIP: e030:[]  [] vmalloc_fault+0x11f/0x208
.. snip ..
Call Trace:
 [] do_page_fault+0x399/0x4b0
 [] ? xen_mc_extend_args+0xec/0x110
 [] page_fault+0x25/0x30
 [] ? mem_cgroup_charge_statistics.isra.13+0x13/0x50
 [] __mem_cgroup_uncharge_common+0xd8/0x350
 [] mem_cgroup_uncharge_page+0x57/0x60
 [] page_remove_rmap+0xe0/0x150
 [] ? vm_normal_page+0x1a/0x80
 [] unmap_single_vma+0x531/0x870
 [] unmap_vmas+0x52/0xa0
 [] ? pte_mfn_to_pfn+0x72/0x100
 [] exit_mmap+0x98/0x170
 [] ? __raw_callee_save_xen_pmd_val+0x11/0x1e
 [] mmput+0x83/0xf0
 [] exit_mm+0x104/0x130
 [] do_exit+0x15a/0x8c0
 [] do_group_exit+0x3f/0xa0
 [] sys_exit_group+0x17/0x20
 [] system_call_fastpath+0x16/0x1b

Calling arch_flush_lazy_mmu_mode immediately after set_pgd makes the
changes visible to the consistency checks.

CC: sta...@vger.kernel.org
RedHat-Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=914737
Tested-by: Josh Boyer 
Reported-and-Tested-by: Krishna Raman 
Signed-off-by: Samu Kallio 
Tested-by: Konrad Rzeszutek Wilk 
Signed-off-by: Konrad Rzeszutek Wilk 
---
 arch/x86/mm/fault.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index 2b97525..0e88336 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -378,10 +378,12 @@ static noinline __kprobes int vmalloc_fault(unsigned long 
address)
if (pgd_none(*pgd_ref))
return -1;
 
-   if (pgd_none(*pgd))
+   if (pgd_none(*pgd)) {
set_pgd(pgd, *pgd_ref);
-   else
+   arch_flush_lazy_mmu_mode();
+   } else {
BUG_ON(pgd_page_vaddr(*pgd) != pgd_page_vaddr(*pgd_ref));
+   }
 
/*
 * Below here mismatches are bugs because these lower tables
-- 
1.8.0.2

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

[PATCH 2/2] mm/x86: Patch out arch_flush_lazy_mmu_mode() when running on bare metal

[Konrad Rzeszutek Wilk]

From: Boris Ostrovsky 

Invoking arch_flush_lazy_mmu_mode() results in calls to
preempt_enable()/disable() which may have performance impact.

Since lazy MMU is not used on bare metal we can patch away
arch_flush_lazy_mmu_mode() so that it is never called in such
environment.

Signed-off-by: Boris Ostrovsky 
Tested-by: Josh Boyer 
Tested-by: Konrad Rzeszutek Wilk 
Acked-by: Borislav Petkov 
Signed-off-by: Konrad Rzeszutek Wilk 
---
 arch/x86/include/asm/paravirt.h   |  5 -
 arch/x86/include/asm/paravirt_types.h |  2 ++
 arch/x86/kernel/paravirt.c| 25 +
 arch/x86/lguest/boot.c|  1 +
 arch/x86/xen/mmu.c|  1 +
 5 files changed, 21 insertions(+), 13 deletions(-)

diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index 5edd174..7361e47 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -703,7 +703,10 @@ static inline void arch_leave_lazy_mmu_mode(void)
PVOP_VCALL0(pv_mmu_ops.lazy_mode.leave);
 }
 
-void arch_flush_lazy_mmu_mode(void);
+static inline void arch_flush_lazy_mmu_mode(void)
+{
+   PVOP_VCALL0(pv_mmu_ops.lazy_mode.flush);
+}
 
 static inline void __set_fixmap(unsigned /* enum fixed_addresses */ idx,
phys_addr_t phys, pgprot_t flags)
diff --git a/arch/x86/include/asm/paravirt_types.h 
b/arch/x86/include/asm/paravirt_types.h
index 142236e..b3b0ec1 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -91,6 +91,7 @@ struct pv_lazy_ops {
/* Set deferred update mode, used for batching operations. */
void (*enter)(void);
void (*leave)(void);
+   void (*flush)(void);
 };
 
 struct pv_time_ops {
@@ -679,6 +680,7 @@ void paravirt_end_context_switch(struct task_struct *next);
 
 void paravirt_enter_lazy_mmu(void);
 void paravirt_leave_lazy_mmu(void);
+void paravirt_flush_lazy_mmu(void);
 
 void _paravirt_nop(void);
 u32 _paravirt_ident_32(u32);
diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
index 17fff18..8bfb335 100644
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -263,6 +263,18 @@ void paravirt_leave_lazy_mmu(void)
leave_lazy(PARAVIRT_LAZY_MMU);
 }
 
+void paravirt_flush_lazy_mmu(void)
+{
+   preempt_disable();
+
+   if (paravirt_get_lazy_mode() == PARAVIRT_LAZY_MMU) {
+   arch_leave_lazy_mmu_mode();
+   arch_enter_lazy_mmu_mode();
+   }
+
+   preempt_enable();
+}
+
 void paravirt_start_context_switch(struct task_struct *prev)
 {
BUG_ON(preemptible());
@@ -292,18 +304,6 @@ enum paravirt_lazy_mode paravirt_get_lazy_mode(void)
return this_cpu_read(paravirt_lazy_mode);
 }
 
-void arch_flush_lazy_mmu_mode(void)
-{
-   preempt_disable();
-
-   if (paravirt_get_lazy_mode() == PARAVIRT_LAZY_MMU) {
-   arch_leave_lazy_mmu_mode();
-   arch_enter_lazy_mmu_mode();
-   }
-
-   preempt_enable();
-}
-
 struct pv_info pv_info = {
.name = "bare hardware",
.paravirt_enabled = 0,
@@ -475,6 +475,7 @@ struct pv_mmu_ops pv_mmu_ops = {
.lazy_mode = {
.enter = paravirt_nop,
.leave = paravirt_nop,
+   .flush = paravirt_nop,
},
 
.set_fixmap = native_set_fixmap,
diff --git a/arch/x86/lguest/boot.c b/arch/x86/lguest/boot.c
index 1cbd89c..7114c63 100644
--- a/arch/x86/lguest/boot.c
+++ b/arch/x86/lguest/boot.c
@@ -1334,6 +1334,7 @@ __init void lguest_init(void)
pv_mmu_ops.read_cr3 = lguest_read_cr3;
pv_mmu_ops.lazy_mode.enter = paravirt_enter_lazy_mmu;
pv_mmu_ops.lazy_mode.leave = lguest_leave_lazy_mmu_mode;
+   pv_mmu_ops.lazy_mode.flush = paravirt_flush_lazy_mmu;
pv_mmu_ops.pte_update = lguest_pte_update;
pv_mmu_ops.pte_update_defer = lguest_pte_update;
 
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index e8e3493..f4f4105 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -2197,6 +2197,7 @@ static const struct pv_mmu_ops xen_mmu_ops __initconst = {
.lazy_mode = {
.enter = paravirt_enter_lazy_mmu,
.leave = xen_leave_lazy_mmu,
+   .flush = paravirt_flush_lazy_mmu,
},
 
.set_fixmap = xen_set_fixmap,
-- 
1.8.0.2

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

Re: [PATCH 1/6] of/pci: Provide support for parsing PCI DT ranges property

[Thomas Petazzoni]

On Sat, 23 Mar 2013 10:41:56 +, Russell King - ARM Linux wrote:

> Please look at how IORESOURCE_* stuff is defined:
> #define IORESOURCE_TYPE_BITS0x1f00  /* Resource type */
> #define IORESOURCE_IO   0x0100  /* PCI/ISA I/O ports */
> #define IORESOURCE_MEM  0x0200
> #define IORESOURCE_REG  0x0300  /* Register offsets */
> #define IORESOURCE_IRQ  0x0400
> #define IORESOURCE_DMA  0x0800
> #define IORESOURCE_BUS  0x1000
> 
> Notice that it's not an array of bits.
> 
> So this should be:
>   if ((iter.flags & IORESOURCE_TYPE_BITS) == IORESOURCE_IO) {

What I've done for the Marvell PCIe driver is:

+   for_each_of_pci_range(, np) {
+   unsigned long restype = iter.flags & IORESOURCE_TYPE_BITS;
+   if (restype == IORESOURCE_IO) {
[...]
+   if (restype == IORESOURCE_MEM) {
[...]

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 21/21] cris: drop unused Kconfig symbols

[Paul Bolle]

Jesper,

On Mon, 2011-10-31 at 11:59 +0100, Jesper Nilsson wrote:
> Ok, let's do it the right way and remove them now, and I can re-add
> them in the same tree.

The patch at the start of this (old) thread still applies on top of
v3.9-rc3. Do you still intend to remove the cris Kconfig symbols unused
in mainline?

(Note that there's a second order effect to this patch:
ETRAX_ETHERNET_IFACE0, and ETRAX_ETHERNET_IFACE1, and ETRAX_SERIAL_PORT4
could also be dropped. I'm happy to submit a patch with those included
too.)


Paul Bolle

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

Re: [GIT PULL REQUEST] watchdog - v3.9-rc4 Fixes

[Wim Van Sebroeck]

Hi Linus,

> >
> > Please pull from 'master' branch of
> > git://www.linux-watchdog.org/linux-watchdog.git
> 
> That host seems to be a little sick right now. I'm not getting
> anything from it, just a very long wait followed by "Connection reset
> by peer".

I restarted the git daemon. It was indeed dead :-(. Can you retry?

Mental note: I need to get that server replaced in the very near future...

Kind regards,
Wim.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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.9-rc3+: reports battery as 0 mWh capacity on thinkpad x60

[Bjørn Mork]

"Rafael J. Wysocki"  writes:
> On Saturday, March 23, 2013 12:40:12 PM Pavel Machek wrote:
>> Hi!
>> 
>> pavel@amd:~$ cat /proc/acpi/battery/BAT0/info 
>> present: yes
>> design capacity: 0 mWh
>> last full capacity:  0 mWh
>> battery technology:  rechargeable
>> design voltage:  14400 mV
>> 
>> This worked before... at least it works in 2.6 kernel used by debian.
>
> This works for me in 3.9-rc3.  May I see your .config?

Well, if this works, then maybe the Kconfig help text should be updated:

config ACPI_PROCFS_POWER
bool "Deprecated power /proc/acpi directories"
depends on PROC_FS
help
  For backwards compatibility, this option allows
  deprecated power /proc/acpi/ directories to exist, even when
  they have been replaced by functions in /sys.
  The deprecated directories (and their replacements) include:
  /proc/acpi/battery/* (/sys/class/power_supply/*)
  /proc/acpi/ac_adapter/* (sys/class/power_supply/*)
  This option has no effect on /proc/acpi/ directories
  and functions, which do not yet exist in /sys
  This option, together with the proc directories, will be
  deleted in 2.6.39.


Time to call the bluff now :)


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

[PATCH 2/2] ARM: davinci: da850: add tps6507x touchscreen DT data

[Vishwanathrao Badarkhe, Manish]

Add tps6507x touchscreen device tree data to da850-evm.

Signed-off-by: Vishwanathrao Badarkhe, Manish 
---
:100644 100644 d1d091b... 5652501... M  arch/arm/boot/dts/da850-evm.dts
 arch/arm/boot/dts/da850-evm.dts |9 +
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
index d1d091b..5652501 100644
--- a/arch/arm/boot/dts/da850-evm.dts
+++ b/arch/arm/boot/dts/da850-evm.dts
@@ -108,4 +108,13 @@
regulator-boot-on;
};
};
+
+   tsc {
+   ti,poll_period = <30>;
+   ti,min_pressure = <0x30>;
+   ti,vref = <0>;
+   ti,vendor = <0>;
+   ti,product = <65070>;
+   ti,version = <0x100>;
+   };
 };
-- 
1.7.4.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/