Re: [PATCH] i2c/scx200_*: replace printks with pr_s
On Fri, 2012-09-14 at 21:21 -0600, Jim Cromie wrote:
> Replace printks with pr_s, add pr_fmt()s to replace NAMEs
Hi Jim.
When you do these, please maximally fill to 80 columns the printk
arguments and coalesce formats without regard to 80 columns.
> diff --git a/drivers/i2c/busses/scx200_acb.c b/drivers/i2c/busses/scx200_acb.c
> @@ -406,7 +408,7 @@ static __devinit int scx200_acb_probe(struct
> scx200_acb_iface *iface)
>
> val = inb(ACBCTL1);
> if (val) {
> - pr_debug(NAME ": disabled, but ACBCTL1=0x%02x\n",
> + pr_debug("disabled, but ACBCTL1=0x%02x\n",
> val);
pr_debug("disabled, but ACBCTL1=0x%02x\n", val);
> @@ -417,7 +419,7 @@ static __devinit int scx200_acb_probe(struct
> scx200_acb_iface *iface)
>
> val = inb(ACBCTL1);
> if ((val & ACBCTL1_NMINTE) != ACBCTL1_NMINTE) {
> - pr_debug(NAME ": enabled, but NMINTE won't be set, "
> + pr_debug("enabled, but NMINTE won't be set, "
>"ACBCTL1=0x%02x\n", val);
pr_debug("enabled, but NMINTE won't be set, ACBCTL1=0x%02x\n",
val);
etc...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/24] ARM: msm: use __iomem pointers for MMIO
On Fri, Sep 14, 2012 at 03:38:01PM -0700, Stephen Boyd wrote: > On 09/14/12 14:34, Arnd Bergmann wrote: > > ARM is moving to stricter checks on readl/write functions, > > so we need to use the correct types everywhere. > > > > Cc: David Brown > > Cc: Daniel Walker > > Cc: Bryan Huntsman > > Signed-off-by: Arnd Bergmann > > I was going to send this patch out today. Thanks. > > Acked-by: Stephen Boyd Acked-by: David Brown -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/9] PCI: preserve dev->subordinate until pci_stop_dev() has been called
On Fri, Sep 14, 2012 at 8:05 PM, Jiang Liu wrote:
> From: Yijing Wang
>
> Changeset 2ed168eeb3edec029aa0eca5cb981d6376f931f9 "PCI: Fold stop and
> remove helpers into their callers" has changed the behavior when
> removing a PCI device.
>
> Previously, for a PCI bridge device with secondary bus, dev->subordinate
> is valid when calling PCI bus notification callbacks for
> BUS_NOTIFY_ADD_DEVICE/BUS_NOTIFY_DEL_DEVICE events. Now dev->subordinate
> has been reset to NULL when calling callbacks for BUS_NOTIFY_DEL_DEVICE
> events, which may break some PCI bus notification callbacks.
>
> So revert to the original behavior to keep dev->subordinate valid for
> both BUS_NOTIFY_ADD_DEVICE events and BUS_NOTIFY_DEL_DEVICE events.
>
> Signed-off-by: Yijing Wang
> Signed-off-by: Jiang Liu
> ---
> drivers/pci/remove.c |6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/pci/remove.c b/drivers/pci/remove.c
> index 86a4636..6244956 100644
> --- a/drivers/pci/remove.c
> +++ b/drivers/pci/remove.c
> @@ -79,16 +79,16 @@ void pci_stop_and_remove_bus_device(struct pci_dev *dev)
> * iterator. Therefore, iterate in reverse so we remove the VFs
> * first, then the PF.
> */
> - if (bus) {
> + if (bus)
> list_for_each_entry_safe_reverse(child, tmp,
> >devices, bus_list)
> pci_stop_and_remove_bus_device(child);
> + pci_stop_dev(dev);
>
> + if (bus) {
> pci_remove_bus(bus);
> dev->subordinate = NULL;
> }
> -
> - pci_stop_dev(dev);
> pci_destroy_dev(dev);
> }
> EXPORT_SYMBOL(pci_stop_and_remove_bus_device);
for support root bus support with acpi_pci_root (ioapic/iommu) will
need pci_stop_bus_devices()
so I just put those function back...
http://git.kernel.org/?p=linux/kernel/git/yinghai/linux-yinghai.git;a=commitdiff;h=247a40206cf44488f21bc6074cf0ba2805d4d840
Thanks
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: 20% performance drop on PostgreSQL 9.2 from kernel 3.5.3 to 3.6-rc5 on AMD chipsets - bisected
On Fri, 2012-09-14 at 21:15 -0700, Linus Torvalds wrote: > We don't do random crazy "use another scheduler" to hide problems with > the default one. I was proposing a diagnostic. > > And since you are the author of the regressing patch, and don't seem > to treat the regression as something serious, I really see no > alternative to just reverting it. Wow, I don't know how you obtained that impression, but fine, nuke it. > Linus > > On Sep 14, 2012 9:11 PM, "Mike Galbraith" wrote: > On Fri, 2012-09-14 at 23:27 +0200, Borislav Petkov wrote: > > (Adding everybody to CC and leaving the below for > reference.) > > > > Guys, > > > > as Nikolay says below, we have a regression in 3.6 with > pgbench's > > benchmark in postgresql. > > > > I was able to reproduce it on another box here and did a > bisection run. > > It pointed to the commit below. > > > > And yes, reverting that commit fixes the issue here. > > My wild (and only) theory is that this is userspace spinlock > related. > If so, starting the server and benchmark SCHED_BATCH should > not only > kill the regression, but likely improve throughput as well. > > -Mike > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] USB: remove CONFIG_EXPERIMENTAL dependancies
From: Greg Kroah-Hartman As discussed at the kernel summit this year, CONFIG_EXPERIMENTAL means nothing, so let's get rid of it. Cc: Kees Cook Cc: Felipe Balbi Cc: David Herrmann Cc: Hauke Mehrtens Cc: Alan Stern Cc: Neil Zhang Cc: Randy Dunlap Cc: Fabio Estevam Signed-off-by: Greg Kroah-Hartman --- drivers/usb/core/Kconfig |2 +- drivers/usb/gadget/Kconfig | 17 ++--- drivers/usb/host/Kconfig | 22 ++ drivers/usb/wusbcore/Kconfig |3 +-- 4 files changed, 18 insertions(+), 26 deletions(-) Any objections to me applying this patch to the usb-next branch? diff --git a/drivers/usb/core/Kconfig b/drivers/usb/core/Kconfig index 9981984..f70c1a1 100644 --- a/drivers/usb/core/Kconfig +++ b/drivers/usb/core/Kconfig @@ -56,7 +56,7 @@ config USB_SUSPEND config USB_OTG bool "OTG support" - depends on USB && EXPERIMENTAL + depends on USB depends on USB_SUSPEND default n help diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig index a53be32..dfb51a4 100644 --- a/drivers/usb/gadget/Kconfig +++ b/drivers/usb/gadget/Kconfig @@ -557,7 +557,7 @@ config USB_ZERO_HNPTEST one serve as the USB host instead (in the "B-Host" role). config USB_AUDIO - tristate "Audio Gadget (EXPERIMENTAL)" + tristate "Audio Gadget" depends on SND select USB_LIBCOMPOSITE select SND_PCM @@ -672,8 +672,7 @@ config USB_G_NCM dynamically linked module called "g_ncm". config USB_GADGETFS - tristate "Gadget Filesystem (EXPERIMENTAL)" - depends on EXPERIMENTAL + tristate "Gadget Filesystem" help This driver provides a filesystem based API that lets user mode programs implement a single-configuration USB device, including @@ -681,15 +680,11 @@ config USB_GADGETFS All endpoints, transfer speeds, and transfer types supported by the hardware are available, through read() and write() calls. - Currently, this option is still labelled as EXPERIMENTAL because - of existing race conditions in the underlying in-kernel AIO core. - Say "y" to link the driver statically, or "m" to build a dynamically linked module called "gadgetfs". config USB_FUNCTIONFS - tristate "Function Filesystem (EXPERIMENTAL)" - depends on EXPERIMENTAL + tristate "Function Filesystem" select USB_LIBCOMPOSITE select USB_FUNCTIONFS_GENERIC if !(USB_FUNCTIONFS_ETH || USB_FUNCTIONFS_RNDIS) help @@ -799,8 +794,8 @@ config USB_G_SERIAL make MS-Windows work with CDC ACM. config USB_MIDI_GADGET - tristate "MIDI Gadget (EXPERIMENTAL)" - depends on SND && EXPERIMENTAL + tristate "MIDI Gadget" + depends on SND select USB_LIBCOMPOSITE select SND_RAWMIDI help @@ -867,7 +862,7 @@ config USB_G_ACM_MS dynamically linked module called "g_acm_ms". config USB_G_MULTI - tristate "Multifunction Composite Gadget (EXPERIMENTAL)" + tristate "Multifunction Composite Gadget" depends on BLOCK && NET select USB_G_MULTI_CDC if !USB_G_MULTI_RNDIS select USB_LIBCOMPOSITE diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index 13cd6d5..b1deb0f 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -18,8 +18,8 @@ config USB_C67X00_HCD module will be called c67x00. config USB_XHCI_HCD - tristate "xHCI HCD (USB 3.0) support (EXPERIMENTAL)" - depends on USB && USB_ARCH_HAS_XHCI && EXPERIMENTAL + tristate "xHCI HCD (USB 3.0) support" + depends on USB && USB_ARCH_HAS_XHCI ---help--- The eXtensible Host Controller Interface (xHCI) is standard for USB 3.0 "SuperSpeed" host controller hardware. @@ -262,7 +262,7 @@ config USB_ISP116X_HCD config USB_ISP1760_HCD tristate "ISP 1760 HCD support" - depends on USB && EXPERIMENTAL + depends on USB ---help--- The ISP1760 chip is a USB 2.0 host controller. @@ -376,7 +376,7 @@ config USB_OHCI_HCD_PCI config USB_OHCI_HCD_SSB bool "OHCI support for Broadcom SSB OHCI core (DEPRECATED)" - depends on USB_OHCI_HCD && (SSB = y || SSB = USB_OHCI_HCD) && EXPERIMENTAL + depends on USB_OHCI_HCD && (SSB = y || SSB = USB_OHCI_HCD) select USB_HCD_SSB select USB_OHCI_HCD_PLATFORM default n @@ -414,7 +414,7 @@ config USB_CNS3XXX_OHCI config USB_OHCI_HCD_PLATFORM bool "Generic OHCI driver for a platform device" - depends on USB_OHCI_HCD && EXPERIMENTAL + depends on USB_OHCI_HCD default n ---help--- Adds an OHCI host driver for a generic platform device, which @@ -424,7 +424,7 @@ config USB_OHCI_HCD_PLATFORM config USB_EHCI_HCD_PLATFORM bool "Generic EHCI driver for a platform device" - depends on USB_EHCI_HCD &&
Re: rtl8192se: ping router gives mdev of 25387.102???
Hi Larry, hi all,
On Fr, 14 Sep 2012, wrote:
> I am running on top of default kernel git, will try wireless-testing, too.
I tried now with wireless-testing from yesterday, and had the same problem.
Actually, I got even *better* results:
64 bytes from 192.168.0.1: icmp_req=75 ttl=255 time=137856 ms
64 bytes from 192.168.0.1: icmp_req=76 ttl=255 time=136848 ms
64 bytes from 192.168.0.1: icmp_req=78 ttl=255 time=134943 ms
...
rtt min/avg/max/mdev = 1.110/46967.879/137856.232/49666.671 ms, pipe 138
So now we are mdev of 50secs sometimes ;-)
Another interesting things:
At home I have the problems with the NEC router, but I am now at
the university. I am writing this email over a very very stable
ssh link to another server.
Here is the output iof ifconfig:
$ ifconfig
eth0 Link encap:Ethernet HWaddr 60:eb:69:c9:0c:ea
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
loLink encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:20418 errors:0 dropped:0 overruns:0 frame:0
TX packets:20418 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1950587 (1.8 MiB) TX bytes:1950587 (1.8 MiB)
wlan0 Link encap:Ethernet HWaddr 88:9f:fa:f9:07:28
inet addr:150.65.206.200 Bcast:150.65.207.255 Mask:255.255.252.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:232640 errors:0 dropped:1 overruns:0 frame:0
TX packets:69798 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:85599897 (81.6 MiB) TX bytes:8925832 (8.5 MiB)
But the kernel is convinced that I am not connected ...:
$ iw dev wlan0 link
Not connected.
$ iwconfig wlan0
wlan0 IEEE 802.11bgn ESSID:off/any
Mode:Managed Access Point: Not-Associated Tx-Power=20 dBm
Retry long limit:7 RTS thr=2347 B Fragment thr:off
Encryption key:off
Power Management:off
And no, I guarantee you there is no ethernet cable plugged in ;-)
I can only assume that is a problem with iwconfig/iw being too old,
although according to the output of iwconfig it is fine:
# iw --version
iw version 3.4
# iwconfig --version
iwconfig Wireless-Tools version 30
Compatible with Wireless Extension v11 to v22.
KernelCurrently compiled with Wireless Extension v22.
wlan0 Recommend Wireless Extension v21 or later,
Currently compiled with Wireless Extension v22.
# uname -a
Linux tofuschnitzel 3.6.0-rc5-wl+ #19 SMP PREEMPT Fri Sep 14 13:14:15 JST 2012
x86_64 GNU/Linux
Best wishes
Norbert
Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
CHICAGO (n.)
The foul-smelling wind which precedes an underground railway train.
--- Douglas Adams, The Meaning of Liff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: 20% performance drop on PostgreSQL 9.2 from kernel 3.5.3 to 3.6-rc5 on AMD chipsets - bisected
On Fri, 2012-09-14 at 23:27 +0200, Borislav Petkov wrote: > (Adding everybody to CC and leaving the below for reference.) > > Guys, > > as Nikolay says below, we have a regression in 3.6 with pgbench's > benchmark in postgresql. > > I was able to reproduce it on another box here and did a bisection run. > It pointed to the commit below. > > And yes, reverting that commit fixes the issue here. My wild (and only) theory is that this is userspace spinlock related. If so, starting the server and benchmark SCHED_BATCH should not only kill the regression, but likely improve throughput as well. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 24/24] net: seeq: use __iomem pointers for MMIO
From: Russell King - ARM Linux Date: Sat, 15 Sep 2012 00:56:07 +0100 > On Fri, Sep 14, 2012 at 11:34:52PM +0200, Arnd Bergmann wrote: >> ARM is moving to stricter checks on readl/write functions, >> so we need to use the correct types everywhere. > > Same comment as for eesox. const void __iomem * is not a problem on > x86, so it should not be a problem on ARM. Agreed. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: 20% performance drop on PostgreSQL 9.2 from kernel 3.5.3 to 3.6-rc5 on AMD chipsets - bisected
On Fri, 2012-09-14 at 23:59 +0200, Peter Zijlstra wrote: > On Fri, 2012-09-14 at 23:56 +0200, Peter Zijlstra wrote: > > On Fri, 2012-09-14 at 14:44 -0700, Linus Torvalds wrote: > > > On Fri, Sep 14, 2012 at 2:40 PM, Peter Zijlstra > > > wrote: > > > > > > > > The problem the patch is trying to address is not having to scan an > > > > entire package for idle cores on every wakeup now that packages are > > > > getting stupid big. > > > > > > No, it does something *else* too. That whole "left-right" logic to > > > (according to the commit message) "prevent bouncing" is entirely new, > > > afaik. > > > > > > So it is *not* just about avoiding to have to scan the whole package. > > > It changes actual semantics too. No? > > > > Both things change semantics, not looking at the entire package is new > > too. But yeah I guess you could look at the exact cross-stitching as an > > enhancement to the 'idle_buggy' thing. > > What I'm saying is that having an idle_buggy means you have to assign > one in the first place, his left-right stuff might not be the simplest > means to do that -- in fact I suggested he do a simple shift first time > I saw that patch. Shift just means that upon perturbation, tasks shift their way around the package vs random bounce around, that's why I cross wired. > So if not the left-right thing, you still need to do _something_ to make > the idle_buggy work at all. So its not entirely separate. Yeah. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux 3.5.3
I'm announcing the release of the 3.5.4 kernel. All users of the 3.5 kernel series must upgrade. The updated 3.5.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.5.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Documentation/i2c/busses/i2c-i801 |1 Makefile |2 arch/alpha/include/asm/fpu.h |2 arch/alpha/include/asm/socket.h|2 arch/arm/Kconfig |1 arch/arm/include/asm/pgtable.h | 40 +- arch/arm/mach-imx/Makefile | 10 +- arch/arm/mach-imx/head-v7.S| 106 - arch/arm/mach-imx/headsmp.S| 106 + arch/arm/mach-imx/hotplug.c| 23 -- arch/arm/mach-s3c24xx/include/mach/dma.h |3 arch/arm/mm/flush.c|2 arch/arm/mm/tlb-v7.S |6 - arch/arm/plat-omap/dmtimer.c |2 arch/arm/plat-s3c24xx/dma.c|2 arch/arm/vfp/vfpmodule.c |2 arch/mips/pci/pci-ar724x.c | 22 ++ arch/parisc/include/asm/atomic.h |4 - arch/powerpc/kernel/asm-offsets.c |1 arch/powerpc/kernel/dbell.c|2 arch/powerpc/kernel/entry_64.S | 23 -- arch/powerpc/kernel/process.c | 12 --- arch/powerpc/kernel/smp.c | 11 ++- arch/powerpc/kernel/sysfs.c| 10 ++ arch/powerpc/kernel/traps.c|3 arch/powerpc/sysdev/xics/icp-hv.c |6 + arch/x86/kernel/microcode_amd.c|7 + arch/x86/mm/hugetlbpage.c | 21 - arch/x86/syscalls/syscall_64.tbl |6 + arch/x86/xen/p2m.c | 95 + arch/x86/xen/setup.c |9 ++ drivers/acpi/acpica/tbxface.c |1 drivers/block/cciss_scsi.c | 11 --- drivers/gpu/drm/gma500/psb_intel_display.c |3 drivers/gpu/drm/radeon/radeon_object.c |3 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c|1 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c|6 + drivers/hid/usbhid/hid-quirks.c|1 drivers/hwmon/asus_atk0110.c |6 + drivers/i2c/busses/Kconfig |6 + drivers/i2c/busses/Makefile|5 - drivers/i2c/busses/i2c-designware-core.c | 11 +++ drivers/i2c/busses/i2c-i801.c |3 drivers/input/serio/i8042-x86ia64io.h | 14 +++ drivers/media/dvb/siano/smsusb.c |2 drivers/media/video/gspca/jl2005bcd.c |2 drivers/media/video/gspca/spca506.c|2 drivers/media/video/uvc/uvc_queue.c|1 drivers/mtd/ubi/vtbl.c |4 - drivers/net/ethernet/intel/e1000e/e1000.h |1 drivers/net/ethernet/intel/e1000e/netdev.c | 48 ++--- drivers/net/usb/usbnet.c |2 drivers/net/wireless/ath/ath9k/pci.c |1 drivers/net/wireless/ath/ath9k/recv.c |2 drivers/net/wireless/p54/p54usb.c |2 drivers/net/wireless/rtl818x/rtl8187/dev.c |2 drivers/pci/pci-driver.c |7 + drivers/rapidio/devices/tsi721.c | 12 +++ drivers/regulator/twl-regulator.c |4 - drivers/scsi/megaraid/megaraid_sas_base.c |3 drivers/scsi/mpt2sas/mpt2sas_base.c| 13 ++- drivers/scsi/scsi_error.c | 10 ++ drivers/scsi/scsi_lib.c|5 + drivers/scsi/scsi_scan.c | 10 ++ drivers/staging/vt6656/main_usb.c |2 drivers/staging/winbond/wbusb.c|2 drivers/target/target_core_transport.c |4 - drivers/usb/class/cdc-acm.c|3 drivers/usb/misc/emi62.c |2 drivers/video/omap2/omapfb/omapfb-main.c |2 drivers/xen/swiotlb-xen.c |2 drivers/xen/xen-pciback/pci_stub.c |8 +- fs/btrfs/extent_io.c | 17 fs/btrfs/volumes.c | 22 -- fs/btrfs/volumes.h |2 fs/buffer.c| 66 -- fs/compat.c| 10 ++ fs/ext3/inode.c| 17 +++- fs/fuse/dev.c |1 fs/jbd/journal.c |5 + fs/nfs/idmap.c | 62 fs/nfs/nfs3proc.c |2 fs/nfs/nfs4proc.c | 65 +++-- fs/nfs/pnfs.c
Linux 3.4.11
I'm announcing the release of the 3.4.11 kernel. All users of the 3.4 kernel series must upgrade. The updated 3.4.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.4.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Documentation/i2c/busses/i2c-i801 |1 Makefile |2 arch/alpha/include/asm/fpu.h |2 arch/alpha/include/asm/socket.h|2 arch/arm/Kconfig |1 arch/arm/include/asm/pgtable.h | 40 + arch/arm/mach-imx/hotplug.c| 23 +- arch/arm/mach-s3c24xx/include/mach/dma.h |3 - arch/arm/mm/flush.c|2 arch/arm/mm/tlb-v7.S |6 +- arch/arm/plat-omap/dmtimer.c |2 arch/arm/plat-s3c24xx/dma.c|2 arch/arm/vfp/vfpmodule.c |2 arch/parisc/include/asm/atomic.h |4 - arch/powerpc/kernel/asm-offsets.c |1 arch/powerpc/kernel/dbell.c|2 arch/powerpc/kernel/entry_64.S | 23 +++--- arch/powerpc/kernel/process.c | 12 - arch/powerpc/kernel/smp.c | 11 +++- arch/powerpc/kernel/sysfs.c| 10 arch/powerpc/kernel/traps.c|3 - arch/powerpc/sysdev/xics/icp-hv.c |6 ++ arch/x86/kernel/microcode_amd.c|7 +-- arch/x86/mm/hugetlbpage.c | 21 +++-- arch/x86/syscalls/syscall_64.tbl |6 +- arch/x86/xen/setup.c |9 +++ drivers/acpi/acpica/tbxface.c |1 drivers/block/cciss_scsi.c | 11 drivers/dma/imx-dma.c | 36 --- drivers/gpu/drm/radeon/radeon_object.c |3 - drivers/gpu/drm/vmwgfx/vmwgfx_drv.c|1 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c|6 ++ drivers/hid/usbhid/hid-quirks.c|1 drivers/hwmon/asus_atk0110.c |6 ++ drivers/i2c/busses/Kconfig |6 ++ drivers/i2c/busses/Makefile|5 +- drivers/i2c/busses/i2c-designware-core.c | 11 drivers/i2c/busses/i2c-i801.c |3 + drivers/input/serio/i8042-x86ia64io.h | 14 ++ drivers/media/dvb/siano/smsusb.c |2 drivers/media/video/gspca/jl2005bcd.c |2 drivers/media/video/gspca/spca506.c|2 drivers/media/video/uvc/uvc_queue.c|1 drivers/net/wireless/ath/ath9k/recv.c |2 drivers/net/wireless/p54/p54usb.c |2 drivers/net/wireless/rtl818x/rtl8187/dev.c |2 drivers/pci/pci-driver.c |7 +++ drivers/rapidio/devices/tsi721.c | 12 - drivers/regulator/twl-regulator.c |4 - drivers/scsi/megaraid/megaraid_sas_base.c |3 - drivers/scsi/mpt2sas/mpt2sas_base.c| 13 +++-- drivers/scsi/scsi_error.c | 10 drivers/scsi/scsi_lib.c|5 +- drivers/scsi/scsi_scan.c | 10 drivers/staging/vt6656/main_usb.c |2 drivers/staging/winbond/wbusb.c|2 drivers/target/target_core_transport.c |4 - drivers/usb/class/cdc-acm.c|3 - drivers/usb/misc/emi62.c |2 drivers/xen/swiotlb-xen.c |2 drivers/xen/xen-pciback/pci_stub.c |8 +-- fs/buffer.c| 66 + fs/compat.c| 10 +++- fs/ext3/inode.c| 17 ++- fs/fuse/dev.c |1 fs/nfs/idmap.c | 62 +++ fs/nfs/nfs3proc.c |2 fs/nfs/nfs4proc.c | 65 +--- fs/nfs/pnfs.c | 39 - fs/nfs/pnfs.h |2 fs/nfs/super.c |2 fs/open.c |7 +-- fs/ubifs/debug.h |2 fs/udf/file.c | 35 --- kernel/audit_tree.c| 11 ++-- kernel/sched/core.c| 35 +-- kernel/sched/sched.h |2 mm/mempolicy.c |2 net/bluetooth/hci_event.c | 28 +--- net/bluetooth/l2cap_core.c |1 net/dccp/ccid.h|4 - net/socket.c |4 -
Re: Linux 3.0.43
diff --git a/Makefile b/Makefile
index d863aa0..4bd7aed 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 3
PATCHLEVEL = 0
-SUBLEVEL = 42
+SUBLEVEL = 43
EXTRAVERSION =
NAME = Sneaky Weasel
diff --git a/arch/alpha/include/asm/socket.h b/arch/alpha/include/asm/socket.h
index 06edfef..3eeb47c 100644
--- a/arch/alpha/include/asm/socket.h
+++ b/arch/alpha/include/asm/socket.h
@@ -69,9 +69,11 @@
#define SO_RXQ_OVFL 40
+#ifdef __KERNEL__
/* O_NONBLOCK clashes with the bits used for socket types. Therefore we
* have to define SOCK_NONBLOCK to a different value here.
*/
#define SOCK_NONBLOCK 0x4000
+#endif /* __KERNEL__ */
#endif /* _ASM_SOCKET_H */
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index f9b212e..fad8e72 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1875,6 +1875,7 @@ source "drivers/cpufreq/Kconfig"
config CPU_FREQ_IMX
tristate "CPUfreq driver for i.MX CPUs"
depends on ARCH_MXC && CPU_FREQ
+ select CPU_FREQ_TABLE
help
This enables the CPUfreq driver for i.MX CPUs.
diff --git a/arch/arm/include/asm/pgtable.h b/arch/arm/include/asm/pgtable.h
index 5750704..6afd081 100644
--- a/arch/arm/include/asm/pgtable.h
+++ b/arch/arm/include/asm/pgtable.h
@@ -360,6 +360,18 @@ static inline pte_t *pmd_page_vaddr(pmd_t pmd)
#define set_pte_ext(ptep,pte,ext) cpu_set_pte_ext(ptep,pte,ext)
#define pte_clear(mm,addr,ptep)set_pte_ext(ptep, __pte(0), 0)
+#define pte_none(pte) (!pte_val(pte))
+#define pte_present(pte) (pte_val(pte) & L_PTE_PRESENT)
+#define pte_write(pte) (!(pte_val(pte) & L_PTE_RDONLY))
+#define pte_dirty(pte) (pte_val(pte) & L_PTE_DIRTY)
+#define pte_young(pte) (pte_val(pte) & L_PTE_YOUNG)
+#define pte_exec(pte) (!(pte_val(pte) & L_PTE_XN))
+#define pte_special(pte) (0)
+
+#define pte_present_user(pte) \
+ ((pte_val(pte) & (L_PTE_PRESENT | L_PTE_USER)) == \
+(L_PTE_PRESENT | L_PTE_USER))
+
#if __LINUX_ARM_ARCH__ < 6
static inline void __sync_icache_dcache(pte_t pteval)
{
@@ -371,25 +383,15 @@ extern void __sync_icache_dcache(pte_t pteval);
static inline void set_pte_at(struct mm_struct *mm, unsigned long addr,
pte_t *ptep, pte_t pteval)
{
- if (addr >= TASK_SIZE)
- set_pte_ext(ptep, pteval, 0);
- else {
+ unsigned long ext = 0;
+
+ if (addr < TASK_SIZE && pte_present_user(pteval)) {
__sync_icache_dcache(pteval);
- set_pte_ext(ptep, pteval, PTE_EXT_NG);
+ ext |= PTE_EXT_NG;
}
-}
-#define pte_none(pte) (!pte_val(pte))
-#define pte_present(pte) (pte_val(pte) & L_PTE_PRESENT)
-#define pte_write(pte) (!(pte_val(pte) & L_PTE_RDONLY))
-#define pte_dirty(pte) (pte_val(pte) & L_PTE_DIRTY)
-#define pte_young(pte) (pte_val(pte) & L_PTE_YOUNG)
-#define pte_exec(pte) (!(pte_val(pte) & L_PTE_XN))
-#define pte_special(pte) (0)
-
-#define pte_present_user(pte) \
- ((pte_val(pte) & (L_PTE_PRESENT | L_PTE_USER)) == \
-(L_PTE_PRESENT | L_PTE_USER))
+ set_pte_ext(ptep, pteval, ext);
+}
#define PTE_BIT_FUNC(fn,op) \
static inline pte_t pte_##fn(pte_t pte) { pte_val(pte) op; return pte; }
@@ -416,13 +418,13 @@ static inline pte_t pte_modify(pte_t pte, pgprot_t
newprot)
*
* 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1
* 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
- * <--- offset > <- type --> 0 0 0
+ * <--- offset --> < type -> 0 0 0
*
- * This gives us up to 63 swap files and 32GB per swap file. Note that
+ * This gives us up to 31 swap files and 64GB per swap file. Note that
* the offset field is always non-zero.
*/
#define __SWP_TYPE_SHIFT 3
-#define __SWP_TYPE_BITS6
+#define __SWP_TYPE_BITS5
#define __SWP_TYPE_MASK((1 << __SWP_TYPE_BITS) - 1)
#define __SWP_OFFSET_SHIFT (__SWP_TYPE_BITS + __SWP_TYPE_SHIFT)
diff --git a/arch/arm/mm/flush.c b/arch/arm/mm/flush.c
index 1a8d4aa..8fda9f7 100644
--- a/arch/arm/mm/flush.c
+++ b/arch/arm/mm/flush.c
@@ -236,8 +236,6 @@ void __sync_icache_dcache(pte_t pteval)
struct page *page;
struct address_space *mapping;
- if (!pte_present_user(pteval))
- return;
if (cache_is_vipt_nonaliasing() && !pte_exec(pteval))
/* only flush non-aliasing VIPT caches for exec mappings */
return;
diff --git a/arch/arm/mm/tlb-v7.S b/arch/arm/mm/tlb-v7.S
index 875634a..d7d0f7f 100644
--- a/arch/arm/mm/tlb-v7.S
+++ b/arch/arm/mm/tlb-v7.S
@@ -38,10 +38,10 @@ ENTRY(v7wbi_flush_user_tlb_range)
dsb
mov r0, r0, lsr #PAGE_SHIFT @ align address
mov r1, r1, lsr #PAGE_SHIFT
-#ifdef CONFIG_ARM_ERRATA_720789
- mov r3, #0
-#else
asidr3,
Linux 3.0.43
I'm announcing the release of the 3.0.43 kernel. All users of the 3.0 kernel series must upgrade. The updated 3.0.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.0.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile |2 arch/alpha/include/asm/socket.h|2 arch/arm/Kconfig |1 arch/arm/include/asm/pgtable.h | 40 + arch/arm/mm/flush.c|2 arch/arm/mm/tlb-v7.S |6 +- arch/arm/plat-s3c24xx/dma.c|2 arch/parisc/include/asm/atomic.h |4 - arch/powerpc/kernel/asm-offsets.c |1 arch/powerpc/kernel/entry_64.S | 23 +++--- arch/powerpc/kernel/process.c | 12 - arch/x86/mm/hugetlbpage.c | 21 +++-- drivers/acpi/acpica/tbxface.c |1 drivers/block/cciss_scsi.c | 11 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c|1 drivers/hwmon/asus_atk0110.c |6 ++ drivers/input/serio/i8042-x86ia64io.h | 14 ++ drivers/media/dvb/siano/smsusb.c |2 drivers/media/video/gspca/spca506.c|2 drivers/net/wireless/ath/ath9k/recv.c |2 drivers/net/wireless/p54/p54usb.c |2 drivers/net/wireless/rtl818x/rtl8187/dev.c |2 drivers/pci/pci-driver.c |7 +++ drivers/scsi/megaraid/megaraid_sas_base.c |3 - drivers/scsi/mpt2sas/mpt2sas_base.c| 13 +++-- drivers/scsi/scsi_error.c | 10 drivers/scsi/scsi_scan.c | 10 drivers/staging/vt6656/main_usb.c |2 drivers/staging/winbond/wbusb.c|2 drivers/usb/class/cdc-acm.c|3 - drivers/usb/misc/emi62.c |2 fs/buffer.c| 66 + fs/compat.c| 10 +++- fs/ext3/inode.c| 17 ++- fs/fuse/dev.c |1 fs/nfs/nfs3proc.c |2 fs/nfs/nfs4proc.c |8 --- fs/nfs/super.c |2 fs/open.c |7 +-- fs/udf/file.c | 35 --- kernel/audit_tree.c| 11 ++-- mm/mempolicy.c |2 net/dccp/ccid.h|4 - net/sunrpc/svc_xprt.c | 10 +--- net/sunrpc/svcsock.c |2 sound/pci/hda/hda_proc.c |2 sound/soc/codecs/wm9712.c | 19 +++- 47 files changed, 259 insertions(+), 150 deletions(-) Al Viro (1): vfs: missed source of ->f_pos races Alex Deucher (1): ACPI: export symbol acpi_get_table_with_size Anton Blanchard (2): powerpc: Fix DSCR inheritance in copy_thread() powerpc: Restore correct DSCR in context switch Arnd Bergmann (1): ARM: imx: select CPU_FREQ_TABLE when needed Dave Airlie (1): drm/vmwgfx: add MODULE_DEVICE_TABLE so vmwgfx loads at boot Dave Jones (1): Remove user-triggerable BUG from mpol_to_str Dmitry Torokhov (1): Input: i8042 - add Gigabyte T1005 series netbooks to noloop table Greg Kroah-Hartman (8): USB: vt6656: remove __devinit* from the struct usb_device_id table USB: emi62: remove __devinit* from the struct usb_device_id table USB: winbond: remove __devinit* from the struct usb_device_id table USB: spca506: remove __devinit* from the struct usb_device_id table USB: p54usb: remove __devinit* from the struct usb_device_id table USB: rtl8187: remove __devinit* from the struct usb_device_id table USB: smsusb: remove __devinit* from the struct usb_device_id table Linux 3.0.43 Heiko Stuebner (1): ARM: S3C24XX: Fix s3c2410_dma_enqueue parameters Hugh Dickins (1): block: replace __getblk_slow misfix by grow_dev_page fix J. Bruce Fields (3): svcrpc: fix BUG() in svc_tcp_clear_pages svcrpc: fix svc_xprt_enqueue/svc_recv busy-looping svcrpc: sends on closed socket should stop immediately James Bottomley (1): SCSI: Fix 'Device not ready' issue on mpt2sas Jan Kara (2): udf: Fix data corruption for files in ICB ext3: Fix fdatasync() for files with only i_size changes Kashyap Desai (1): SCSI: megaraid_sas: Move poll_aen_lock initializer Lorenzo Bianconi (1): ath9k: fix decrypt_error initialization in ath_rx_tasklet() Luca Tettamanti (1): hwmon: (asus_atk0110) Add quirk for Asus M5A78L Mark Brown (1):
Re: 20% performance drop on PostgreSQL 9.2 from kernel 3.5.3 to 3.6-rc5 on AMD chipsets - bisected
On Fri, 2012-09-14 at 14:42 -0700, Linus Torvalds wrote: > On Fri, Sep 14, 2012 at 2:27 PM, Borislav Petkov wrote: > > > > as Nikolay says below, we have a regression in 3.6 with pgbench's > > benchmark in postgresql. > > > > I was able to reproduce it on another box here and did a bisection run. > > It pointed to the commit below. > > Ok. I guess we should just revert it. However, before we do that, > maybe Mike can make it just use the exact old semantics of > select_idle_sibling() in the update_top_cache_domain() logic. > > Because the patch in question seems to do two things: > (a) cache the "idle_buggy" logic, so that we don't have those costly loops > (b) change it to do that "left-right" thing. > > and that (b) thing may be what causes a regression for you. > > So my gut feel is that the patch was wrong to begin with, exactly > because it did two independent changes. It *should* have treated those > two issues as independent changes and separate commits. > > Maybe I'm mis-reading it. Mike? Peter? It does two things, but it's one problem. If you crawl over the whole package, you constantly pull tasks all over the package, which as you can see from the numbers hurts quite a lot. The only reason I can think of why pgbench might suffer is postgres's userspace spinlocks. If you always look for an idle core, you improve the odds that the wakeup won't preempt a lock holder, sending others into a long spin. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] i2c/scx200_*: replace printks with pr_s
Replace printks with pr_s, add pr_fmt()s to replace NAMEs
Signed-off-by: Jim Cromie
---
drivers/i2c/busses/scx200_acb.c | 18 ++
drivers/i2c/busses/scx200_i2c.c | 12 +++-
2 files changed, 17 insertions(+), 13 deletions(-)
diff --git a/drivers/i2c/busses/scx200_acb.c b/drivers/i2c/busses/scx200_acb.c
index 2eacb77..8851526 100644
--- a/drivers/i2c/busses/scx200_acb.c
+++ b/drivers/i2c/busses/scx200_acb.c
@@ -23,6 +23,8 @@
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*/
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
#include
#include
#include
@@ -398,7 +400,7 @@ static __devinit int scx200_acb_probe(struct
scx200_acb_iface *iface)
outb(0x70, ACBCTL2);
if (inb(ACBCTL2) != 0x70) {
- pr_debug(NAME ": ACBCTL2 readback failed\n");
+ pr_debug("ACBCTL2 readback failed\n");
return -ENXIO;
}
@@ -406,7 +408,7 @@ static __devinit int scx200_acb_probe(struct
scx200_acb_iface *iface)
val = inb(ACBCTL1);
if (val) {
- pr_debug(NAME ": disabled, but ACBCTL1=0x%02x\n",
+ pr_debug("disabled, but ACBCTL1=0x%02x\n",
val);
return -ENXIO;
}
@@ -417,7 +419,7 @@ static __devinit int scx200_acb_probe(struct
scx200_acb_iface *iface)
val = inb(ACBCTL1);
if ((val & ACBCTL1_NMINTE) != ACBCTL1_NMINTE) {
- pr_debug(NAME ": enabled, but NMINTE won't be set, "
+ pr_debug("enabled, but NMINTE won't be set, "
"ACBCTL1=0x%02x\n", val);
return -ENXIO;
}
@@ -433,7 +435,7 @@ static __devinit struct scx200_acb_iface
*scx200_create_iface(const char *text,
iface = kzalloc(sizeof(*iface), GFP_KERNEL);
if (!iface) {
- printk(KERN_ERR NAME ": can't allocate memory\n");
+ pr_err("can't allocate memory\n");
return NULL;
}
@@ -459,14 +461,14 @@ static int __devinit scx200_acb_create(struct
scx200_acb_iface *iface)
rc = scx200_acb_probe(iface);
if (rc) {
- printk(KERN_WARNING NAME ": probe failed\n");
+ pr_warning("probe failed\n");
return rc;
}
scx200_acb_reset(iface);
if (i2c_add_adapter(adapter) < 0) {
- printk(KERN_ERR NAME ": failed to register\n");
+ pr_err("failed to register\n");
return -ENODEV;
}
@@ -493,7 +495,7 @@ static struct scx200_acb_iface * __devinit
scx200_create_dev(const char *text,
return NULL;
if (!request_region(base, 8, iface->adapter.name)) {
- printk(KERN_ERR NAME ": can't allocate io 0x%lx-0x%lx\n",
+ pr_err("can't allocate io 0x%lx-0x%lx\n",
base, base + 8 - 1);
goto errout_free;
}
@@ -583,7 +585,7 @@ static __init void scx200_scan_isa(void)
static int __init scx200_acb_init(void)
{
- pr_debug(NAME ": NatSemi SCx200 ACCESS.bus Driver\n");
+ pr_debug("NatSemi SCx200 ACCESS.bus Driver\n");
/* First scan for ISA-based devices */
scx200_scan_isa(); /* XXX: should we care about errors? */
diff --git a/drivers/i2c/busses/scx200_i2c.c b/drivers/i2c/busses/scx200_i2c.c
index 7ee0d50..355a8a5 100644
--- a/drivers/i2c/busses/scx200_i2c.c
+++ b/drivers/i2c/busses/scx200_i2c.c
@@ -21,6 +21,8 @@
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*/
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
#include
#include
#include
@@ -88,17 +90,17 @@ static struct i2c_adapter scx200_i2c_ops = {
static int scx200_i2c_init(void)
{
- pr_debug(NAME ": NatSemi SCx200 I2C Driver\n");
+ pr_debug("NatSemi SCx200 I2C Driver\n");
if (!scx200_gpio_present()) {
- printk(KERN_ERR NAME ": no SCx200 gpio pins available\n");
+ pr_err("no SCx200 gpio pins available\n");
return -ENODEV;
}
- pr_debug(NAME ": SCL=GPIO%02u, SDA=GPIO%02u\n", scl, sda);
+ pr_debug("SCL=GPIO%02u, SDA=GPIO%02u\n", scl, sda);
if (scl == -1 || sda == -1 || scl == sda) {
- printk(KERN_ERR NAME ": scl and sda must be specified\n");
+ pr_err("scl and sda must be specified\n");
return -EINVAL;
}
@@ -107,7 +109,7 @@ static int scx200_i2c_init(void)
scx200_gpio_configure(sda, ~2, 5);
if (i2c_bit_add_bus(_i2c_ops) < 0) {
- printk(KERN_ERR NAME ": adapter %s registration failed\n",
+ pr_err("adapter %s registration failed\n",
scx200_i2c_ops.name);
return -ENODEV;
}
--
1.7.10.1.487.ga3935e6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
[PATCH v2 6/9] ACPI/pci_slot: update PCI slot information when PCI hotplug event happens
Currently the pci_slot driver doesn't update PCI slot information
when PCI device hotplug event happens, which may cause memory leak
and returning stale information to user.
So hook the BUS_NOTIFY_ADD_DEVICE/BUS_NOTIFY_DEL_DEVICE events to
update PCI slot information when PCI hotplug event happens.
Signed-off-by: Jiang Liu
Signed-off-by: Yijing Wang
---
drivers/acpi/pci_slot.c | 86 ++-
1 file changed, 78 insertions(+), 8 deletions(-)
diff --git a/drivers/acpi/pci_slot.c b/drivers/acpi/pci_slot.c
index e50e31a..96dcc19 100644
--- a/drivers/acpi/pci_slot.c
+++ b/drivers/acpi/pci_slot.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include
static bool debug;
@@ -123,12 +124,7 @@ struct callback_args {
/*
* register_slot
*
- * Called once for each SxFy object in the namespace. Don't worry about
- * calling pci_create_slot multiple times for the same pci_bus:device,
- * since each subsequent call simply bumps the refcount on the pci_slot.
- *
- * The number of calls to pci_destroy_slot from unregister_slot is
- * symmetrical.
+ * Called once for each SxFy object in the namespace.
*/
static acpi_status
register_slot(acpi_handle handle, u32 lvl, void *context, void **rv)
@@ -145,6 +141,15 @@ register_slot(acpi_handle handle, u32 lvl, void *context,
void **rv)
if (device < 0)
return AE_OK;
+ /* Avoid duplicated records for the same slot */
+ list_for_each_entry(slot, _list, list) {
+ pci_slot = slot->pci_slot;
+ if (pci_slot && pci_slot->bus == pci_bus &&
+ pci_slot->number == device) {
+ return AE_OK;
+ }
+ }
+
slot = kmalloc(sizeof(*slot), GFP_KERNEL);
if (!slot) {
err("%s: cannot allocate memory\n", __func__);
@@ -162,9 +167,7 @@ register_slot(acpi_handle handle, u32 lvl, void *context,
void **rv)
slot->root_handle = parent_context->root_handle;
slot->pci_slot = pci_slot;
INIT_LIST_HEAD(>list);
- mutex_lock(_list_lock);
list_add(>list, _list);
- mutex_unlock(_list_lock);
get_device(_bus->dev);
@@ -299,7 +302,9 @@ acpi_pci_slot_add(acpi_handle handle)
{
acpi_status status;
+ mutex_lock(_list_lock);
status = walk_root_bridge(handle, register_slot);
+ mutex_unlock(_list_lock);
if (ACPI_FAILURE(status))
err("%s: register_slot failure - %d\n", __func__, status);
@@ -354,17 +359,82 @@ static struct dmi_system_id acpi_pci_slot_dmi_table[]
__initdata = {
{}
};
+static void acpi_pci_slot_notify_add(struct pci_dev *dev)
+{
+ acpi_handle handle;
+ struct callback_args context;
+
+ if (!dev->subordinate)
+ return;
+
+ mutex_lock(_list_lock);
+ handle = DEVICE_ACPI_HANDLE(>dev);
+ context.root_handle = acpi_find_root_bridge_handle(dev);
+ if (handle && context.root_handle) {
+ context.pci_bus = dev->subordinate;
+ context.user_function = register_slot;
+ acpi_walk_namespace(ACPI_TYPE_DEVICE, handle, (u32)1,
+ register_slot, NULL, , NULL);
+ }
+ mutex_unlock(_list_lock);
+}
+
+static void acpi_pci_slot_notify_del(struct pci_dev *dev)
+{
+ struct acpi_pci_slot *slot, *tmp;
+ struct pci_bus *bus = dev->subordinate;
+
+ if (!bus)
+ return;
+
+ mutex_lock(_list_lock);
+ list_for_each_entry_safe(slot, tmp, _list, list)
+ if (slot->pci_slot && slot->pci_slot->bus == bus) {
+ list_del(>list);
+ pci_destroy_slot(slot->pci_slot);
+ put_device(>dev);
+ kfree(slot);
+ }
+ mutex_unlock(_list_lock);
+}
+
+static int acpi_pci_slot_notify_fn(struct notifier_block *nb,
+ unsigned long event, void *data)
+{
+ struct device *dev = data;
+
+ switch (event) {
+ case BUS_NOTIFY_ADD_DEVICE:
+ acpi_pci_slot_notify_add(to_pci_dev(dev));
+ break;
+ case BUS_NOTIFY_DEL_DEVICE:
+ acpi_pci_slot_notify_del(to_pci_dev(dev));
+ break;
+ default:
+ return NOTIFY_DONE;
+ }
+
+ return NOTIFY_OK;
+}
+
+static struct notifier_block acpi_pci_slot_notifier = {
+ .notifier_call = _pci_slot_notify_fn,
+};
+
static int __init
acpi_pci_slot_init(void)
{
dmi_check_system(acpi_pci_slot_dmi_table);
acpi_pci_register_driver(_pci_slot_driver);
+ bus_register_notifier(_bus_type, _pci_slot_notifier);
+
return 0;
}
static void __exit
acpi_pci_slot_exit(void)
{
+ bus_unregister_notifier(_bus_type, _pci_slot_notifier);
acpi_pci_unregister_driver(_pci_slot_driver);
}
--
1.7.9.5
--
To unsubscribe from this
[PATCH v2 7/9] PCI/acpiphp: update ACPI hotplug slot information when PCI hotplug happens
Currently the acpiphp driver fails to update hotplug slot information under
several conditions, such as:
1) The bridge device is removed through /sys/bus/pci/devices/.../remove
2) The bridge device is added/removed by PCI hotplug driver other than the
acpiphp driver itself. For example, if an IO expansion box with ACPI
hotplug slots available is hot-added by the pciehp driver, all ACPI
hotplug slots won't be discovered by the acpiphp driver.
So hook the BUS_NOTIFY_ADD_DEVICE/BUS_NOTIFY_DEL_DEVICE events to
update ACPI hotplug slot information when PCI hotplug event happens.
Signed-off-by: Jiang Liu
Signed-off-by: Yijing Wang
---
drivers/pci/hotplug/acpiphp_glue.c | 64 ++--
1 file changed, 61 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/hotplug/acpiphp_glue.c
b/drivers/pci/hotplug/acpiphp_glue.c
index 7be4ca5..1fb0eb7 100644
--- a/drivers/pci/hotplug/acpiphp_glue.c
+++ b/drivers/pci/hotplug/acpiphp_glue.c
@@ -61,6 +61,7 @@ static void handle_hotplug_event_bridge (acpi_handle, u32,
void *);
static void acpiphp_sanitize_bus(struct pci_bus *bus);
static void acpiphp_set_hpp_values(struct pci_bus *bus);
static void handle_hotplug_event_func(acpi_handle handle, u32 type, void
*context);
+static struct acpiphp_bridge *acpiphp_handle_to_bridge(acpi_handle handle);
/* callback routine to check for the existence of a pci dock device */
static acpi_status
@@ -382,7 +383,7 @@ static inline void config_p2p_bridge_flags(struct
acpiphp_bridge *bridge)
/* allocate and initialize host bridge data structure */
-static void add_host_bridge(acpi_handle *handle)
+static void add_host_bridge(acpi_handle handle)
{
struct acpiphp_bridge *bridge;
struct acpi_pci_root *root = acpi_pci_find_root(handle);
@@ -399,12 +400,14 @@ static void add_host_bridge(acpi_handle *handle)
init_bridge_misc(bridge);
}
-
/* allocate and initialize PCI-to-PCI bridge data structure */
-static void add_p2p_bridge(acpi_handle *handle)
+static void add_p2p_bridge(acpi_handle handle)
{
struct acpiphp_bridge *bridge;
+ if (acpiphp_handle_to_bridge(handle))
+ return;
+
bridge = kzalloc(sizeof(struct acpiphp_bridge), GFP_KERNEL);
if (bridge == NULL) {
err("out of memory\n");
@@ -1405,6 +1408,58 @@ find_root_bridges(acpi_handle handle, u32 lvl, void
*context, void **rv)
return AE_OK ;
}
+static void acpiphp_hp_notify_add(struct pci_dev *dev)
+{
+ acpi_handle handle = DEVICE_ACPI_HANDLE(>dev);
+
+ if (!dev->subordinate || !handle)
+ return;
+
+ /* check if this bridge has ejectable slots */
+ if (detect_ejectable_slots(handle) > 0) {
+ dbg("found PCI-to-PCI bridge at PCI %s\n", pci_name(dev));
+ add_p2p_bridge(handle);
+ }
+}
+
+static void acpiphp_hp_notify_del(struct pci_dev *dev)
+{
+ struct acpiphp_bridge *bridge, *tmp;
+ struct pci_bus *bus = dev->subordinate;
+
+ if (!bus)
+ return;
+
+ list_for_each_entry_safe(bridge, tmp, _list, list)
+ if (bridge->pci_bus == bus) {
+ cleanup_bridge(bridge);
+ break;
+ }
+}
+
+static int acpi_pci_hp_notify_fn(struct notifier_block *nb,
+unsigned long event, void *data)
+{
+ struct device *dev = data;
+
+ switch (event) {
+ case BUS_NOTIFY_ADD_DEVICE:
+ acpiphp_hp_notify_add(to_pci_dev(dev));
+ break;
+ case BUS_NOTIFY_DEL_DEVICE:
+ acpiphp_hp_notify_del(to_pci_dev(dev));
+ break;
+ default:
+ return NOTIFY_DONE;
+ }
+
+ return NOTIFY_OK;
+}
+
+static struct notifier_block acpi_pci_hp_notifier = {
+ .notifier_call = _pci_hp_notify_fn,
+};
+
static struct acpi_pci_driver acpi_pci_hp_driver = {
.add = add_bridge,
.remove = remove_bridge,
@@ -1425,6 +1480,8 @@ int __init acpiphp_glue_init(void)
else
acpi_pci_register_driver(_pci_hp_driver);
+ bus_register_notifier(_bus_type, _pci_hp_notifier);
+
return 0;
}
@@ -1436,6 +1493,7 @@ int __init acpiphp_glue_init(void)
*/
void acpiphp_glue_exit(void)
{
+ bus_unregister_notifier(_bus_type, _pci_hp_notifier);
acpi_pci_unregister_driver(_pci_hp_driver);
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 9/9] PCI/AER: update AER configuration when PCI hotplug event happens
From: Yijing Wang
The AER driver only configures downstream PCIe devices at driver
binding time and all hot-added PCIe devices won't be managed by
the AER driver. So hook PCIe device hotplug events to setup AER
configuration for hot-added PCIe devices.
Signed-off-by: Yijing Wang
Signed-off-by: Jiang Liu
---
drivers/pci/pcie/aer/aerdrv.c | 63 -
1 file changed, 62 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/pcie/aer/aerdrv.c b/drivers/pci/pcie/aer/aerdrv.c
index 030cf12..b70ec84 100644
--- a/drivers/pci/pcie/aer/aerdrv.c
+++ b/drivers/pci/pcie/aer/aerdrv.c
@@ -408,6 +408,55 @@ static void aer_error_resume(struct pci_dev *dev)
pci_write_config_dword(dev, pos + PCI_ERR_UNCOR_STATUS, status);
}
+static void acpi_pcie_aer_notify_dev(struct pcie_device *dev, bool enable)
+{
+ int rc, pos;
+ u32 val = 0;
+ struct pci_dev *pdev = dev->port;
+
+ if (dev->service != PCIE_PORT_SERVICE_AER)
+ return;
+ if (pci_pcie_type(pdev) == PCI_EXP_TYPE_ROOT_PORT)
+ return;
+ while (pci_pcie_type(pdev) != PCI_EXP_TYPE_ROOT_PORT) {
+ pdev = pdev->bus->self;
+ if (!pdev)
+ return;
+ }
+
+ pos = pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_ERR);
+ if (!pos)
+ return;
+ rc = pci_read_config_dword(pdev, pos + PCI_ERR_ROOT_COMMAND, );
+ if (rc || val == 0x || !(val & ROOT_PORT_INTR_ON_MESG_MASK))
+ return;
+
+ set_device_error_reporting(dev->port, );
+}
+
+static int acpi_pcie_aer_notify(struct notifier_block *nb,
+ unsigned long event, void *data)
+{
+ struct device *dev = data;
+
+ switch (event) {
+ case BUS_NOTIFY_ADD_DEVICE:
+ acpi_pcie_aer_notify_dev(to_pcie_device(dev), true);
+ break;
+ case BUS_NOTIFY_DEL_DEVICE:
+ acpi_pcie_aer_notify_dev(to_pcie_device(dev), false);
+ break;
+ default:
+ return NOTIFY_DONE;
+ }
+
+ return NOTIFY_OK;
+}
+
+static struct notifier_block acpi_pcie_aer_notifier = {
+ .notifier_call = _pcie_aer_notify,
+};
+
/**
* aer_service_init - register AER root service driver
*
@@ -415,9 +464,20 @@ static void aer_error_resume(struct pci_dev *dev)
*/
static int __init aer_service_init(void)
{
+ int ret;
+
if (!pci_aer_available() || aer_acpi_firmware_first())
return -ENXIO;
- return pcie_port_service_register();
+
+ ret = pcie_port_service_register();
+ if (!ret) {
+ ret = bus_register_notifier(_port_bus_type,
+ _pcie_aer_notifier);
+ if (ret)
+ pcie_port_service_unregister();
+ }
+
+ return ret;
}
/**
@@ -427,6 +487,7 @@ static int __init aer_service_init(void)
*/
static void __exit aer_service_exit(void)
{
+ bus_unregister_notifier(_port_bus_type, _pcie_aer_notifier);
pcie_port_service_unregister();
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 8/9] PCI/acpiphp: serialize access to the bridge_list list
Serialize access to the bridge_list in the acpiphp driver.
Signed-off-by: Jiang Liu
Signed-off-by: Yijing Wang
---
drivers/pci/hotplug/acpiphp_glue.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/pci/hotplug/acpiphp_glue.c
b/drivers/pci/hotplug/acpiphp_glue.c
index 1fb0eb7..348afd7 100644
--- a/drivers/pci/hotplug/acpiphp_glue.c
+++ b/drivers/pci/hotplug/acpiphp_glue.c
@@ -53,6 +53,7 @@
#include "../pci.h"
#include "acpiphp.h"
+static DEFINE_MUTEX(bridge_mutex);
static LIST_HEAD(bridge_list);
#define MY_NAME "acpiphp_glue"
@@ -497,8 +498,10 @@ static int add_bridge(acpi_handle handle)
}
/* search P2P bridges under this host bridge */
+ mutex_lock(_mutex);
status = acpi_walk_namespace(ACPI_TYPE_DEVICE, handle, (u32)1,
find_p2p_bridge, NULL, NULL, NULL);
+ mutex_unlock(_mutex);
if (ACPI_FAILURE(status))
warn("find_p2p_bridge failed (error code = 0x%x)\n", status);
@@ -595,6 +598,8 @@ static void remove_bridge(acpi_handle handle)
{
struct acpiphp_bridge *bridge;
+ mutex_lock(_mutex);
+
/* cleanup p2p bridges under this host bridge
in a depth-first manner */
acpi_walk_namespace(ACPI_TYPE_DEVICE, handle,
@@ -613,6 +618,8 @@ static void remove_bridge(acpi_handle handle)
else
acpi_remove_notify_handler(handle, ACPI_SYSTEM_NOTIFY,
handle_hotplug_event_bridge);
+
+ mutex_unlock(_mutex);
}
static int power_on_slot(struct acpiphp_slot *slot)
@@ -1415,11 +1422,13 @@ static void acpiphp_hp_notify_add(struct pci_dev *dev)
if (!dev->subordinate || !handle)
return;
+ mutex_lock(_mutex);
/* check if this bridge has ejectable slots */
if (detect_ejectable_slots(handle) > 0) {
dbg("found PCI-to-PCI bridge at PCI %s\n", pci_name(dev));
add_p2p_bridge(handle);
}
+ mutex_unlock(_mutex);
}
static void acpiphp_hp_notify_del(struct pci_dev *dev)
@@ -1430,11 +1439,13 @@ static void acpiphp_hp_notify_del(struct pci_dev *dev)
if (!bus)
return;
+ mutex_lock(_mutex);
list_for_each_entry_safe(bridge, tmp, _list, list)
if (bridge->pci_bus == bus) {
cleanup_bridge(bridge);
break;
}
+ mutex_unlock(_mutex);
}
static int acpi_pci_hp_notify_fn(struct notifier_block *nb,
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ 24/46] ACPI: export symbol acpi_get_table_with_size
On Sat, Sep 15, 2012 at 01:22:20AM +0100, Ben Hutchings wrote: > On Wed, 2012-09-12 at 16:39 -0700, Greg Kroah-Hartman wrote: > > From: Greg KH > > > > 3.0-stable review patch. If anyone has any objections, please let me know. > > > > -- > > > > From: Alex Deucher > > > > commit 4f81f986761a7663db7d24d24cd6ae68008f1fc2 upstream. > > > > We need it in the radeon drm module to fetch > > and verify the vbios image on UEFI systems. > > Unless you're planning going to include those radeon changes in the next > update, I don't see the point of this. Yes, they will be coming, I have a ton of drm patches to pick through that I haven't gotten to. This was just part of it, the rest will be in the next release. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 4/9] ACPI/pci_bind: correctly update binding relationship for PCI hotplug
From: Jiang Liu
Currently pci_bind.c is used to maintain binding relationship between
ACPI and PCI devices. But it's broken when handling PCI hotplug events.
For the acpiphp driver, it's designed to update the binding relationship
when PCI hotplug event happens, but the implementation is broken.
For PCI device hot-adding:
enable_device()
pci_scan_slot()
acpiphp_bus_add()
acpi_bus_add()
acpi_pci_bind()
acpi_get_pci_dev()
return NULL because dev->archdata.acpi_handle is
still unset
return without updating actual binding relationship
pci_bus_add_devices()
pci_bus_add_device()
device_add()
platform_notify()
acpi_bind_one()
set dev->archdata.acpi_handle
For PCI device hot-removal,
disable_device()
pci_stop_bus_device()
__pci_remove_bus_device()
acpiphp_bus_trim()
acpi_bus_remove()
acpi_pci_unbind()
return without really unbinding because PCI device has
already been destroyed
For other PCI hotplug drivers, they even don't bother to update binding
relationships. So hook into acpi_bind_one()/acpi_unbind_one() in
drivers/acpi/glue.c to update PCI<->ACPI binding relationship.
Signed-off-by: Jiang Liu
Signed-off-by: Yijing Wang
---
drivers/acpi/glue.c |6 ++-
drivers/acpi/internal.h |2 +
drivers/acpi/pci_bind.c | 101 +++
drivers/acpi/pci_root.c | 40 +--
4 files changed, 81 insertions(+), 68 deletions(-)
diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c
index 243ee85..4904700 100644
--- a/drivers/acpi/glue.c
+++ b/drivers/acpi/glue.c
@@ -121,7 +121,6 @@ acpi_handle acpi_get_child(acpi_handle parent, u64 address)
1, do_acpi_find_child, NULL, , NULL);
return find.handle;
}
-
EXPORT_SYMBOL(acpi_get_child);
/* Link ACPI devices with physical devices */
@@ -142,7 +141,6 @@ struct device *acpi_get_physical_device(acpi_handle handle)
return get_device(dev);
return NULL;
}
-
EXPORT_SYMBOL(acpi_get_physical_device);
static int acpi_bind_one(struct device *dev, acpi_handle handle)
@@ -162,6 +160,8 @@ static int acpi_bind_one(struct device *dev, acpi_handle
handle)
}
dev->archdata.acpi_handle = handle;
+ acpi_pci_bind_notify(dev->archdata.acpi_handle, dev, true);
+
status = acpi_bus_get_device(handle, _dev);
if (!ACPI_FAILURE(status)) {
int ret;
@@ -193,6 +193,8 @@ static int acpi_unbind_one(struct device *dev)
sysfs_remove_link(_dev->dev.kobj, "physical_node");
}
+ acpi_pci_bind_notify(dev->archdata.acpi_handle, dev, false);
+
acpi_detach_data(dev->archdata.acpi_handle,
acpi_glue_data_handler);
dev->archdata.acpi_handle = NULL;
diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
index ca75b9c..5396b20 100644
--- a/drivers/acpi/internal.h
+++ b/drivers/acpi/internal.h
@@ -93,4 +93,6 @@ static inline int suspend_nvs_save(void) { return 0; }
static inline void suspend_nvs_restore(void) {}
#endif
+void acpi_pci_bind_notify(acpi_handle handle, struct device *dev, bool bind);
+
#endif /* _ACPI_INTERNAL_H_ */
diff --git a/drivers/acpi/pci_bind.c b/drivers/acpi/pci_bind.c
index 2ef0409..320e698 100644
--- a/drivers/acpi/pci_bind.c
+++ b/drivers/acpi/pci_bind.c
@@ -35,40 +35,41 @@
#define _COMPONENT ACPI_PCI_COMPONENT
ACPI_MODULE_NAME("pci_bind");
-static int acpi_pci_unbind(struct acpi_device *device)
-{
- struct pci_dev *dev;
-
- dev = acpi_get_pci_dev(device->handle);
- if (!dev)
- goto out;
+static int acpi_pci_bind_cb(struct acpi_device *device);
+static int acpi_pci_unbind(struct acpi_device *device, struct pci_dev *dev)
+{
device_set_run_wake(>dev, false);
pci_acpi_remove_pm_notifier(device);
- if (!dev->subordinate)
- goto out;
+ if (dev->subordinate) {
+ acpi_pci_irq_del_prt(dev->subordinate);
+ device->ops.bind = NULL;
+ device->ops.unbind = NULL;
+ }
+
+ return 0;
+}
- acpi_pci_irq_del_prt(dev->subordinate);
+static int acpi_pci_unbind_cb(struct acpi_device *device)
+{
+ int rc = 0;
+ struct pci_dev *dev;
- device->ops.bind = NULL;
- device->ops.unbind = NULL;
+ dev = acpi_get_pci_dev(device->handle);
+ if (dev) {
+ rc = acpi_pci_unbind(device, dev);
+ pci_dev_put(dev);
+ }
-out:
- pci_dev_put(dev);
- return 0;
+ return rc;
}
-static int acpi_pci_bind(struct acpi_device *device)
+static int acpi_pci_bind(struct acpi_device *device, struct pci_dev *dev)
{
acpi_status status;
[PATCH v2 3/9] PCI: preserve dev->subordinate until pci_stop_dev() has been called
From: Yijing Wang
Changeset 2ed168eeb3edec029aa0eca5cb981d6376f931f9 "PCI: Fold stop and
remove helpers into their callers" has changed the behavior when
removing a PCI device.
Previously, for a PCI bridge device with secondary bus, dev->subordinate
is valid when calling PCI bus notification callbacks for
BUS_NOTIFY_ADD_DEVICE/BUS_NOTIFY_DEL_DEVICE events. Now dev->subordinate
has been reset to NULL when calling callbacks for BUS_NOTIFY_DEL_DEVICE
events, which may break some PCI bus notification callbacks.
So revert to the original behavior to keep dev->subordinate valid for
both BUS_NOTIFY_ADD_DEVICE events and BUS_NOTIFY_DEL_DEVICE events.
Signed-off-by: Yijing Wang
Signed-off-by: Jiang Liu
---
drivers/pci/remove.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/remove.c b/drivers/pci/remove.c
index 86a4636..6244956 100644
--- a/drivers/pci/remove.c
+++ b/drivers/pci/remove.c
@@ -79,16 +79,16 @@ void pci_stop_and_remove_bus_device(struct pci_dev *dev)
* iterator. Therefore, iterate in reverse so we remove the VFs
* first, then the PF.
*/
- if (bus) {
+ if (bus)
list_for_each_entry_safe_reverse(child, tmp,
>devices, bus_list)
pci_stop_and_remove_bus_device(child);
+ pci_stop_dev(dev);
+ if (bus) {
pci_remove_bus(bus);
dev->subordinate = NULL;
}
-
- pci_stop_dev(dev);
pci_destroy_dev(dev);
}
EXPORT_SYMBOL(pci_stop_and_remove_bus_device);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 5/9] ACPI/pci-bind: remove bind/unbind callbacks from acpi_device_ops
From: Jiang Liu
Now ACPI devices are created before/destroyed after corresponding PCI
devices, and acpi_platform_notify/acpi_platform_notify_remove will
update PCI<->ACPI binding relationship when creating/destroying PCI
devices, there's no need to invoke bind/unbind callbacks from ACPI
device probe/destroy routines anymore. So remove bind/unbind callbacks
from acpi_device_ops.
Signed-off-by: Jiang Liu
Signed-off-by: Yijing Wang
---
drivers/acpi/pci_bind.c | 100 +--
drivers/acpi/pci_root.c |9
drivers/acpi/scan.c | 21 +
include/acpi/acpi_bus.h |4 --
include/acpi/acpi_drivers.h |1 -
5 files changed, 23 insertions(+), 112 deletions(-)
diff --git a/drivers/acpi/pci_bind.c b/drivers/acpi/pci_bind.c
index 320e698..d18316a 100644
--- a/drivers/acpi/pci_bind.c
+++ b/drivers/acpi/pci_bind.c
@@ -35,57 +35,31 @@
#define _COMPONENT ACPI_PCI_COMPONENT
ACPI_MODULE_NAME("pci_bind");
-static int acpi_pci_bind_cb(struct acpi_device *device);
-
-static int acpi_pci_unbind(struct acpi_device *device, struct pci_dev *dev)
+static int acpi_pci_unbind(acpi_handle handle, struct pci_dev *dev)
{
- device_set_run_wake(>dev, false);
- pci_acpi_remove_pm_notifier(device);
+ struct acpi_device *acpi_dev;
- if (dev->subordinate) {
- acpi_pci_irq_del_prt(dev->subordinate);
- device->ops.bind = NULL;
- device->ops.unbind = NULL;
+ if (!acpi_bus_get_device(handle, _dev) && acpi_dev) {
+ device_set_run_wake(>dev, false);
+ pci_acpi_remove_pm_notifier(acpi_dev);
}
- return 0;
-}
-
-static int acpi_pci_unbind_cb(struct acpi_device *device)
-{
- int rc = 0;
- struct pci_dev *dev;
-
- dev = acpi_get_pci_dev(device->handle);
- if (dev) {
- rc = acpi_pci_unbind(device, dev);
- pci_dev_put(dev);
- }
+ if (dev->subordinate)
+ acpi_pci_irq_del_prt(dev->subordinate);
- return rc;
+ return 0;
}
-static int acpi_pci_bind(struct acpi_device *device, struct pci_dev *dev)
+static int acpi_pci_bind(acpi_handle handle, struct pci_dev *dev)
{
acpi_status status;
- acpi_handle handle;
struct pci_bus *bus;
+ struct acpi_device *acpi_dev;
- pci_acpi_add_pm_notifier(device, dev);
- if (device->wakeup.flags.run_wake)
- device_set_run_wake(>dev, true);
-
- /*
-* Install the 'bind' function to facilitate callbacks for
-* children of the P2P bridge.
-*/
- if (dev->subordinate) {
- ACPI_DEBUG_PRINT((ACPI_DB_INFO,
- "Device %04x:%02x:%02x.%d is a PCI bridge\n",
- pci_domain_nr(dev->bus), dev->bus->number,
- PCI_SLOT(dev->devfn), PCI_FUNC(dev->devfn)));
- device->ops.bind = acpi_pci_bind_cb;
- device->ops.unbind = acpi_pci_unbind_cb;
+ if (!acpi_bus_get_device(handle, _dev) && acpi_dev) {
+ pci_acpi_add_pm_notifier(acpi_dev, dev);
+ if (acpi_dev->wakeup.flags.run_wake)
+ device_set_run_wake(>dev, true);
}
/*
@@ -96,56 +70,24 @@ static int acpi_pci_bind(struct acpi_device *device, struct
pci_dev *dev)
*
* TBD: Can _PRTs exist within the scope of non-bridge PCI devices?
*/
- status = acpi_get_handle(device->handle, METHOD_NAME__PRT, );
+ status = acpi_get_handle(handle, METHOD_NAME__PRT, );
if (ACPI_SUCCESS(status)) {
if (dev->subordinate)
bus = dev->subordinate;
else
bus = dev->bus;
- acpi_pci_irq_add_prt(device->handle, bus);
+ acpi_pci_irq_add_prt(handle, bus);
}
return 0;
}
-static int acpi_pci_bind_cb(struct acpi_device *device)
-{
- int rc = 0;
- struct pci_dev *dev;
-
- dev = acpi_get_pci_dev(device->handle);
- if (dev) {
- rc = acpi_pci_bind(device, dev);
- pci_dev_put(dev);
- }
-
- return rc;
-}
-
-int acpi_pci_bind_root(struct acpi_device *device)
-{
- device->ops.bind = acpi_pci_bind_cb;
- device->ops.unbind = acpi_pci_unbind_cb;
-
- return 0;
-}
-
void acpi_pci_bind_notify(acpi_handle handle, struct device *dev, bool bind)
{
- struct acpi_device *acpi_dev;
-
- if (!dev_is_pci(dev))
- return;
- if (acpi_bus_get_device(handle, _dev) || !acpi_dev)
- return;
-
- if (acpi_dev->parent) {
- if (bind) {
- if (acpi_dev->parent->ops.bind)
- acpi_pci_bind(acpi_dev, to_pci_dev(dev));
- } else {
- if (acpi_dev->parent->ops.unbind)
-
[PATCH v2 2/9] PCI: split registration of PCI bus devices into two stages
When handling BUS_NOTIFY_ADD_DEVICE event for a PCI bridge device,
the notification handler can't hold reference count to the new PCI bus
because the device object for the new bus (pci_dev->subordinate->dev)
hasn't been initialized yet.
Split the registration of PCI bus device into two stages as below,
so that the event handler could hold reference count to the new PCI bus
when handling BUS_NOTIFY_ADD_DEVICE event.
1) device_initialize(_dev->dev)
2) device_initialize(_dev->subordinate->dev)
3) notify BUS_NOTIFY_ADD_DEVICE event for pci_dev
4) device_add(_dev->dev)
5) device_add(_dev->subordinate->dev)
Signed-off-by: Jiang Liu
---
drivers/pci/bus.c|2 +-
drivers/pci/probe.c |3 ++-
drivers/pci/remove.c | 10 +-
3 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/pci/bus.c b/drivers/pci/bus.c
index 4b0970b..11a5c28 100644
--- a/drivers/pci/bus.c
+++ b/drivers/pci/bus.c
@@ -189,7 +189,7 @@ int pci_bus_add_child(struct pci_bus *bus)
if (bus->bridge)
bus->dev.parent = bus->bridge;
- retval = device_register(>dev);
+ retval = device_add(>dev);
if (retval)
return retval;
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 5dbad03..ddc8f7f 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -464,6 +464,7 @@ static struct pci_bus * pci_alloc_bus(void)
INIT_LIST_HEAD(>resources);
b->max_bus_speed = PCI_SPEED_UNKNOWN;
b->cur_bus_speed = PCI_SPEED_UNKNOWN;
+ device_initialize(>dev);
}
return b;
}
@@ -1672,7 +1673,7 @@ struct pci_bus *pci_create_root_bus(struct device
*parent, int bus,
b->dev.class = _class;
b->dev.parent = b->bridge;
dev_set_name(>dev, "%04x:%02x", pci_domain_nr(b), bus);
- error = device_register(>dev);
+ error = device_add(>dev);
if (error)
goto class_dev_reg_err;
diff --git a/drivers/pci/remove.c b/drivers/pci/remove.c
index 37b9407..86a4636 100644
--- a/drivers/pci/remove.c
+++ b/drivers/pci/remove.c
@@ -48,11 +48,11 @@ void pci_remove_bus(struct pci_bus *bus)
list_del(>node);
pci_bus_release_busn_res(bus);
up_write(_bus_sem);
- if (!bus->is_added)
- return;
-
- pci_remove_legacy_files(bus);
- device_unregister(>dev);
+ if (bus->is_added) {
+ pci_remove_legacy_files(bus);
+ device_del(>dev);
+ }
+ put_device(>dev);
}
EXPORT_SYMBOL(pci_remove_bus);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/9] PCI: make PCI device create/destroy logic symmetric
According to device model documentation, the way to create/destroy PCI
devices should be symmetric.
/**
* device_del - delete device from system.
* @dev: device.
*
* This is the first part of the device unregistration
* sequence. This removes the device from the lists we control
* from here, has it removed from the other driver model
* subsystems it was added to in device_add(), and removes it
* from the kobject hierarchy.
*
* NOTE: this should be called manually _iff_ device_add() was
* also called manually.
*/
The rule is to either use
1) device_register()/device_unregister()
or
2) device_initialize()/device_add()/device_del()/put_device().
So change PCI core logic to follow the rule and get rid of the redundant
pci_dev_get()/pci_dev_put() pair.
Signed-off-by: Jiang Liu
Acked-by: Bjorn Helgaas
---
drivers/pci/probe.c |1 -
drivers/pci/remove.c |4 ++--
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 2396111..5dbad03 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1293,7 +1293,6 @@ void pci_device_add(struct pci_dev *dev, struct pci_bus
*bus)
{
device_initialize(>dev);
dev->dev.release = pci_release_dev;
- pci_dev_get(dev);
dev->dev.dma_mask = >dma_mask;
dev->dev.dma_parms = >dma_parms;
diff --git a/drivers/pci/remove.c b/drivers/pci/remove.c
index 4f9ca91..37b9407 100644
--- a/drivers/pci/remove.c
+++ b/drivers/pci/remove.c
@@ -22,7 +22,7 @@ static void pci_stop_dev(struct pci_dev *dev)
if (dev->is_added) {
pci_proc_detach_device(dev);
pci_remove_sysfs_dev_files(dev);
- device_unregister(>dev);
+ device_del(>dev);
dev->is_added = 0;
}
@@ -37,7 +37,7 @@ static void pci_destroy_dev(struct pci_dev *dev)
up_write(_bus_sem);
pci_free_resources(dev);
- pci_dev_put(dev);
+ put_device(>dev);
}
void pci_remove_bus(struct pci_bus *bus)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/9] enhance PCI related drivers to handle hotplug events
Several PCI related drivers, such as pci_bind, pci_slot, acpiphp and aerdrv, don't handle PCI device hotplug events, which may cause stale state and even system crashes. This patch set registers bus notification callbacks to update driver states when PCI device hotplug happens. V1->V2: Hook pcie_port_bus_type instead of pci_bus_type for aerdrv Jiang Liu (7): PCI: make PCI device create/destroy logic symmetric PCI: split registration of PCI bus devices into two stages ACPI/pci_bind: correctly update binding relationship for PCI hotplug ACPI/pci-bind: remove bind/unbind callbacks from acpi_device_ops ACPI/pci_slot: update PCI slot information when PCI hotplug event happens PCI/acpiphp: update ACPI hotplug slot information when PCI hotplug happens PCI/acpiphp: serialize access to the bridge_list list Yijing Wang (2): PCI: preserve dev->subordinate until pci_stop_dev() has been called PCI/AER: update AER configuration when PCI hotplug event happens drivers/acpi/glue.c|6 ++- drivers/acpi/internal.h|2 + drivers/acpi/pci_bind.c| 85 --- drivers/acpi/pci_root.c| 31 - drivers/acpi/pci_slot.c| 86 drivers/acpi/scan.c| 21 + drivers/pci/bus.c |2 +- drivers/pci/hotplug/acpiphp_glue.c | 75 +-- drivers/pci/pcie/aer/aerdrv.c | 63 +- drivers/pci/probe.c|4 +- drivers/pci/remove.c | 20 - include/acpi/acpi_bus.h|4 -- include/acpi/acpi_drivers.h|1 - 13 files changed, 262 insertions(+), 138 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [PATCH] IRQ: Add a check for uninitialized irqs.
Hi,
* On Mon, Sep 10, 2012 at 09:41:49AM -0400, Paul Gortmaker
wrote:
On 12-09-09 03:25 PM, raghu.prabh...@gmail.com wrote:
From: Raghavendra D Prabhu
Errors like "do_IRQ: 0.84 No Irq handler for vector (irq -1)" have been reported
earlier filling up the console/logs. So this adds a condition to check for
Reported by who, and where, and on what hardware, and under what
circumstances?
I have seen it reported in many places like
https://bugzilla.redhat.com/show_bug.cgi?id=225399 and
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/480997
You are adding another if statement to the hot path of do_IRQ just
to mask some random unknown symptom. instead of trying to understand
(and then solve) what the real breakage is. Which is not the right
approach.
I just realized that handler_irq checks for < NR_IRQS where the
underflow will fail and will return. So this patch is not required.
However, I think we need to fix the unsigned / int mixup by
assigning vector_irq[..] to NR_IRQS+1 as guard value and
changing unsigned to signed as in patch.
Paul.
--
uninitialized irqs so that it exits early and doesn't proceed further. Also, irq
is made a signed integer, since if it is not mapped to a vector, it will be
assigned -1 which will be UINT_MAX otherwise.
Signed-off-by: Raghavendra D Prabhu
---
arch/x86/kernel/irq.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/arch/x86/kernel/irq.c b/arch/x86/kernel/irq.c
index d44f782..ddba63a 100644
--- a/arch/x86/kernel/irq.c
+++ b/arch/x86/kernel/irq.c
@@ -184,21 +184,24 @@ unsigned int __irq_entry do_IRQ(struct pt_regs *regs)
/* high bit used in ret_from_ code */
unsigned vector = ~regs->orig_ax;
- unsigned irq;
+ int irq;
irq_enter();
exit_idle();
- irq = __this_cpu_read(vector_irq[vector]);
+ if (unlikely((irq = __this_cpu_read(vector_irq[vector])) == -1)) {
+ pr_emerg_ratelimited("IRQ handler not setup for vector %u",
vector);
+ goto err_exit;
+ }
if (!handle_irq(irq, regs)) {
ack_APIC_irq();
- if (printk_ratelimit())
- pr_emerg("%s: %d.%d No irq handler for vector (irq
%d)\n",
- __func__, smp_processor_id(), vector, irq);
+ pr_emerg_ratelimited("%s: %d.%d No irq handler for vector (irq
%u)\n",
+ __func__, smp_processor_id(), vector, irq);
}
+err_exit:
irq_exit();
set_irq_regs(old_regs);
Regards,
--
Raghavendra Prabhu
GPG Id : 0xD72BE977
Fingerprint: B93F EBCB 8E05 7039 CD3C A4B8 A616 DCA1 D72B E977
www: wnohang.net
pgptmBC2xewUs.pgp
Description: PGP signature
Re: [RFC,PATCH v2] efi: Add support for a UEFI variable filesystem
於 四，2012-09-13 於 21:41 -0700，H. Peter Anvin 提到：
> On 09/13/2012 08:45 PM, joeyli wrote:
> > Hi Peter,
> >
> > 於 四，2012-09-13 於 09:52 -0400，Peter Jones 提到：
> >> On Thu, 2012-09-13 at 16:10 +0800, joeyli wrote:
> >>
> >>> Do we have plan to create a new kobject add to /sys/firmware/efi for
> >>> provide a fixed mount point to efivars fs?
> >>> e.g. /sys/firmware/efi/efivars
> >>>
> >>> Or we just direct reuse current /sys/firmeware/efi/vars? But, that means
> >>> we need think for the backward compatibility if choice reuse vars
> >>> folder.
> >>
> >> I'm not sure that's a terribly large concern - if you haven't updated
> >> your tools to use the new efivars, don't mount the new efivars.
> >>
> >
> > Thanks for your comment!
> >
>
> I think it is wrong. The new API should have a different path.
>
> -hpa
>
OK, so, if still keep the old API and have new mount point for UEFI
variable filesystem. Then how about add this simple patch for create new
mount point to /sys/firmware/efi/efivars.
Thanks a lot!
Joey Lee
>From 5e64382a9a4ad538dd5ca94072d19c7a70e4c650 Mon Sep 17 00:00:00 2001
From: Lee, Chun-Yi
Date: Sat, 15 Sep 2012 10:33:46 +0800
Subject: [PATCH] efi: add efivars kobject to efi sysfs folder
UEFI variable filesystem need a new mount point, so this patch add
efivars kobject to efi_kobj for create a /sys/firmware/efi/efivars
folder.
Signed-off-by: Lee, Chun-Yi
---
drivers/firmware/efivars.c | 11 +++
include/linux/efi.h|1 +
2 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/firmware/efivars.c b/drivers/firmware/efivars.c
index 1e1aad0..7c1234e 100644
--- a/drivers/firmware/efivars.c
+++ b/drivers/firmware/efivars.c
@@ -1487,6 +1487,7 @@ void unregister_efivars(struct efivars *efivars)
sysfs_remove_bin_file(>kset->kobj, efivars->del_var);
kfree(efivars->new_var);
kfree(efivars->del_var);
+ kobject_put(efivars->kobject);
kset_unregister(efivars->kset);
}
EXPORT_SYMBOL_GPL(unregister_efivars);
@@ -1518,6 +1519,13 @@ int register_efivars(struct efivars *efivars,
goto out;
}
+ efivars->kobject = kobject_create_and_add("efivars", parent_kobj);
+ if (!efivars->kobject) {
+ pr_err("efivars: Subsystem registration failed.\n");
+ error = -ENOMEM;
+ goto err_unreg_vars;
+ }
+
/*
* Per EFI spec, the maximum storage allocated for both
* the variable name and variable data is 1024 bytes.
@@ -1562,6 +1570,9 @@ int register_efivars(struct efivars *efivars,
register_filesystem(_fs_type);
+err_unreg_vars:
+ kset_unregister(efivars->kset);
+
out:
kfree(variable_name);
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 1829a97..c993f54 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -654,6 +654,7 @@ struct efivars {
spinlock_t lock;
struct list_head list;
struct kset *kset;
+ struct kobject *kobject;
struct bin_attribute *new_var, *del_var;
const struct efivar_operations *ops;
struct efivar_entry *walk_entry;
--
1.7.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC,PATCH v2] efi: Add support for a UEFI variable filesystem
於 二，2012-09-11 於 15:23 +0800，lee joey 提到： > From: Matthew Garrett > > The existing EFI variables code only supports variables of up to 1024 > bytes. This limitation existed in version 0.99 of the EFI > specification, > but was removed before any full releases. Since variables can now be > larger than a single page, sysfs isn't the best interface for this. > So, > instead, let's add a filesystem. Variables can be read, written and > created, with the first 4 bytes of each variable representing its UEFI > attributes. The create() method doesn't actually commit to flash since > zero-length variables can't exist per-spec. > > Updates from Jeremy Kerr . > > Signed-off-by: Matthew Garrett > Signed-off-by: Jeremy Kerr I and Gary tested create, update, delete unauthenticated variable, works fine. Tested-by: Lee, Chun-Yi Thanks a lot! Joey Lee -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Getting debugfs mountpoint?
On Fri, Sep 14, 2012 at 07:17:12PM -0700, Jacob Sowles wrote: > The first instance of my code calls debugfs_create_file and stores a > pointer to the dentry of that directory. But when the second instance > calls debugfs_create_file, the function returns NULL because that > directory already exists, so it doesn't return the dentry that I need. ... and? Ever heard of that thing called "global variable"? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC 1/1] kvm: Use vcpu_id as pivot instead of last boosted vcpu in PLE handler
On 09/02/2012 09:59 PM, Rik van Riel wrote: On 09/02/2012 06:12 AM, Gleb Natapov wrote: On Thu, Aug 30, 2012 at 12:51:01AM +0530, Raghavendra K T wrote: The idea of starting from next vcpu (source of yield_to + 1) seem to work well for overcomitted guest rather than using last boosted vcpu. We can also remove per VM variable with this approach. Iteration for eligible candidate after this patch starts from vcpu source+1 and ends at source-1 (after wrapping) Thanks Nikunj for his quick verification of the patch. Please let me know if this patch is interesting and makes sense. This last_boosted_vcpu thing caused us trouble during attempt to implement vcpu destruction. It is good to see it removed from this POV. I like this implementation. It should achieve pretty much the same as my old code, but without the downsides and without having to keep the same amount of global state. I able to test this on 3.6-rc5 (where I do not see inconsistency may be it was my bad to go with rc1), with 32 guest 1x and 2x overcommit scenario Here is the result on 16 core ple machine (with HT 32 thread) x240 machine base = 3.6-rc5 + ple handler improvement patch patched = base + vcpuid usage patch +---+---+---++---+ ebizzy (records/sec higher is better) +---+---+---++---+ base stdev patchedstdev%improve +---+---+---++---+ 1x 11293.3750 624.4378 11242.8750 583.1757-0.44716 2x 3641.8750 468.94004088.8750 290.547012.27390 +---+---+---++---+ Avi, Marcelo.. any comments on this? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] cgroup TODOs
Quoting Aristeu Rozanski (a...@ruivo.org):
> Tejun,
> On Thu, Sep 13, 2012 at 01:58:27PM -0700, Tejun Heo wrote:
> > memcg can be handled by memcg people and I can handle cgroup_freezer
> > and others with help from the authors. The problematic one is
> > blkio. If anyone is interested in working on blkio, please be my
> > guest. Vivek? Glauber?
>
> if Serge is not planning to do it already, I can take a look in device_cgroup.
That's fine with me, thanks.
> also, heard about the desire of having a device namespace instead with
> support for translation ("sda" -> "sdf"). If anyone see immediate use for
> this please let me know.
Before going down this road, I'd like to discuss this with at least you,
me, and Eric Biederman (cc:d) as to how it relates to a device namespace.
thanks,
-serge
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [ 44/85] ACPI: export symbol acpi_get_table_with_size
On Wed, 2012-09-12 at 16:36 -0700, Greg Kroah-Hartman wrote: > From: Greg KH > > 3.4-stable review patch. If anyone has any objections, please let me know. > > -- > > From: Alex Deucher > > commit 4f81f986761a7663db7d24d24cd6ae68008f1fc2 upstream. > > We need it in the radeon drm module to fetch > and verify the vbios image on UEFI systems. Same as for 3.0, this seems pointless without the dependent radeon changes: 268ba0a drm/radeon: implement ACPI VFCT vbios fetch (v3) 7c3906d drm/radeon: convert radeon vfct code to use acpi_get_table_with_size c61e277 drm/radeon: split ATRM support out from the ATPX handler (v3) (For 3.2 I also needed these fixes from 3.3: a3f83ab drm/radeon: fix invalid memory access in radeon_atrm_get_bios() 211fa4f drm/radeon: finish getting bios earlier de47a9c drm/radeon: fix use after free in ATRM bios reading code. but I don't know whether those would be sufficient to backport this lot to 3.0.) Ben. > Signed-off-by: Alex Deucher > Signed-off-by: Greg Kroah-Hartman > > --- > drivers/acpi/acpica/tbxface.c |1 + > 1 file changed, 1 insertion(+) > > --- a/drivers/acpi/acpica/tbxface.c > +++ b/drivers/acpi/acpica/tbxface.c > @@ -436,6 +436,7 @@ acpi_get_table_with_size(char *signature > > return (AE_NOT_FOUND); > } > +ACPI_EXPORT_SYMBOL(acpi_get_table_with_size) > > acpi_status > acpi_get_table(char *signature, > > > -- > To unsubscribe from this list: send the line "unsubscribe stable" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Ben Hutchings Logic doesn't apply to the real world. - Marvin Minsky signature.asc Description: This is a digitally signed message part
Re: Getting debugfs mountpoint?
debugfs_create_dir, rather. Not debugfs_create_file. On Fri, Sep 14, 2012 at 7:17 PM, Jacob Sowles wrote: > The first instance of my code calls debugfs_create_file and stores a > pointer to the dentry of that directory. But when the second instance > calls debugfs_create_file, the function returns NULL because that > directory already exists, so it doesn't return the dentry that I need. > > On Fri, Sep 14, 2012 at 7:11 PM, Al Viro wrote: >> On Fri, Sep 14, 2012 at 07:07:43PM -0700, Jacob Sowles wrote: >>> Multiple instances of my code can be run simultaneously, and all >>> instances use the same debugfs directory, so I need the path to the >>> debugfs root directory so that I can use filp_open to get the dentry >>> for that directory. >> >> What's wrong with just storing a pointer to that dentry in a variable? >> And what do you want an opened file (of a directory, at that) on debugfs? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Getting debugfs mountpoint?
The first instance of my code calls debugfs_create_file and stores a pointer to the dentry of that directory. But when the second instance calls debugfs_create_file, the function returns NULL because that directory already exists, so it doesn't return the dentry that I need. On Fri, Sep 14, 2012 at 7:11 PM, Al Viro wrote: > On Fri, Sep 14, 2012 at 07:07:43PM -0700, Jacob Sowles wrote: >> Multiple instances of my code can be run simultaneously, and all >> instances use the same debugfs directory, so I need the path to the >> debugfs root directory so that I can use filp_open to get the dentry >> for that directory. > > What's wrong with just storing a pointer to that dentry in a variable? > And what do you want an opened file (of a directory, at that) on debugfs? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Getting debugfs mountpoint?
On Fri, Sep 14, 2012 at 07:07:43PM -0700, Jacob Sowles wrote: > Multiple instances of my code can be run simultaneously, and all > instances use the same debugfs directory, so I need the path to the > debugfs root directory so that I can use filp_open to get the dentry > for that directory. What's wrong with just storing a pointer to that dentry in a variable? And what do you want an opened file (of a directory, at that) on debugfs? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Getting debugfs mountpoint?
Multiple instances of my code can be run simultaneously, and all instances use the same debugfs directory, so I need the path to the debugfs root directory so that I can use filp_open to get the dentry for that directory. Jacob On Fri, Sep 14, 2012 at 6:57 PM, Al Viro wrote: > On Fri, Sep 14, 2012 at 06:49:01PM -0700, Jacob Sowles wrote: >> Is there an easy way to get the path to where debugfs is mounted? I >> found a function called debugfs_find_mountpoint(), which is exactly >> what I want, but it’s not exported, so I can’t use it. The only >> exported debugfs functions that I could find are the ones that create, >> remove, etc. > > More to the point, it's a userland function. Why would you want that > kernel-side? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Getting debugfs mountpoint?
On Fri, Sep 14, 2012 at 06:49:01PM -0700, Jacob Sowles wrote: > Is there an easy way to get the path to where debugfs is mounted? I > found a function called debugfs_find_mountpoint(), which is exactly > what I want, but it’s not exported, so I can’t use it. The only > exported debugfs functions that I could find are the ones that create, > remove, etc. More to the point, it's a userland function. Why would you want that kernel-side? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Getting debugfs mountpoint?
Is there an easy way to get the path to where debugfs is mounted? I found a function called debugfs_find_mountpoint(), which is exactly what I want, but it’s not exported, so I can’t use it. The only exported debugfs functions that I could find are the ones that create, remove, etc. Jacob -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] fs/buffer.c: Revoke LRU when trying to drop buffers
On Tue, 11 Sep 2012, Laura Abbott wrote:
> When a buffer is added to the LRU list, a reference is taken which is
> not dropped until the buffer is evicted from the LRU list. This is the
> correct behavior, however this LRU reference will prevent the buffer
> from being dropped. This means that the buffer can't actually be dropped
> until it is selected for eviction. There's no bound on the time spent
> on the LRU list, which means that the buffer may be undroppable for
> very long periods of time. Given that migration involves dropping
> buffers, the associated page is now unmigratible for long periods of
> time as well.
Disclaimer: I'm no expert on buffer_heads, and haven't studied your
patch. But it seems to me that this is an issue with the (unnamed)
filesystem you use, rather than a problem to be solved in drop_buffers().
extN, gfs2, ntfs, ocfs2 and xfs set .migratepage = buffer_migrate_page,
and I cannot see that page migration involves drop_buffers() at all in
that case: it transfers the buffer_heads from the old page to the new,
whether they're busy or not, with no attempt to free them.
Maybe your filesystem can be converted, with or without some extra help,
to buffer_migrate_page() instead of the default fallback_migrate_page():
which indeed has to play safe, doing the try_to_release_page() you see.
Maybe ask on the mailing list for your filesystem?
Hugh
> CMA relies on being able to migrate a specific range
> of pages, so these these types of failures make CMA significantly
> less reliable, especially under high filesystem usage.
>
> Rather than waiting for the LRU algorithm to eventually kick out
> the buffer, explicitly remove the buffer from the LRU list when trying
> to drop it. There is still the possibility that the buffer
> could be added back on the list, but that indicates the buffer is
> still in use and would probably have other 'in use' indicates to
> prevent dropping.
>
> Signed-off-by: Laura Abbott
> ---
> fs/buffer.c | 38 ++
> 1 file changed, 38 insertions(+)
>
> diff --git a/fs/buffer.c b/fs/buffer.c
> index ad5938c..daa0c3d 100644
> --- a/fs/buffer.c
> +++ b/fs/buffer.c
> @@ -1399,12 +1399,49 @@ static bool has_bh_in_lru(int cpu, void *dummy)
> return 0;
> }
>
> +static void __evict_bh_lru(void *arg)
> +{
> + struct bh_lru *b = _cpu_var(bh_lrus);
> + struct buffer_head *bh = arg;
> + int i;
> +
> + for (i = 0; i < BH_LRU_SIZE; i++) {
> + if (b->bhs[i] == bh) {
> + brelse(b->bhs[i]);
> + b->bhs[i] = NULL;
> + goto out;
> + }
> + }
> +out:
> + put_cpu_var(bh_lrus);
> +}
> +
> +static bool bh_exists_in_lru(int cpu, void *arg)
> +{
> + struct bh_lru *b = per_cpu_ptr(_lrus, cpu);
> + struct buffer_head *bh = arg;
> + int i;
> +
> + for (i = 0; i < BH_LRU_SIZE; i++) {
> + if (b->bhs[i] == bh)
> + return 1;
> + }
> +
> + return 0;
> +
> +}
> void invalidate_bh_lrus(void)
> {
> on_each_cpu_cond(has_bh_in_lru, invalidate_bh_lru, NULL, 1, GFP_KERNEL);
> }
> EXPORT_SYMBOL_GPL(invalidate_bh_lrus);
>
> +void evict_bh_lrus(struct buffer_head *bh)
> +{
> + on_each_cpu_cond(bh_exists_in_lru, __evict_bh_lru, bh, 1, GFP_ATOMIC);
> +}
> +EXPORT_SYMBOL_GPL(evict_bh_lrus);
> +
> void set_bh_page(struct buffer_head *bh,
> struct page *page, unsigned long offset)
> {
> @@ -3052,6 +3089,7 @@ drop_buffers(struct page *page, struct buffer_head
> **buffers_to_free)
>
> bh = head;
> do {
> + evict_bh_lrus(bh);
> if (buffer_write_io_error(bh) && page->mapping)
> set_bit(AS_EIO, >mapping->flags);
> if (buffer_busy(bh))
> --
> 1.7.11.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [PATCH 2/3] block: Fix not tracing all device plug-operation.
On 2012-08-10 21:09 Jens Axboe Wrote:
>On 08/10/2012 01:46 PM, Jianpeng Ma wrote:
>> If process handled two or more devices,there will not be trace some
>> devices plug-operation.
>>
>> Signed-off-by: Jianpeng Ma
>> ---
>> block/blk-core.c | 16 +++-
>> 1 file changed, 15 insertions(+), 1 deletion(-)
>>
>> diff --git a/block/blk-core.c b/block/blk-core.c
>> index 7a3abc6..034f186 100644
>> --- a/block/blk-core.c
>> +++ b/block/blk-core.c
>> @@ -1521,11 +1521,25 @@ get_rq:
>> struct request *__rq;
>>
>> __rq = list_entry_rq(plug->list.prev);
>> -if (__rq->q != q)
>> +if (__rq->q != q) {
>> plug->should_sort = 1;
>> +trace_block_plug(q);
>> +}
>> +} else {
>> +struct request *__rq;
>> +list_for_each_entry_reverse(__rq, >list,
>> +queuelist) {
>> +if (__rq->q == q) {
>> +list_add_tail(>queuelist,
>> +&__rq->queuelist);
>> +goto stat_acct;
>
>Did you verify this? It doesn't look right to me. You browse the list in
>reverse, which means __rq is the first one that has a matching q. Then
>you add the new req IN FRONT of that. You would want list_add() here
>instead, adding it as the last member of that q string, not in the
>middle.
>
>--
>Jens Axboe
>
Hi all:
How about those patches? Ok or wrong?
Thanks!N�Р骒r��yb�X�肚�v�^�)藓{.n�+�伐�{��赙zXФ�≤�}��财�z�:+v�����赙zZ+��+zf＂�h���~i���z� �wア�?�ㄨ��&�)撷f��^j谦y�m��@A�a囤�
0鹅h���i
Re: [PATCH 0/3] Remove jiffies clocksource's dependency on CLOCK_TICK_RATE
On 09/14/2012 06:05 PM, John Stultz wrote: Just wanted to send this out for initial review and comments. Gah. And I forgot to add the [RFC] header to my mails to make this clear. Hopefully this doesn't confuse anyone. These are not yet ready for submission! Just wanting feedback on the approach! thanks -john -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/3] jiffies: Remove compile time assumptions about CLOCK_TICK_RATE
CLOCK_TICK_RATE is used to accurately caclulate exactly how
a tick will be at a given HZ.
This is useful, because while we'd expect NSEC_PER_SEC/HZ,
the underlying hardware will have some granularity limit,
so we won't be able to have exactly HZ ticks per second.
This slight error can cause timekeeping quality problems
when using the jiffies or other jiffies driven clocksources.
Thus we currently use compile time CLOCK_TICK_RATE value to
generate SHIFTED_HZ and NSEC_PER_JIFFIES, which we then use
to adjust the jiffies clocksource to correct this error.
Unfortunately though, since CLOCK_TICK_RATE is a compile
time value, and the jiffies clocksource is registered very
early during boot, there are a number of cases where there
are different possible hardware timers that have different
tick rates. This causes problems in cases like ARM where
there are numerous different types of hardware, each having
their own compile-time CLOCK_TICK_RATE, making it hard to
accurately support different hardware with a single kernel.
For the most part, this doesn't matter all that much, as not
too many systems actually utilize the jiffies or jiffies driven
clocksource. Usually there are other highres clocksources
who's granularity error is negligable.
Even so, we have some complicated calcualtions that we do
everywhere to handle these edge cases.
This patch removes the compile time SHIFTED_HZ value, and
introduces a register_refined_jiffies() function. This results
in the default jiffies clock as being assumed a perfect HZ
freq, and allows archtectures that care about jiffies accuracy
to call register_refined_jiffies() with the tick rate, specified
dynamically at boot.
This allows us, where necessary, to not have a compile time
CLOCK_TICK_RATE constant, simplifies the jiffies code, and
still provides a way to have an accurate jiffies clock.
NOTE: Since this patch does not add register_refinied_jiffies()
calls for every arch, it may cause time quality regressions
in some cases. Its likely these will not be noticable, but
if they are an issue, adding the following to the end of
setup_arch() should resolve the regression:
register_refinied_jiffies(CLOCK_TICK_RATE)
Cc: Catalin Marinas
Cc: Arnd Bergmann
Cc: Richard Cochran
Cc: Prarit Bhargava
Cc: Thomas Gleixner
Signed-off-by: John Stultz
---
arch/x86/kernel/setup.c |3 +++
include/linux/jiffies.h | 15 ++-
kernel/time/jiffies.c | 32 +++-
3 files changed, 36 insertions(+), 14 deletions(-)
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index f4b9b80..4062f15 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -68,6 +68,7 @@
#include
#include
#include
+#include
#include
@@ -1034,6 +1035,8 @@ void __init setup_arch(char **cmdline_p)
mcheck_init();
arch_init_ideal_nops();
+
+ register_refined_jiffies(CLOCK_TICK_RATE);
}
#ifdef CONFIG_X86_32
diff --git a/include/linux/jiffies.h b/include/linux/jiffies.h
index 4a7e386..388edb5 100644
--- a/include/linux/jiffies.h
+++ b/include/linux/jiffies.h
@@ -51,21 +51,10 @@
#define SH_DIV(NOM,DEN,LSH) ( (((NOM) / (DEN)) << (LSH)) \
+ NOM) % (DEN)) << (LSH)) + (DEN) / 2) /
(DEN))
-#ifdef CLOCK_TICK_RATE
-/* LATCH is used in the interval timer and ftape setup. */
-# define LATCH ((CLOCK_TICK_RATE + HZ/2) / HZ) /* For divider */
-
-/*
- * HZ is the requested value. However the CLOCK_TICK_RATE may not allow
- * for exactly HZ. So SHIFTED_HZ is high res HZ ("<< 8" is for accuracy)
- */
-# define SHIFTED_HZ (SH_DIV(CLOCK_TICK_RATE, LATCH, 8))
-#else
-# define SHIFTED_HZ (HZ << 8)
-#endif
+extern int register_refined_jiffies(long clock_tick_rate);
/* TICK_NSEC is the time between ticks in nsec assuming SHIFTED_HZ */
-#define TICK_NSEC (SH_DIV(100UL * 1000, SHIFTED_HZ, 8))
+#define TICK_NSEC ((NSEC_PER_SEC+HZ/2)/HZ)
/* TICK_USEC is the time between ticks in usec assuming fake USER_HZ */
#define TICK_USEC ((100UL + USER_HZ/2) / USER_HZ)
diff --git a/kernel/time/jiffies.c b/kernel/time/jiffies.c
index 46da053..6629bf7 100644
--- a/kernel/time/jiffies.c
+++ b/kernel/time/jiffies.c
@@ -37,7 +37,7 @@
* requested HZ value. It is also not recommended
* for "tick-less" systems.
*/
-#define NSEC_PER_JIFFY ((u32)u64)NSEC_PER_SEC)<<8)/SHIFTED_HZ))
+#define NSEC_PER_JIFFY ((NSEC_PER_SEC+HZ/2)/HZ)
/* Since jiffies uses a simple NSEC_PER_JIFFY multiplier
* conversion, the .shift value could be zero. However
@@ -95,3 +95,33 @@ struct clocksource * __init __weak
clocksource_default_clock(void)
{
return _jiffies;
}
+
+struct clocksource refined_jiffies;
+
+int register_refined_jiffies(long cycles_per_second)
+{
+ u64 nsec_per_tick, shift_hz;
+ long cycles_per_tick;
+
+
+
+ refined_jiffies = clocksource_jiffies;
+ refined_jiffies.name = "refined-jiffies";
+ refined_jiffies.rating++;
+
+ /* Calc
[PATCH 3/3] jiffies: Add register_refined_jiffies() call to every arch
This isn't really something I want to submit, but shows what is required to retain the refined jiffies clock calculation. Instead of submitting this, which adds code that really doesn't matter in most cases, I instead propose to not submit this patch, and should anyone notice time quality regressions caused by jiffies clock error, they can add the appropriate changes from this patch. Cc: Catalin Marinas Cc: Arnd Bergmann Cc: Richard Cochran Cc: Prarit Bhargava Cc: Thomas Gleixner Signed-off-by: John Stultz --- arch/alpha/kernel/setup.c |3 +++ arch/arm/kernel/setup.c|2 ++ arch/avr32/kernel/setup.c |2 ++ arch/blackfin/kernel/setup.c |2 ++ arch/c6x/kernel/setup.c|2 ++ arch/cris/kernel/setup.c |2 ++ arch/h8300/kernel/setup.c |2 ++ arch/hexagon/kernel/setup.c|2 ++ arch/ia64/kernel/setup.c |2 ++ arch/m32r/kernel/setup.c |2 ++ arch/m68k/kernel/setup_mm.c|2 ++ arch/m68k/kernel/setup_no.c|2 ++ arch/microblaze/kernel/setup.c |2 ++ arch/mips/kernel/setup.c |2 ++ arch/mn10300/kernel/setup.c|2 ++ arch/openrisc/kernel/setup.c |2 ++ arch/parisc/kernel/setup.c |3 ++- arch/powerpc/kernel/setup_32.c |2 ++ arch/powerpc/kernel/setup_64.c |2 ++ arch/s390/kernel/setup.c |2 ++ arch/score/kernel/setup.c |2 ++ arch/sh/kernel/setup.c |2 ++ arch/sparc/kernel/setup_32.c |2 ++ arch/sparc/kernel/setup_64.c |2 ++ arch/tile/kernel/setup.c |2 ++ arch/um/kernel/um_arch.c |2 ++ arch/unicore32/kernel/setup.c |2 ++ arch/xtensa/kernel/setup.c |3 ++- 28 files changed, 57 insertions(+), 2 deletions(-) diff --git a/arch/alpha/kernel/setup.c b/arch/alpha/kernel/setup.c index 9e3107cc5..cec1744 100644 --- a/arch/alpha/kernel/setup.c +++ b/arch/alpha/kernel/setup.c @@ -44,6 +44,7 @@ #include #include #include +#include extern struct atomic_notifier_head panic_notifier_list; static int alpha_panic_event(struct notifier_block *, unsigned long, void *); @@ -747,6 +748,8 @@ setup_arch(char **cmdline_p) setup_smp(); #endif paging_init(); + + register_refined_jiffies(CLOCK_TICK_RATE); } static char sys_unknown[] = "Unknown"; diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c index a81dcec..9b4580c 100644 --- a/arch/arm/kernel/setup.c +++ b/arch/arm/kernel/setup.c @@ -31,6 +31,7 @@ #include #include #include +#include #include #include @@ -998,6 +999,7 @@ void __init setup_arch(char **cmdline_p) if (mdesc->init_early) mdesc->init_early(); + register_refined_jiffies(CLOCK_TICK_RATE); } diff --git a/arch/avr32/kernel/setup.c b/arch/avr32/kernel/setup.c index b4247f4..141ac85 100644 --- a/arch/avr32/kernel/setup.c +++ b/arch/avr32/kernel/setup.c @@ -19,6 +19,7 @@ #include #include #include +#include #include #include @@ -606,4 +607,5 @@ void __init setup_arch (char **cmdline_p) paging_init(); resource_init(); + register_refined_jiffies(CLOCK_TICK_RATE); } diff --git a/arch/blackfin/kernel/setup.c b/arch/blackfin/kernel/setup.c index fb96e60..71a4c1b 100644 --- a/arch/blackfin/kernel/setup.c +++ b/arch/blackfin/kernel/setup.c @@ -13,6 +13,7 @@ #include #include #include +#include #ifdef CONFIG_MTD_UCLINUX #include @@ -1101,6 +1102,7 @@ void __init setup_arch(char **cmdline_p) #endif init_exception_vectors(); bfin_cache_init(); /* Initialize caches for the boot CPU */ + register_refined_jiffies(CLOCK_TICK_RATE); } static int __init topology_init(void) diff --git a/arch/c6x/kernel/setup.c b/arch/c6x/kernel/setup.c index f4e72bd..b95997a 100644 --- a/arch/c6x/kernel/setup.c +++ b/arch/c6x/kernel/setup.c @@ -12,6 +12,7 @@ #include #include #include +#include #include #include #include @@ -441,6 +442,7 @@ void __init setup_arch(char **cmdline_p) #if defined(CONFIG_VT) && defined(CONFIG_DUMMY_CONSOLE) conswitchp = _con; #endif + register_refined_jiffies(CLOCK_TICK_RATE); } #define cpu_to_ptr(n) ((void *)((long)(n)+1)) diff --git a/arch/cris/kernel/setup.c b/arch/cris/kernel/setup.c index 32c3d24..9a18d57 100644 --- a/arch/cris/kernel/setup.c +++ b/arch/cris/kernel/setup.c @@ -19,6 +19,7 @@ #include #include #include +#include #include #include @@ -163,6 +164,7 @@ void __init setup_arch(char **cmdline_p) /* Setup utsname */ strcpy(init_utsname()->machine, cris_machine_name); + register_refined_jiffies(CLOCK_TICK_RATE); } static void *c_start(struct seq_file *m, loff_t *pos) diff --git a/arch/h8300/kernel/setup.c b/arch/h8300/kernel/setup.c index d0b1607..4da1763 100644 --- a/arch/h8300/kernel/setup.c +++ b/arch/h8300/kernel/setup.c @@ -31,6 +31,7 @@ #include #include #include +#include #include #include @@ -187,6 +188,7 @@ void __init
[PATCH 1/3] jiffies: Kill unused TICK_USEC_TO_NSEC
No one is using TICK_USEC_TO_NSEC, so kill it. Cc: Catalin Marinas Cc: Arnd Bergmann Cc: Richard Cochran Cc: Prarit Bhargava Cc: Thomas Gleixner Signed-off-by: John Stultz --- include/linux/jiffies.h |6 -- 1 file changed, 6 deletions(-) diff --git a/include/linux/jiffies.h b/include/linux/jiffies.h index 8268054..4a7e386 100644 --- a/include/linux/jiffies.h +++ b/include/linux/jiffies.h @@ -70,12 +70,6 @@ /* TICK_USEC is the time between ticks in usec assuming fake USER_HZ */ #define TICK_USEC ((100UL + USER_HZ/2) / USER_HZ) -/* - * TICK_USEC_TO_NSEC is the time between ticks in nsec assuming SHIFTED_HZ and - * a value TUSEC for TICK_USEC (can be set bij adjtimex) - */ -#define TICK_USEC_TO_NSEC(TUSEC) (SH_DIV(TUSEC * USER_HZ * 1000, SHIFTED_HZ, 8)) - /* some arch's have a small-data section that can be accessed register-relative * but that can only take up to, say, 4-byte variables. jiffies being part of * an 8-byte variable may not be correctly accessed unless we force the issue -- 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 0/3] Remove jiffies clocksource's dependency on CLOCK_TICK_RATE
Just wanted to send this out for initial review and comments. During Linux Plumbers, Thomas mentioned that Arnd was still wanting to kill off the derived values from the compile time constant CLOCK_TICK_RATE, as it is a problem for unified zImage on ARM. One issue holding this back is that CLOCK_TICK_RATE allows us to address the granularity error of the underlying timer hardware, allowing for accurate timekeeping with jiffies and jiffies derived clocksources. Thomas proposed allowing the jiffies correction to be done dynamically at runtime, and this is my first attempt at such an approach. * The first patch is a simple cleanup of an unused define. * The second patch adds the hook to add a refined jiffies clocksource, and kills the values derived at compile time from CLOCK_TICK_RATE. * The third is a patch that adds the refined jiffies registration to all arches. Clearly, since in most cases platforms aren't using jiffies as a clocksource (except for just briefly in early boot), its quality doesn't matter that much. So I'd rather not actually submit the third patch, which adds unnecessary code in most cases, and instead allow architectures to add their portion as they see fit/regressions. I've only done some initial testing, and haven't tested with all HZ values yet, so there may still be issues, but its looking reasonably good so far. Anyway, I'd appreciate any feedback on this approach, or suggestions for other ways to allow for dynamic adjustments at runtime. thanks -john Cc: Catalin Marinas Cc: Arnd Bergmann Cc: Richard Cochran Cc: Prarit Bhargava Cc: Thomas Gleixner John Stultz (3): jiffies: Kill unused TICK_USEC_TO_NSEC jiffies: Remove compile time assumptions about CLOCK_TICK_RATE jiffies: Add register_refined_jiffies() call to every arch arch/alpha/kernel/setup.c |3 +++ arch/arm/kernel/setup.c|2 ++ arch/avr32/kernel/setup.c |2 ++ arch/blackfin/kernel/setup.c |2 ++ arch/c6x/kernel/setup.c|2 ++ arch/cris/kernel/setup.c |2 ++ arch/h8300/kernel/setup.c |2 ++ arch/hexagon/kernel/setup.c|2 ++ arch/ia64/kernel/setup.c |2 ++ arch/m32r/kernel/setup.c |2 ++ arch/m68k/kernel/setup_mm.c|2 ++ arch/m68k/kernel/setup_no.c|2 ++ arch/microblaze/kernel/setup.c |2 ++ arch/mips/kernel/setup.c |2 ++ arch/mn10300/kernel/setup.c|2 ++ arch/openrisc/kernel/setup.c |2 ++ arch/parisc/kernel/setup.c |3 ++- arch/powerpc/kernel/setup_32.c |2 ++ arch/powerpc/kernel/setup_64.c |2 ++ arch/s390/kernel/setup.c |2 ++ arch/score/kernel/setup.c |2 ++ arch/sh/kernel/setup.c |2 ++ arch/sparc/kernel/setup_32.c |2 ++ arch/sparc/kernel/setup_64.c |2 ++ arch/tile/kernel/setup.c |2 ++ arch/um/kernel/um_arch.c |2 ++ arch/unicore32/kernel/setup.c |2 ++ arch/x86/kernel/setup.c|3 +++ arch/xtensa/kernel/setup.c |3 ++- include/linux/jiffies.h| 21 ++--- kernel/time/jiffies.c | 32 +++- 31 files changed, 93 insertions(+), 22 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] PCI, x86: clear initial value for root info resources
Found one system one root bus hot remove get panic.
Panic happens when try to release hostbridge resource.
It turns out that resource get reject during put into resource tree
because of conflicts.
Also that resource parent pointer have random value.
That invalid value cause it pass through check __release_pci_root_info
and panic in release_resource.
Try to use kzalloc instead.
Signed-off-by: Yinghai Lu
Cc: x...@kernel.org
---
arch/x86/pci/acpi.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
Index: linux-2.6/arch/x86/pci/acpi.c
===
--- linux-2.6.orig/arch/x86/pci/acpi.c
+++ linux-2.6/arch/x86/pci/acpi.c
@@ -305,7 +305,6 @@ setup_resource(struct acpi_resource *acp
res->flags = flags;
res->start = start;
res->end = end;
- res->child = NULL;
if (!pci_use_crs) {
dev_printk(KERN_DEBUG, >bridge->dev,
@@ -434,7 +433,7 @@ probe_pci_root_info(struct pci_root_info
size = sizeof(*info->res) * info->res_num;
info->res_num = 0;
- info->res = kmalloc(size, GFP_KERNEL);
+ info->res = kzalloc(size, GFP_KERNEL);
if (!info->res)
return;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Use correct type when freeing bus resource list
Should use struct pci_bus_resource instead of struct pci_host_bridge_window
Signed-off-by: Yinghai Lu
---
drivers/pci/bus.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
Index: linux-2.6/drivers/pci/bus.c
===
--- linux-2.6.orig/drivers/pci/bus.c
+++ linux-2.6/drivers/pci/bus.c
@@ -87,11 +87,15 @@ EXPORT_SYMBOL_GPL(pci_bus_resource_n);
void pci_bus_remove_resources(struct pci_bus *bus)
{
int i;
+ struct pci_bus_resource *bus_res, *tmp;
for (i = 0; i < PCI_BRIDGE_RESOURCE_NUM; i++)
bus->resource[i] = NULL;
- pci_free_resource_list(>resources);
+ list_for_each_entry_safe(bus_res, tmp, >resources, list) {
+ list_del(_res->list);
+ kfree(bus_res);
+ }
}
/**
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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, x86: fix default vga ref_count
when __ARCH_HAS_VGA_DEFAULT_DEVICE is not defined, aka EFIFB is not used,
for static path, vga_default setting is through vga_arbiter_add_pci_device.
and for x86 pci_fixup_video, will skip that.
because subsys_initcall(vga_arb_device_init) come first to call
vga_arbiter_add_pci_device.
for hotplug path, even vga_arbiter_add_pci_device is called via notifier, but it
will check VGA_RSRC_LEGACY_MASK that is not set for hotplug path.
So x86 pci_fixup_video will take over to call vga_set_default_device().
We need to hold one dev reference there.
otherwise vga_arbiter_del_pci_device that does not check VGA_RSRC_LEGACY_MASK
will call put_device and it will cause ref_count to decrease extra.
that will have that device get deleted early wrongly.
Signed-off-by: Yinghai Lu
Cc: x...@kernel.org
---
arch/x86/pci/fixup.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
Index: linux-2.6/arch/x86/pci/fixup.c
===
--- linux-2.6.orig/arch/x86/pci/fixup.c
+++ linux-2.6/arch/x86/pci/fixup.c
@@ -349,8 +349,12 @@ static void __devinit pci_fixup_video(st
if (config & (PCI_COMMAND_IO | PCI_COMMAND_MEMORY)) {
pdev->resource[PCI_ROM_RESOURCE].flags |= IORESOURCE_ROM_SHADOW;
dev_printk(KERN_DEBUG, >dev, "Boot video device\n");
- if (!vga_default_device())
+ if (!vga_default_device()) {
+#ifndef __ARCH_HAS_VGA_DEFAULT_DEVICE
+ pdev = pci_dev_get(pdev);
+#endif
vga_set_default_device(pdev);
+ }
}
}
DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_ANY_ID, PCI_ANY_ID,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [ 24/46] ACPI: export symbol acpi_get_table_with_size
On Wed, 2012-09-12 at 16:39 -0700, Greg Kroah-Hartman wrote: > From: Greg KH > > 3.0-stable review patch. If anyone has any objections, please let me know. > > -- > > From: Alex Deucher > > commit 4f81f986761a7663db7d24d24cd6ae68008f1fc2 upstream. > > We need it in the radeon drm module to fetch > and verify the vbios image on UEFI systems. Unless you're planning going to include those radeon changes in the next update, I don't see the point of this. Ben. > Signed-off-by: Alex Deucher > Signed-off-by: Greg Kroah-Hartman > > --- > drivers/acpi/acpica/tbxface.c |1 + > 1 file changed, 1 insertion(+) > > --- a/drivers/acpi/acpica/tbxface.c > +++ b/drivers/acpi/acpica/tbxface.c > @@ -435,6 +435,7 @@ acpi_get_table_with_size(char *signature > > return (AE_NOT_FOUND); > } > +ACPI_EXPORT_SYMBOL(acpi_get_table_with_size) > > acpi_status > acpi_get_table(char *signature, > > > -- > To unsubscribe from this list: send the line "unsubscribe stable" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Ben Hutchings Logic doesn't apply to the real world. - Marvin Minsky signature.asc Description: This is a digitally signed message part
RE: [PATCH v5] iio: adc: add new lp8788 adc driver
> > The LP8788 has 13 ADC input selection. > > > > ADC selection: > > Battery voltage, general ADC1 and so on. > > > > ADC result: > > Result = MAX_VALUE * (raw + 0.5) / 4095 except ADC is the charger > voltage > > If the ADC input is the charger voltage, > > Result = MAX_VALUE * (raw + 0.5) / (4095 * 0.48) > > > > The raw value is from the registers. > > It has the range between 0 to 4095. (12bits) > > > > MAX_VALUE is constant for each selection. > > For the battery voltage, there are three ADC inputs. 5.0/5.5/6.0V > > Battery voltage for Max 5.0V = 5.0 > > Battery voltage for Max 5.5V = 5.5 > > Battery voltage for Max 6.0V = 6.0 > > Charger = 6.0 > > ADC1 = 2.5 > > > > I'm afraid I still misunderstand how IIO ADC works. > > Could you me some guide how to setup the scale in the driver? > > The scale is a fixpoint value, which should be multiplied with the raw > value > to get the result in the proper unit. The unit depends on the channel > type, > e.g. for voltage it is mV and for temperature it is C. The number of > decimal > places for the fixed point value depends on whether you return > INT_PLUS_MICRO it's 6, if you return INT_PLUS_NANO it is 9. The digits > before the decimal point are stored in "val" the digits after the > decimal > point are stored in "val2". > > E.g. if you have > *val = 1; > *val2 = 1256; > return INT_PLUS_MICRO; > > your scale factor is 1.001256, if you'd return INT_PLUS_NANO you scale > factor would be 1.001256 instead. > > In your case you could for example calculate the voltage scales as: > > tmp = MAX_VALUE * 100 / 4095; > *val = tmp / 100; > *val2 = tmp % 100; > > This assumes that MAX_VALUE is in millivolt. > > E.g. if MAX_VALUE is 5.0V you should get a scale of 1.220703 (val = 1, > val2 > = 220703). Since your MAX_VALUE is fixed you can probably just pre- > calculate > the result of MAX_VALUE * 100 / 4095 for each channel, similar like > you > already did with your lp8788_scale table. Superb! Thanks a lot for your clear explanation. I have one more question about the temperature ADC. The LP8788 has no dedicated temperature ADC, but it provides four general inputs - ADC1 to 4. The IIO consumer can get the battery temperature among general ADC inputs. I think the ADC driver should not assume that ADC1..4 is for the temperature, because the selection is configurable in the platform side. Then how can I set the unit of ADC MAX_VALUE? I would set the unit of ADC MAX_VALUE to mili (same as voltage) and the result is converted by the IIO consumer manually. Does it make sense ? Best Regards, Milo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/7] mm: add CONFIG_DEBUG_VM_RB build option
On Fri, Sep 14, 2012 at 3:46 PM, Michel Lespinasse wrote:
> On Fri, Sep 14, 2012 at 3:14 PM, Sasha Levin wrote:
>> On 09/04/2012 11:20 AM, Michel Lespinasse wrote:
>>> Add a CONFIG_DEBUG_VM_RB build option for the previously existing
>>> DEBUG_MM_RB code. Now that Andi Kleen modified it to avoid using
>>> recursive algorithms, we can expose it a bit more.
>>>
>>> Also extend this code to validate_mm() after stack expansion, and to
>>> check that the vma's start and last pgoffs have not changed since the
>>> nodes were inserted on the anon vma interval tree (as it is important
>>> that the nodes be reindexed after each such update).
>>
>> This patch exposes the following warning:
>>
>> [ 24.977502] [ cut here ]
>> [ 24.979089] WARNING: at mm/interval_tree.c:110
>> anon_vma_interval_tree_verify+0x81/0xa0()
>> [ 24.981765] Pid: 5928, comm: trinity-child37 Tainted: GW
>> 3.6.0-rc5-next-20120914-sasha-3-g7deb7fa-dirty #333
>> [ 24.985501] Call Trace:
>> [ 24.986345] [] ?
>> anon_vma_interval_tree_verify+0x81/0xa0
>> [ 24.988535] [] warn_slowpath_common+0x86/0xb0
>> [ 24.990636] [] warn_slowpath_null+0x15/0x20
>> [ 24.992658] [] anon_vma_interval_tree_verify+0x81/0xa0
>> [ 24.994980] [] validate_mm+0x58/0x1e0
>> [ 24.996772] [] vma_link+0x94/0xe0
>> [ 24.997719] [] copy_vma+0x279/0x2e0
>> [ 24.998522] [] ? trace_hardirqs_off+0xd/0x10
>> [ 25.000772] [] move_vma+0xa9/0x260
>> [ 25.002499] [] sys_mremap+0x475/0x540
>> [ 25.004364] [] tracesys+0xe1/0xe6
>> [ 25.006108] ---[ end trace 7c901670963aa6e2 ]---
>>
>> The code line is
>>
>> WARN_ON_ONCE(node->cached_vma_last != avc_last_pgoff(node));
>
> That's very interesting (and potentially relevant to another bug
> that's been reported too).
>
> I'd like to know, what workload did you use that triggered this ?
> (I find it hard to test mremap as I don't know of enough users of it)
All right. Hugh managed to reproduce the issue on his suse laptop, and
I came up with a fix.
The problem was that in mremap, the new vma's vm_{start,end,pgoff}
fields need to be updated before calling anon_vma_clone() so that the
new vma will be properly indexed.
Patch attached. I expect this should also explain Jiri's reported
failure involving splitting THP pages during mremap(), even though we
did not manage to reproduce that one.
-8<---
From: Michel Lespinasse
Date: Fri, 14 Sep 2012 16:43:49 -0700
Subject: [PATCH] mm anon rmap: in mremap, set the new vma's position before
anon_vma_clone()
anon_vma_clone() expects new_vma->vm_{start,end,pgoff} to be correctly set
so that the new vma can be indexed on the anon interval tree.
copy_vma() was failing to do that, which broke mremap().
Signed-off-by: Michel Lespinasse
---
mm/mmap.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/mm/mmap.c b/mm/mmap.c
index cc8c64077a42..7e672800b5d4 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -2446,16 +2446,16 @@ struct vm_area_struct *copy_vma(struct vm_area_struct
**vmap,
new_vma = kmem_cache_alloc(vm_area_cachep, GFP_KERNEL);
if (new_vma) {
*new_vma = *vma;
+ new_vma->vm_start = addr;
+ new_vma->vm_end = addr + len;
+ new_vma->vm_pgoff = pgoff;
pol = mpol_dup(vma_policy(vma));
if (IS_ERR(pol))
goto out_free_vma;
+ vma_set_policy(new_vma, pol);
INIT_LIST_HEAD(_vma->anon_vma_chain);
if (anon_vma_clone(new_vma, vma))
goto out_free_mempol;
- vma_set_policy(new_vma, pol);
- new_vma->vm_start = addr;
- new_vma->vm_end = addr + len;
- new_vma->vm_pgoff = pgoff;
if (new_vma->vm_file) {
get_file(new_vma->vm_file);
--
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 24/24] net: seeq: use __iomem pointers for MMIO
On Fri, Sep 14, 2012 at 11:34:52PM +0200, Arnd Bergmann wrote: > ARM is moving to stricter checks on readl/write functions, > so we need to use the correct types everywhere. Same comment as for eesox. const void __iomem * is not a problem on x86, so it should not be a problem on ARM. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/24] serial: ks8695: use __iomem pointers for MMIO
On Fri, Sep 14, 2012 at 11:34:49PM +0200, Arnd Bergmann wrote: > ARM is moving to stricter checks on readl/write functions, > so we need to use the correct types everywhere. > > Cc: Alan Cox > Cc: Greg Kroah-Hartman > Signed-off-by: Arnd Bergmann Acked-by: Greg Kroah-Hartman -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 22/24] scsi: eesox: use __iomem pointers for MMIO
On Fri, Sep 14, 2012 at 11:34:50PM +0200, Arnd Bergmann wrote:
> ARM is moving to stricter checks on readl/write functions,
> so we need to use the correct types everywhere.
There's nothing wrong with const iomem pointers. If you think
otherwise, patch x86 not to use const in its accessor implementation
and watch the reaction:
#define build_mmio_read(name, size, type, reg, barrier) \
static inline type name(const volatile void __iomem *addr) \
{ type ret; asm volatile("mov" size " %1,%0":reg (ret) \
:"m" (*(volatile type __force *)addr) barrier); return ret; }
build_mmio_read(readb, "b", unsigned char, "=q", :"memory")
build_mmio_read(readw, "w", unsigned short, "=r", :"memory")
build_mmio_read(readl, "l", unsigned int, "=r", :"memory")
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] [PATCH 2] dm: Use bioset's front_pad for dm_target_io
On Wed, Sep 12, 2012 at 06:31:53PM -0400, Mikulas Patocka wrote: > This is the patch based on this tree. I've pulled this into the dm tree 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: [PATCHSET] kthread_worker: reimplement flush_kthread_work() to allow freeing during execution
On Thu, Jul 19, 2012 at 2:15 PM, Tejun Heo wrote: > Hello, > > kthread_worker was introduced together with concurrency managed > workqueue to serve workqueue users which need a special dedicated > worker - e.g. RT scheduling. This is minimal queue / flush / flush > all iterface on top of kthread and each provided interface matches the > workqueue counterpart so that switching isn't difficult. > > However, one noticeable difference was that kthread_worker doesn't > allow a work item to be freed while being executed. The intention was > to keep the code simpler but it didn't really and the restriction is > subtle and does prevent some valid use cases. > > This two-patch series reimplements flush_kthread_work() so that it > uses an extra work item for flushing. While this takes a bit more > lines, this is easier to understand and removes the annoying > difference. > > This patchset contains the following two patches. > > 0001-kthread_worker-reorganize-to-prepare-for-flush_kthre.patch > 0002-kthread_worker-reimplement-flush_kthread_work-to-all.patch > > The first one is a prep patch which makes no functional changes. The > second reimplements flush_kthread_work(). > > All current kthread_worker users are cc'd. If no one objects, I'll > push it through the workqueue branch. This patchset is also available > in the following git branch. > > git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq.git > review-kthread_worker-flush > > diffstat follows. Thanks. > > include/linux/kthread.h |8 +--- > kernel/kthread.c| 86 > +++- > 2 files changed, 52 insertions(+), 42 deletions(-) > > -- > tejun This patch set fixes a reproducible crash I'm seeing on a 3.4.10 kernel. flush_kthread_worker (which is different from flush_kthread_work) is initializing a kthread_work and a completion on the stack, then queuing it and calling wait_for_completion. Once the completion is signaled, flush_kthread_worker exits and the stack region used by the kthread_work may be immediately reused by another object on the stack, but kthread_worker_fn continues accessing its work pointer: work->func(work); <- calls complete, effectively frees work smp_wmb(); /* wmb worker-b0 paired with flush-b1 */ work->done_seq = work->queue_seq; <- overwrites a new stack object smp_mb(); /* mb worker-b1 paired with flush-b0 */ if (atomic_read(>flushing)) wake_up_all(>done); <- or crashes here These patches fix the problem by not accessing work after work->func is called, and should be backported to stable. They apply cleanly to 3.4.10. Upstream commits are 9a2e03d8ed518a61154f18d83d6466628e519f94 and 46f3d976213452350f9d10b0c2780c2681f7075b. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/7] mm: add CONFIG_DEBUG_VM_RB build option
On Fri, Sep 14, 2012 at 3:14 PM, Sasha Levin wrote: > On 09/04/2012 11:20 AM, Michel Lespinasse wrote: >> Add a CONFIG_DEBUG_VM_RB build option for the previously existing >> DEBUG_MM_RB code. Now that Andi Kleen modified it to avoid using >> recursive algorithms, we can expose it a bit more. >> >> Also extend this code to validate_mm() after stack expansion, and to >> check that the vma's start and last pgoffs have not changed since the >> nodes were inserted on the anon vma interval tree (as it is important >> that the nodes be reindexed after each such update). > > This patch exposes the following warning: > > [ 24.977502] [ cut here ] > [ 24.979089] WARNING: at mm/interval_tree.c:110 > anon_vma_interval_tree_verify+0x81/0xa0() > [ 24.981765] Pid: 5928, comm: trinity-child37 Tainted: GW > 3.6.0-rc5-next-20120914-sasha-3-g7deb7fa-dirty #333 > [ 24.985501] Call Trace: > [ 24.986345] [] ? anon_vma_interval_tree_verify+0x81/0xa0 > [ 24.988535] [] warn_slowpath_common+0x86/0xb0 > [ 24.990636] [] warn_slowpath_null+0x15/0x20 > [ 24.992658] [] anon_vma_interval_tree_verify+0x81/0xa0 > [ 24.994980] [] validate_mm+0x58/0x1e0 > [ 24.996772] [] vma_link+0x94/0xe0 > [ 24.997719] [] copy_vma+0x279/0x2e0 > [ 24.998522] [] ? trace_hardirqs_off+0xd/0x10 > [ 25.000772] [] move_vma+0xa9/0x260 > [ 25.002499] [] sys_mremap+0x475/0x540 > [ 25.004364] [] tracesys+0xe1/0xe6 > [ 25.006108] ---[ end trace 7c901670963aa6e2 ]--- > > The code line is > > WARN_ON_ONCE(node->cached_vma_last != avc_last_pgoff(node)); That's very interesting (and potentially relevant to another bug that's been reported too). I'd like to know, what workload did you use that triggered this ? (I find it hard to test mremap as I don't know of enough users of it) Thanks, -- Michel "Walken" Lespinasse A program is never fully debugged until the last user dies. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/7] mm: add CONFIG_DEBUG_VM_RB build option
On 09/15/2012 12:14 AM, Sasha Levin wrote: > On 09/04/2012 11:20 AM, Michel Lespinasse wrote: >> Add a CONFIG_DEBUG_VM_RB build option for the previously existing >> DEBUG_MM_RB code. Now that Andi Kleen modified it to avoid using >> recursive algorithms, we can expose it a bit more. >> >> Also extend this code to validate_mm() after stack expansion, and to >> check that the vma's start and last pgoffs have not changed since the >> nodes were inserted on the anon vma interval tree (as it is important >> that the nodes be reindexed after each such update). > > This patch exposes the following warning: > > [ 24.977502] [ cut here ] > [ 24.979089] WARNING: at mm/interval_tree.c:110 > anon_vma_interval_tree_verify+0x81/0xa0() > [ 24.981765] Pid: 5928, comm: trinity-child37 Tainted: GW > 3.6.0-rc5-next-20120914-sasha-3-g7deb7fa-dirty #333 > [ 24.985501] Call Trace: > [ 24.986345] [] ? anon_vma_interval_tree_verify+0x81/0xa0 > [ 24.988535] [] warn_slowpath_common+0x86/0xb0 > [ 24.990636] [] warn_slowpath_null+0x15/0x20 > [ 24.992658] [] anon_vma_interval_tree_verify+0x81/0xa0 > [ 24.994980] [] validate_mm+0x58/0x1e0 > [ 24.996772] [] vma_link+0x94/0xe0 > [ 24.997719] [] copy_vma+0x279/0x2e0 > [ 24.998522] [] ? trace_hardirqs_off+0xd/0x10 > [ 25.000772] [] move_vma+0xa9/0x260 > [ 25.002499] [] sys_mremap+0x475/0x540 > [ 25.004364] [] tracesys+0xe1/0xe6 > [ 25.006108] ---[ end trace 7c901670963aa6e2 ]--- > > The code line is > > WARN_ON_ONCE(node->cached_vma_last != avc_last_pgoff(node)); > The second WARN in the function also triggers once in a while: [ 18.360283] [ cut here ] [ 18.360289] WARNING: at mm/interval_tree.c:109 anon_vma_interval_tree_verify+0x36/0xa0() [ 18.360292] Pid: 5694, comm: trinity-child15 Tainted: GW 3.6.0-rc5-next-20120914-sasha-3-g7deb7fa-dirty #335 [ 18.360293] Call Trace: [ 18.360297] [] ? anon_vma_interval_tree_verify+0x36/0xa0 [ 18.360300] [] warn_slowpath_common+0x86/0xb0 [ 18.360303] [] warn_slowpath_null+0x15/0x20 [ 18.360305] [] anon_vma_interval_tree_verify+0x36/0xa0 [ 18.360309] [] validate_mm+0x58/0x1e0 [ 18.360312] [] vma_link+0x94/0xe0 [ 18.360315] [] copy_vma+0x279/0x2e0 [ 18.360319] [] ? trace_hardirqs_off+0xd/0x10 [ 18.360322] [] move_vma+0xa9/0x260 [ 18.360326] [] sys_mremap+0x475/0x540 [ 18.360330] [] tracesys+0xe1/0xe6 [ 18.360332] ---[ end trace de862a218d00cefd ]--- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/24] ARM: msm: use __iomem pointers for MMIO
On 09/14/12 14:34, Arnd Bergmann wrote: > ARM is moving to stricter checks on readl/write functions, > so we need to use the correct types everywhere. > > Cc: David Brown > Cc: Daniel Walker > Cc: Bryan Huntsman > Signed-off-by: Arnd Bergmann I was going to send this patch out today. Thanks. Acked-by: Stephen Boyd -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mtd/nand/docg4: Add missing HAS_IOMEM dependency
While building an allyesconfig for UML I received this error message(s): drivers/mtd/nand/docg4.c: In function 'probe_docg4': drivers/mtd/nand/docg4.c:1272:2: error: implicit declaration of function 'ioremap' [-Werror=implicit-function-declaration] drivers/mtd/nand/docg4.c:1272:10: warning: assignment makes pointer from integer without a cast [enabled by default] drivers/mtd/nand/docg4.c:1327:2: error: implicit declaration of function 'iounmap' [-Werror=implicit-function-declaration] which is caused by the missing implementations on UML. This patch adds this missing HAS_IOMEM dependency and prevents the driver from being build on platforms with no HAS_IOMEM Signed-off-by: Peter Huewe --- drivers/mtd/nand/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig index 8ca4176..3e2f75d 100644 --- a/drivers/mtd/nand/Kconfig +++ b/drivers/mtd/nand/Kconfig @@ -356,7 +356,7 @@ config MTD_NAND_DISKONCHIP_BBTWRITE config MTD_NAND_DOCG4 tristate "Support for DiskOnChip G4 (EXPERIMENTAL)" - depends on EXPERIMENTAL + depends on EXPERIMENTAL && HAS_IOMEM select BCH select BITREVERSE help -- 1.7.8.6 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] PCI: Annotate pci_fixup_irqs with __devinit
On Fri, Sep 14, 2012 at 02:53:11PM -0600, Bjorn Helgaas wrote: > +cc Greg KH > > On Fri, Sep 14, 2012 at 2:44 PM, Thierry Reding > wrote: > > In order to keep pci_fixup_irqs() around after init (e.g. for hotplug), > > mark it __devinit instead of __init. This requires the same change for > > the implementation of the pcibios_update_irq() function on all > > architectures. > > > > Signed-off-by: Thierry Reding > > --- > > Note: Ideally these annotations should go away completely in order to > > be independent of the HOTPLUG symbol. However, there is work underway > > to get rid of HOTPLUG altogether, so I've kept the __devinit for now. No, just take away the __init marking completly. For 3.7, CONFIG_HOTPLUG will always be enabled, making it be the same thing. That way this saves me the time and energy from deleting the __devinit markings when I get to that point in the patch series :) thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 05/24] ARM: imx: use __iomem pointers for MMIO
On Fri, Sep 14, 2012 at 6:34 PM, Arnd Bergmann wrote: > ARM is moving to stricter checks on readl/write functions, > so we need to use the correct types everywhere. > > This found a bug in mach-armadillo5x0.c, where we attempt mmio > on the MXC_CCM_RCSR address that is currently defined to 0xc > and consequently causes an illegal address access. ... > /* set NAND page size to 2k if not configured via boot mode pins */ > - __raw_writel(__raw_readl(MXC_CCM_RCSR) | (1 << 30), MXC_CCM_RCSR); > + /* FIXME __raw_writel(__raw_readl(MXC_CCM_RCSR) | (1 << 30), > MXC_CCM_RCSR); */ Good catch, the correct access would be: __raw_readl(mx3_ccm_base + MXC_CCM_RCSR) ... I will fix this after your series reaches linux-next. Regards, Fabio Estevam -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 segfault in dtc when empty input file is given.
From: Markus Mayer
Date: Thu, 13 Sep 2012 14:46:28 -0700
Subject: [PATCH] Fix segfault in dtc when empty input file is given.
Prior to this change, an empty input file would cause a segfault, because
yylloc had never been initialized. There was never any characters for the
lexer to match, so YY_USER_ACTION was never executed before the parse error
was detected.
When the parser printed the error message, it tried to include the name of
the file, but the structure holding the file name (yylloc.file, referenced
as pos->file) had never been initialized.
Without the fix:
$ ./dtc /dev/null
DTC: dts->dts on file "/dev/null"
Segmentation fault (core dumped)
$ gdb dtc core
Program terminated with signal 11, Segmentation fault.
at scripts/dtc/srcpos.c:194
194 fname = pos->file->name;
(gdb) bt
at scripts/dtc/srcpos.c:194
fmt=0x40d769 "%s", va=0x7fffbf027148) at scripts/dtc/srcpos.c:220
at scripts/dtc/dtc-parser.tab.c:1920
at scripts/dtc/treesource.c:38
at scripts/dtc/dtc.c:203
(gdb) p *pos
$1 = {first_line = 0, first_column = 0, last_line = 0, last_column = 0,
file = 0x0}
With the fix:
$ ./dtc /dev/null
DTC: dts->dts on file "/dev/null"
Error: /dev/null:1.1 syntax error
FATAL ERROR: Unable to parse input tree
Signed-off-by: Markus Mayer
---
scripts/dtc/treesource.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/scripts/dtc/treesource.c b/scripts/dtc/treesource.c
index c09aafa..b461b88 100644
--- a/scripts/dtc/treesource.c
+++ b/scripts/dtc/treesource.c
@@ -29,11 +29,15 @@ int treesource_error;
struct boot_info *dt_from_source(const char *fname)
{
+ extern YYLTYPE yylloc;
+
the_boot_info = NULL;
treesource_error = 0;
srcfile_push(fname);
yyin = current_srcfile->f;
+ /* Initialize yylloc->file to avoid segfault on empty input */
+ srcpos_update(, NULL, 0);
if (yyparse() != 0)
die("Unable to parse input tree\n");
--
1.7.5.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 v2 2/2] ARM: local timers: add timer support using IO mapped register
The current arch_timer only support accessing through CP15 interface.
Add support for ARM processors that only support IO mapped register
interface. The memory mapped timer interface works with SPI
interrupts instead of PPI.
Signed-off-by: Rohit Vaswani
---
.../devicetree/bindings/arm/arch_timer.txt |9 +-
arch/arm/kernel/arch_timer.c | 299 +++-
2 files changed, 297 insertions(+), 11 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/arch_timer.txt
b/Documentation/devicetree/bindings/arm/arch_timer.txt
index 52478c8..8e01328 100644
--- a/Documentation/devicetree/bindings/arm/arch_timer.txt
+++ b/Documentation/devicetree/bindings/arm/arch_timer.txt
@@ -7,10 +7,13 @@ The timer is attached to a GIC to deliver its per-processor
interrupts.
** Timer node properties:
-- compatible : Should at least contain "arm,armv7-timer".
+- compatible : Should at least contain "arm,armv7-timer" or
+ "arm,armv7-timer-mem" if using the memory mapped arch timer interface.
-- interrupts : Interrupt list for secure, non-secure, virtual and
- hypervisor timers, in that order.
+- interrupts : If using the cp15 interface, the interrupt list for secure,
+ non-secure, virtual and hypervisor timers, in that order.
+ If using the memory mapped interface, list the interrupts for each core,
+ starting with core 0.
- clock-frequency : The frequency of the main counter, in Hz. Optional.
diff --git a/arch/arm/kernel/arch_timer.c b/arch/arm/kernel/arch_timer.c
index 8672a75..f79092d 100644
--- a/arch/arm/kernel/arch_timer.c
+++ b/arch/arm/kernel/arch_timer.c
@@ -17,7 +17,9 @@
#include
#include
#include
+#include
#include
+#include
#include
#include
@@ -44,6 +46,11 @@ extern void init_current_timer_delay(unsigned long freq);
static bool arch_timer_use_virtual = true;
+static bool arch_timer_irq_percpu = true;
+static void __iomem *timer_base;
+static unsigned arch_timer_mem_irqs[NR_CPUS];
+static unsigned arch_timer_num_irqs;
+
/*
* Architected system timer support.
*/
@@ -56,8 +63,17 @@ static bool arch_timer_use_virtual = true;
#define ARCH_TIMER_REG_FREQ1
#define ARCH_TIMER_REG_TVAL2
+/* Iomapped Register Offsets */
+static unsigned arch_timer_mem_offset[] = {0x2C, 0x10, 0x28};
+#define ARCH_TIMER_CNTP_LOW_REG0x0
+#define ARCH_TIMER_CNTP_HIGH_REG 0x4
+#define ARCH_TIMER_CNTV_LOW_REG0x8
+#define ARCH_TIMER_CNTV_HIGH_REG 0xC
+
#define ARCH_TIMER_PHYS_ACCESS 0
#define ARCH_TIMER_VIRT_ACCESS 1
+#define ARCH_TIMER_MEM_PHYS_ACCESS 2
+#define ARCH_TIMER_MEM_VIRT_ACCESS 3
/*
* These register accessors are marked inline so the compiler can
@@ -88,6 +104,9 @@ static inline void arch_timer_reg_write(const int access,
const int reg, u32 val
}
}
+ if (access == ARCH_TIMER_MEM_PHYS_ACCESS)
+ __raw_writel(val, timer_base + arch_timer_mem_offset[reg]);
+
isb();
}
@@ -120,12 +139,16 @@ static inline u32 arch_timer_reg_read(const int access,
const int reg)
}
}
+ if (access == ARCH_TIMER_MEM_PHYS_ACCESS)
+ val = __raw_readl(timer_base + arch_timer_mem_offset[reg]);
+
return val;
}
static inline cycle_t arch_timer_counter_read(const int access)
{
cycle_t cval = 0;
+ u32 cvall, cvalh, thigh;
if (access == ARCH_TIMER_PHYS_ACCESS)
asm volatile("mrrc p15, 0, %Q0, %R0, c14" : "=r" (cval));
@@ -133,17 +156,49 @@ static inline cycle_t arch_timer_counter_read(const int
access)
if (access == ARCH_TIMER_VIRT_ACCESS)
asm volatile("mrrc p15, 1, %Q0, %R0, c14" : "=r" (cval));
+ if (access == ARCH_TIMER_MEM_PHYS_ACCESS) {
+ do {
+ cvalh = __raw_readl(timer_base +
+ ARCH_TIMER_CNTP_HIGH_REG);
+ cvall = __raw_readl(timer_base +
+ ARCH_TIMER_CNTP_LOW_REG);
+ thigh = __raw_readl(timer_base +
+ ARCH_TIMER_CNTP_HIGH_REG);
+ } while (cvalh != thigh);
+
+ cval = ((cycle_t) cvalh << 32) | cvall;
+ }
+
+ if (access == ARCH_TIMER_MEM_VIRT_ACCESS) {
+ do {
+ cvalh = __raw_readl(timer_base +
+ ARCH_TIMER_CNTV_HIGH_REG);
+ cvall = __raw_readl(timer_base +
+ ARCH_TIMER_CNTV_LOW_REG);
+ thigh = __raw_readl(timer_base +
+ ARCH_TIMER_CNTV_HIGH_REG);
+ } while (cvalh != thigh);
+
+ cval = ((cycle_t) cvalh << 32) | cvall;
+ }
+
return cval;
}
static inline cycle_t
[PATCH v2 1/2] ARM: arch timer: Set the TVAL before timer is enabled
On some hardware, the timer deasserts the interrupt when a
new TVAL is written only when the enable bit is cleared.
Hence explicitly disable the timer and then program the
TVAL followed by enabling the timer.
If this order is not followed, there are chances that
you would not receive any timer interrupts.
Signed-off-by: Rohit Vaswani
---
arch/arm/kernel/arch_timer.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/kernel/arch_timer.c b/arch/arm/kernel/arch_timer.c
index c04c2a6..8672a75 100644
--- a/arch/arm/kernel/arch_timer.c
+++ b/arch/arm/kernel/arch_timer.c
@@ -206,9 +206,10 @@ static inline void set_next_event(const int access,
unsigned long evt)
{
unsigned long ctrl;
ctrl = arch_timer_reg_read(access, ARCH_TIMER_REG_CTRL);
- ctrl |= ARCH_TIMER_CTRL_ENABLE;
- ctrl &= ~ARCH_TIMER_CTRL_IT_MASK;
+ ctrl &= ~(ARCH_TIMER_CTRL_ENABLE | ARCH_TIMER_CTRL_IT_MASK);
+ arch_timer_reg_write(access, ARCH_TIMER_REG_CTRL, ctrl);
arch_timer_reg_write(access, ARCH_TIMER_REG_TVAL, evt);
+ ctrl |= ARCH_TIMER_CTRL_ENABLE;
arch_timer_reg_write(access, ARCH_TIMER_REG_CTRL, ctrl);
}
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] leds: use workqueue in led_set_brightness() API internally
On Fri, Sep 14, 2012 at 1:53 AM, Bryan Wu wrote: > The API function led_set_brightness() and __led_set_brightness will > call .brightness_set() function provided by led class drivers. So > .brightness_set() function will run in atomic context, which requires > led class drivers use workqueue in .brightness_set(). > > Finally, all the led class driver implemented their own workqueue in > .brightness_set(). For those missing this, we will face runtime warning > or error when running it in atomic context. > > This patch adds a workqueue in led_set_brightness() internally. LED > class driver doesn't need to care about duplicated workqueue stuff in > their own driver. > > Also this patch unified the led_set_brightness() and __led_set_brightness() > > Signed-off-by: Bryan Wu > --- > drivers/leds/led-class.c | 23 --- > drivers/leds/led-core.c | 15 +++ > drivers/leds/leds.h | 11 ++- > drivers/leds/ledtrig-backlight.c | 8 > drivers/leds/ledtrig-default-on.c | 2 +- > drivers/leds/ledtrig-gpio.c | 6 +++--- > drivers/leds/ledtrig-heartbeat.c | 2 +- > drivers/leds/ledtrig-oneshot.c| 4 ++-- > drivers/leds/ledtrig-transient.c | 8 Bryan, ledtrig-transient.c change looks good. Thanks for updating it. -- Shuah -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: 20% performance drop on PostgreSQL 9.2 from kernel 3.5.3 to 3.6-rc5 on AMD chipsets - bisected
On Fri, Sep 14, 2012 at 3:10 PM, Peter Zijlstra wrote: > > I'm not seeing how it could be. Only ever looking at 1 other cpu > (regardless which one) cannot be the same as checking 'all' of them. Oh, you're right, it has that cpu_idle() in the loop too. So yeah, you can't make it be even remotely equivalent. You can only make it equivalent for the "all other cpu's are idle" case. It doesn't even do *that*, though. In fact, as far as I can tell, it looks like a cpu could be its own idle_buddy. That whole logic looks very odd. I vote we just revert it as "insane". The code really doesn't seem to make any sense. 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: linux-next: Tree for Sept 14 (sata_highhbank)
On Fri, Sep 14, 2012 at 11:02 PM, Mark Langsdorf wrote: > Fix patch follows. Do I need to submit it as a separate patch or is this > sufficient? You appear to have submitted it as a separate patch just now ;p Will queue and push to libata-dev.git#upstream (and thus linux-next) Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 04/24] ARM: ep93xx: use __iomem pointers for MMIO
On 15/09/12 07:34, Arnd Bergmann wrote:
> ARM is moving to stricter checks on readl/write functions,
> so we need to use the correct types everywhere.
>
> Cc: Hartley Sweeten
> Cc: Ryan Mallon
> Signed-off-by: Arnd Bergmann
Hi Arnd,
Do you want me to queue both this and my patch to move the
ts72xx.h header into arch/arm/mach-ep93xx on to my ep93xx-fixes
branch? That way you won't have to deal with any conflicts at
your end.
Thanks,
~Ryan
> ---
> arch/arm/mach-ep93xx/include/mach/ts72xx.h | 10 +-
> arch/arm/mach-ep93xx/ts72xx.c | 10 +-
> 2 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm/mach-ep93xx/include/mach/ts72xx.h
> b/arch/arm/mach-ep93xx/include/mach/ts72xx.h
> index f1397a1..071feaa 100644
> --- a/arch/arm/mach-ep93xx/include/mach/ts72xx.h
> +++ b/arch/arm/mach-ep93xx/include/mach/ts72xx.h
> @@ -14,7 +14,7 @@
> */
>
> #define TS72XX_MODEL_PHYS_BASE 0x2200
> -#define TS72XX_MODEL_VIRT_BASE 0xfebff000
> +#define TS72XX_MODEL_VIRT_BASE IOMEM(0xfebff000)
> #define TS72XX_MODEL_SIZE0x1000
>
> #define TS72XX_MODEL_TS7200 0x00
> @@ -26,7 +26,7 @@
>
>
> #define TS72XX_OPTIONS_PHYS_BASE 0x2240
> -#define TS72XX_OPTIONS_VIRT_BASE 0xfebfe000
> +#define TS72XX_OPTIONS_VIRT_BASE IOMEM(0xfebfe000)
> #define TS72XX_OPTIONS_SIZE 0x1000
>
> #define TS72XX_OPTIONS_COM2_RS4850x02
> @@ -34,18 +34,18 @@
>
>
> #define TS72XX_OPTIONS2_PHYS_BASE0x2280
> -#define TS72XX_OPTIONS2_VIRT_BASE0xfebfd000
> +#define TS72XX_OPTIONS2_VIRT_BASEIOMEM(0xfebfd000)
> #define TS72XX_OPTIONS2_SIZE 0x1000
>
> #define TS72XX_OPTIONS2_TS9420 0x04
> #define TS72XX_OPTIONS2_TS9420_BOOT 0x02
>
>
> -#define TS72XX_RTC_INDEX_VIRT_BASE 0xfebf9000
> +#define TS72XX_RTC_INDEX_VIRT_BASE IOMEM(0xfebf9000)
> #define TS72XX_RTC_INDEX_PHYS_BASE 0x1080
> #define TS72XX_RTC_INDEX_SIZE0x1000
>
> -#define TS72XX_RTC_DATA_VIRT_BASE0xfebf8000
> +#define TS72XX_RTC_DATA_VIRT_BASEIOMEM(0xfebf8000)
> #define TS72XX_RTC_DATA_PHYS_BASE0x1170
> #define TS72XX_RTC_DATA_SIZE 0x1000
>
> diff --git a/arch/arm/mach-ep93xx/ts72xx.c b/arch/arm/mach-ep93xx/ts72xx.c
> index 75cab2d..faa5bdd 100644
> --- a/arch/arm/mach-ep93xx/ts72xx.c
> +++ b/arch/arm/mach-ep93xx/ts72xx.c
> @@ -32,27 +32,27 @@
>
> static struct map_desc ts72xx_io_desc[] __initdata = {
> {
> - .virtual= TS72XX_MODEL_VIRT_BASE,
> + .virtual= (unsigned long)TS72XX_MODEL_VIRT_BASE,
> .pfn= __phys_to_pfn(TS72XX_MODEL_PHYS_BASE),
> .length = TS72XX_MODEL_SIZE,
> .type = MT_DEVICE,
> }, {
> - .virtual= TS72XX_OPTIONS_VIRT_BASE,
> + .virtual= (unsigned long)TS72XX_OPTIONS_VIRT_BASE,
> .pfn= __phys_to_pfn(TS72XX_OPTIONS_PHYS_BASE),
> .length = TS72XX_OPTIONS_SIZE,
> .type = MT_DEVICE,
> }, {
> - .virtual= TS72XX_OPTIONS2_VIRT_BASE,
> + .virtual= (unsigned long)TS72XX_OPTIONS2_VIRT_BASE,
> .pfn= __phys_to_pfn(TS72XX_OPTIONS2_PHYS_BASE),
> .length = TS72XX_OPTIONS2_SIZE,
> .type = MT_DEVICE,
> }, {
> - .virtual= TS72XX_RTC_INDEX_VIRT_BASE,
> + .virtual= (unsigned long)TS72XX_RTC_INDEX_VIRT_BASE,
> .pfn= __phys_to_pfn(TS72XX_RTC_INDEX_PHYS_BASE),
> .length = TS72XX_RTC_INDEX_SIZE,
> .type = MT_DEVICE,
> }, {
> - .virtual= TS72XX_RTC_DATA_VIRT_BASE,
> + .virtual= (unsigned long)TS72XX_RTC_DATA_VIRT_BASE,
> .pfn= __phys_to_pfn(TS72XX_RTC_DATA_PHYS_BASE),
> .length = TS72XX_RTC_DATA_SIZE,
> .type = MT_DEVICE,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: 20% performance drop on PostgreSQL 9.2 from kernel 3.5.3 to 3.6-rc5 on AMD chipsets - bisected
On Fri, Sep 14, 2012 at 03:01:44PM -0700, Linus Torvalds wrote: > On Fri, Sep 14, 2012 at 2:56 PM, Peter Zijlstra > wrote: > > > > Both things change semantics, not looking at the entire package is new > > too. > > Well, the "idle_buddy" thing on its own could be considered to be > purely a caching thing. > > Sure, it doesn't take tsk_cpus_allowed() into account while setting up > the cache (since it's not dynamic enough), but *assuming* the common > case is that people let threads be on any of the cores of a package, > it should be possible to make the cache 100% equivalent with no > semantic change. No? > > The code doesn't even try to do that kind of "don't change semantics", > though, and makes the idle-buddy thing entirely different. Could it be that this machine has a non-power of two cores (6) and maybe the idle buddy selection doesn't work as expected? (Although it shouldn't since the commit message speaks also of non-power of two cores (40) and it works fine there). Anyway, here's the topology of the box: $ for i in $(ls cpu?/topology/*); do echo -n $i": "; cat $i; done cpu0/topology/core_id: 0 cpu0/topology/core_siblings: 3f cpu0/topology/core_siblings_list: 0-5 cpu0/topology/physical_package_id: 0 cpu0/topology/thread_siblings: 01 cpu0/topology/thread_siblings_list: 0 cpu1/topology/core_id: 1 cpu1/topology/core_siblings: 3f cpu1/topology/core_siblings_list: 0-5 cpu1/topology/physical_package_id: 0 cpu1/topology/thread_siblings: 02 cpu1/topology/thread_siblings_list: 1 cpu2/topology/core_id: 2 cpu2/topology/core_siblings: 3f cpu2/topology/core_siblings_list: 0-5 cpu2/topology/physical_package_id: 0 cpu2/topology/thread_siblings: 04 cpu2/topology/thread_siblings_list: 2 cpu3/topology/core_id: 3 cpu3/topology/core_siblings: 3f cpu3/topology/core_siblings_list: 0-5 cpu3/topology/physical_package_id: 0 cpu3/topology/thread_siblings: 08 cpu3/topology/thread_siblings_list: 3 cpu4/topology/core_id: 4 cpu4/topology/core_siblings: 3f cpu4/topology/core_siblings_list: 0-5 cpu4/topology/physical_package_id: 0 cpu4/topology/thread_siblings: 10 cpu4/topology/thread_siblings_list: 4 cpu5/topology/core_id: 5 cpu5/topology/core_siblings: 3f cpu5/topology/core_siblings_list: 0-5 cpu5/topology/physical_package_id: 0 cpu5/topology/thread_siblings: 20 cpu5/topology/thread_siblings_list: 5 -- Regards/Gruss, Boris. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/7] mm: add CONFIG_DEBUG_VM_RB build option
On 09/04/2012 11:20 AM, Michel Lespinasse wrote: > Add a CONFIG_DEBUG_VM_RB build option for the previously existing > DEBUG_MM_RB code. Now that Andi Kleen modified it to avoid using > recursive algorithms, we can expose it a bit more. > > Also extend this code to validate_mm() after stack expansion, and to > check that the vma's start and last pgoffs have not changed since the > nodes were inserted on the anon vma interval tree (as it is important > that the nodes be reindexed after each such update). This patch exposes the following warning: [ 24.977502] [ cut here ] [ 24.979089] WARNING: at mm/interval_tree.c:110 anon_vma_interval_tree_verify+0x81/0xa0() [ 24.981765] Pid: 5928, comm: trinity-child37 Tainted: G W 3.6.0-rc5-next-20120914-sasha-3-g7deb7fa-dirty #333 [ 24.985501] Call Trace: [ 24.986345] [] ? anon_vma_interval_tree_verify+0x81/0xa0 [ 24.988535] [] warn_slowpath_common+0x86/0xb0 [ 24.990636] [] warn_slowpath_null+0x15/0x20 [ 24.992658] [] anon_vma_interval_tree_verify+0x81/0xa0 [ 24.994980] [] validate_mm+0x58/0x1e0 [ 24.996772] [] vma_link+0x94/0xe0 [ 24.997719] [] copy_vma+0x279/0x2e0 [ 24.998522] [] ? trace_hardirqs_off+0xd/0x10 [ 25.000772] [] move_vma+0xa9/0x260 [ 25.002499] [] sys_mremap+0x475/0x540 [ 25.004364] [] tracesys+0xe1/0xe6 [ 25.006108] ---[ end trace 7c901670963aa6e2 ]--- The code line is WARN_ON_ONCE(node->cached_vma_last != avc_last_pgoff(node)); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: 20% performance drop on PostgreSQL 9.2 from kernel 3.5.3 to 3.6-rc5 on AMD chipsets - bisected
On Fri, 2012-09-14 at 15:01 -0700, Linus Torvalds wrote: > Sure, it doesn't take tsk_cpus_allowed() into account while setting up > the cache (since it's not dynamic enough), but *assuming* the common > case is that people let threads be on any of the cores of a package, > it should be possible to make the cache 100% equivalent with no > semantic change. No? I'm not seeing how it could be. Only ever looking at 1 other cpu (regardless which one) cannot be the same as checking 'all' of them. Suppose we have the 6 core AMD chip, a task being woken on cpu0 would look at cpus 1-6 (the entire package shares cache) to see if any of them was idle. Only looking at a single cpu will avoid looking at the other 4. The chance of finding an idle cpu to run on is much bigger the more cpus you look at (also more expensive). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[BUG 3.6-rc] samba works rather randomly with w2k+debian server
3.5.3 and older works, 3.6-rc not -> shared directories sometimes work, sometimes not, /etc/init.d/samba restart did help atleast once with 3.6-rc5, hope this helps thanks -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] cgroup TODOs
Hello, On Fri, Sep 14, 2012 at 06:03:16PM -0400, Dhaval Giani wrote: > > > > * Sort & unique when listing tasks. Even the documentation says it > > doesn't happen but we have a good hunk of code doing it in > > cgroup.c. I'm gonna rip it out at some point. Again, if you > > don't like it, scream. > > I think some userspace tools do assume the uniq bit. So if we can > preserve that, great! Can you point me to those? If there are users depending on it, I won't break it, at least for now, but I at least wanna know more about them. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] cgroup TODOs
> > * Sort & unique when listing tasks. Even the documentation says it > doesn't happen but we have a good hunk of code doing it in > cgroup.c. I'm gonna rip it out at some point. Again, if you > don't like it, scream. > I think some userspace tools do assume the uniq bit. So if we can preserve that, great! Thanks Dhaval -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] KSM: numa awareness sysfs knob
On Fri, 14 Sep 2012 23:22:47 +0200
Petr Holasek wrote:
> Introduces new sysfs boolean knob /sys/kernel/mm/ksm/merge_nodes
I wonder if merge_across_nodes would be a better name.
> which control merging pages across different numa nodes.
> When it is set to zero only pages from the same node are merged,
> otherwise pages from all nodes can be merged together (default behavior).
>
> Typical use-case could be a lot of KVM guests on NUMA machine
> and cpus from more distant nodes would have significant increase
> of access latency to the merged ksm page. Sysfs knob was choosen
> for higher scalability.
Well... what is the use case for merge_nodes=0? IOW, why shouldn't we
make this change non-optional and avoid the sysfs knob?
> Every numa node has its own stable & unstable trees because
> of faster searching and inserting. Changing of merge_nodes
> value is possible only when there are not any ksm shared pages in system.
>
> This patch also adds share_all sysfs knob which can be used for adding
> all anon vmas of all processes in system to ksmd scan queue. Knob can be
> triggered only when run knob is set to zero.
I really don't understand this share_all thing. From reading the code,
it is a once-off self-resetting trigger thing. Why? How is one to use
this? What's the benefit? What's the effect?
> I've tested this patch on numa machines with 2, 4 and 8 nodes and
> measured speed of memory access inside of KVM guests with memory pinned
> to one of nodes with this benchmark:
>
> http://pholasek.fedorapeople.org/alloc_pg.c
>
> Population standard deviations of access times in percentage of average
> were following:
>
> merge_nodes=1
> 2 nodes 1.4%
> 4 nodes 1.6%
> 8 nodes 1.7%
>
> merge_nodes=0
> 2 nodes 1%
> 4 nodes 0.32%
> 8 nodes 0.018%
>
>
> ...
>
> @@ -462,7 +473,13 @@ static void remove_node_from_stable_tree(struct
> stable_node *stable_node)
> cond_resched();
> }
>
> - rb_erase(_node->node, _stable_tree);
> + if (ksm_merge_nodes)
> + nid = 0;
> + else
> + nid = pfn_to_nid(stable_node->kpfn);
This sequence happens three times - it might be a little tidier to
capture the above into a separate helper function. Or not bother ;)
One benefit of the standalone function is that it provides a nice site
for a comment
> + rb_erase(_node->node,
> + _stable_tree[nid]);
> free_stable_node(stable_node);
> }
>
>
> ...
>
> +static int ksmd_should_run(void)
> +{
> + return (ksm_run & KSM_RUN_MERGE) && !list_empty(_mm_head.mm_list);
> +}
> +
> +static int ksmd_should_madvise(void)
> +{
> + return ksm_share_all;
> +}
> +
> +static int ksm_madvise_all(void)
> +{
> + struct task_struct *p;
> + int err;
> +
> + for_each_process(p) {
what, what. We can't just go waltzing across the task list without
taking any locks. Needs rcu_read_lock(), methinks.
Also... I've forgotten how threads/processes are arranged. Will this
walk across all the threads in the system? If so, that would be
terribly inefficient walking 1000 task structs which share a single mm,
manipulating that mm 1000 times. It might be better to walk the mm's
instead - see mm_struct.mmlist.
> + read_lock(_lock);
> +
> + if (!p->mm)
> + goto out;
> +
> + down_write(>mm->mmap_sem);
whoa, you can't do down_write() inside read_lock().
Please, immediately put down your mail client, read
Documentation/SubmitChecklist section 12 and go make the appropriate
changes to your kernel .config.
> + err = ksm_madvise_mm(p->mm);
> + up_write(>mm->mmap_sem);
> +out:
> + read_unlock(_lock);
> + if (err)
> + break;
> + cond_resched();
> + }
> + return err;
> +}
> +
> +/**
> + * ksm_do_scan - the ksm scanner main worker function.
> + * @scan_npages - number of pages we want to scan before we return.
> + */
> +static void ksm_do_scan(unsigned int scan_npages)
> +{
> + struct rmap_item *rmap_item;
> + struct page *uninitialized_var(page);
gcc is silly. I think that got fixed in more recent versions.
> + while (scan_npages-- && likely(!freezing(current))) {
> + cond_resched();
> + rmap_item = scan_get_next_rmap_item();
> + if (!rmap_item)
> + return;
> + if (!PageKsm(page) || !in_stable_tree(rmap_item))
> + cmp_and_merge_page(page, rmap_item);
> + put_page(page);
> + }
> +}
> +
> +static int ksm_scan_thread(void *nothing)
> +{
> + set_freezable();
> + set_user_nice(current, 5);
The reason for the set_user_nice() is a total mystery to this and any
other reader. Hence it needs a comment.
> + while (!kthread_should_stop()) {
> + mutex_lock(_thread_mutex);
> + if (ksmd_should_madvise()) {
> +
Re: 20% performance drop on PostgreSQL 9.2 from kernel 3.5.3 to 3.6-rc5 on AMD chipsets - bisected
On Fri, Sep 14, 2012 at 2:56 PM, Peter Zijlstra wrote: > > Both things change semantics, not looking at the entire package is new > too. Well, the "idle_buddy" thing on its own could be considered to be purely a caching thing. Sure, it doesn't take tsk_cpus_allowed() into account while setting up the cache (since it's not dynamic enough), but *assuming* the common case is that people let threads be on any of the cores of a package, it should be possible to make the cache 100% equivalent with no semantic change. No? The code doesn't even try to do that kind of "don't change semantics", though, and makes the idle-buddy thing entirely different. 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: linux-next: Tree for Sept 14 (sata_highhbank)
On 09/14/2012 12:04 PM, Randy Dunlap wrote: > On 09/14/2012 12:38 AM, Stephen Rothwell wrote: > >> Hi all, >> >> Changes since 201209013: >> > > > > on i386: > > CONFIG_SATA_HIGHBANK=m > # CONFIG_SATA_AHCI_PLATFORM is not set > > ERROR: "ahci_sdev_attrs" [drivers/ata/sata_highbank.ko] undefined! > ERROR: "ahci_shost_attrs" [drivers/ata/sata_highbank.ko] undefined! > ERROR: "ahci_ops" [drivers/ata/sata_highbank.ko] undefined! > ERROR: "ahci_dev_classify" [drivers/ata/sata_highbank.ko] undefined! > ERROR: "ahci_start_engine" [drivers/ata/sata_highbank.ko] undefined! > ERROR: "ahci_stop_engine" [drivers/ata/sata_highbank.ko] undefined! > ERROR: "ahci_interrupt" [drivers/ata/sata_highbank.ko] undefined! > ERROR: "ahci_print_info" [drivers/ata/sata_highbank.ko] undefined! > ERROR: "ahci_reset_em" [drivers/ata/sata_highbank.ko] undefined! > ERROR: "ahci_ignore_sss" [drivers/ata/sata_highbank.ko] undefined! > ERROR: "ahci_set_em_messages" [drivers/ata/sata_highbank.ko] undefined! > ERROR: "ahci_save_initial_config" [drivers/ata/sata_highbank.ko] undefined! > ERROR: "ahci_init_controller" [drivers/ata/sata_highbank.ko] undefined! > ERROR: "ahci_reset_controller" [drivers/ata/sata_highbank.ko] undefined! > Fix patch follows. Do I need to submit it as a separate patch or is this sufficient? --Mark Langsdorf Calxeda, Inc. [PATCH] ata: fix compile error for sata_highbank sata_highbank depends on the libahci library. Signed-off-by: Mark Langsdorf --- drivers/ata/Makefile |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile index 8b384f1..9329daf 100644 --- a/drivers/ata/Makefile +++ b/drivers/ata/Makefile @@ -9,7 +9,7 @@ obj-$(CONFIG_SATA_FSL) += sata_fsl.o obj-$(CONFIG_SATA_INIC162X)+= sata_inic162x.o obj-$(CONFIG_SATA_SIL24) += sata_sil24.o obj-$(CONFIG_SATA_DWC) += sata_dwc_460ex.o -obj-$(CONFIG_SATA_HIGHBANK)+= sata_highbank.o +obj-$(CONFIG_SATA_HIGHBANK)+= sata_highbank.o libahci.o # SFF w/ custom DMA obj-$(CONFIG_PDC_ADMA) += pdc_adma.o -- 1.7.5.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: 20% performance drop on PostgreSQL 9.2 from kernel 3.5.3 to 3.6-rc5 on AMD chipsets - bisected
On Fri, 2012-09-14 at 23:56 +0200, Peter Zijlstra wrote: > On Fri, 2012-09-14 at 14:44 -0700, Linus Torvalds wrote: > > On Fri, Sep 14, 2012 at 2:40 PM, Peter Zijlstra > > wrote: > > > > > > The problem the patch is trying to address is not having to scan an > > > entire package for idle cores on every wakeup now that packages are > > > getting stupid big. > > > > No, it does something *else* too. That whole "left-right" logic to > > (according to the commit message) "prevent bouncing" is entirely new, > > afaik. > > > > So it is *not* just about avoiding to have to scan the whole package. > > It changes actual semantics too. No? > > Both things change semantics, not looking at the entire package is new > too. But yeah I guess you could look at the exact cross-stitching as an > enhancement to the 'idle_buggy' thing. What I'm saying is that having an idle_buggy means you have to assign one in the first place, his left-right stuff might not be the simplest means to do that -- in fact I suggested he do a simple shift first time I saw that patch. So if not the left-right thing, you still need to do _something_ to make the idle_buggy work at all. So its not entirely separate. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] cgroup TODOs
Hello, Vivek, Peter. On Fri, Sep 14, 2012 at 11:14:47AM -0400, Vivek Goyal wrote: > We don't have to start with 0%. We can keep a pool with dynamic % and > launch all the virtual machines from that single pool. So nobody starts > with 0%. If we require certain % for a machine, only then we look at > peers and see if we have bandwidth free and create cgroup and move virtual > machine there, otherwise we deny resources. > > So I think it is doable just that it is painful and tricky and I think > lot of it will be in user space. I think the system-wide % thing is rather distracting for the discussion at hand (and I don't think being able to specify X% of the whole system when you're three level down the resource hierarchy makes sense anyway). Let's focus on tasks vs. groups. > > > So > > > an easier way is to stick to the model of relative weights/share and > > > let user specify relative importance of a virtual machine and actual > > > quota or % will vary dynamically depending on other tasks/components > > > in the system. > > > > > > Thoughts? > > > > cpu does the relative weight, so 'users' will have to deal with it > > anyway regardless of blk, its effectively free of learning curve for all > > subsequent controllers. > > I am inclined to keep it simple in kernel and just follow cpu model of > relative weights and treating tasks and gropu at same level in the > hierarchy. It makes behavior consistent across the controllers and I > think it might just work for majority of cases. I think we need to stick to one model for all controllers; otherwise, it gets confusing and unified hierarchy can't work. That said, I'm not too happy about how cpu is handling it now. * As I wrote before, the configuration esacpes cgroup proper and the mapping from per-task value to group weight is essentially arbitrary and may not exist depending on the resource type. * The proportion of each group fluctuates as tasks fork and exit in the parent group, which is confusing. * cpu deals with tasks but blkcg deals with iocontexts and memcg, which currently doesn't implement proportional control, deals with address spaces (processes). The proportions wouldn't even fluctuate the same way across different controllers. So, I really don't think the current model used by cpu is a good one and we rather should treat the tasks as a group competing with the rest of child groups. Whether we can change that at this point, I don't know. Peter, what do you think? Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 20% performance drop on PostgreSQL 9.2 from kernel 3.5.3 to 3.6-rc5 on AMD chipsets - bisected
On Fri, 2012-09-14 at 14:44 -0700, Linus Torvalds wrote: > On Fri, Sep 14, 2012 at 2:40 PM, Peter Zijlstra > wrote: > > > > The problem the patch is trying to address is not having to scan an > > entire package for idle cores on every wakeup now that packages are > > getting stupid big. > > No, it does something *else* too. That whole "left-right" logic to > (according to the commit message) "prevent bouncing" is entirely new, > afaik. > > So it is *not* just about avoiding to have to scan the whole package. > It changes actual semantics too. No? Both things change semantics, not looking at the entire package is new too. But yeah I guess you could look at the exact cross-stitching as an enhancement to the 'idle_buggy' thing. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] cgroup TODOs
On Fri, Sep 14, 2012 at 9:29 PM, Tejun Heo wrote: > On Fri, Sep 14, 2012 at 09:58:30AM -0400, Vivek Goyal wrote: >> I am little concerned about above and wondering how systemd and libvirt >> will interact and behave out of the box. >> >> Currently systemd does not create its own hierarchy under blkio and >> libvirt does. So putting all together means there is no way to avoid >> the overhead of systemd created hierarchy. >> >> \ >> | >> +- system >> | >> +- libvirtd.service >> | >> +- virt-machine1 >> +- virt-machine2 >> >> So there is now way to avoid the overhead of two levels of hierarchy >> created by systemd. I really wish that systemd gets rid of "system" >> cgroup and puts services directly in top level group. Creating deeper >> hieararchices is expensive. The idea here is to split equally between the "system" and the "user"s at that level. That all can be re-considered and changed if really needed, but it's not an unintentionally created directory. Thanks, Kay -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] [PATCH v10 8/8] block: Add bio_clone_bioset(), bio_clone_kmalloc()
On Thu, Sep 06, 2012 at 03:35:02PM -0700, Kent Overstreet wrote: > Previously, there was bio_clone() but it only allocated from the fs bio > set; as a result various users were open coding it and using > __bio_clone(). Explain in the header the reasoning behind the change to dm-crypt so that it no longer resets bi_idx to 0 too? > - clone->bi_idx = 0; 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: 20% performance drop on PostgreSQL 9.2 from kernel 3.5.3 to 3.6-rc5 on AMD chipsets - bisected
On Fri, Sep 14, 2012 at 11:40:43PM +0200, Peter Zijlstra wrote: > Hmm, cute. What kind of machine did you test it on? Nikolay's machines > look to be smallish AMD X6 or ancient Intel c2d (the patch will indeed > have absolutely no effect on a dual core). Yep, I took an X6 too. So it's a single-socket, 6-core AMD, F10h. > I'll see about running pgbench on a bigger Intel tomorrow if Mike > doesn't beat me to it. Can try that too on one of the bigger machines I have, if needed. > The problem the patch is trying to address is not having to scan an > entire package for idle cores on every wakeup now that packages are > getting stupid big. > > Regressing Postgres otoh isn't nice either.. > > Anyway, I guess I'm fine with nixing this patch until we figure out > something smarter.. > > I'm also curious to know wth postgres does that this patch makes such a > big difference... I'm using 9.1 in Debian testing while Nikolay is using 9.2. Thanks. -- Regards/Gruss, Boris. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: 20% performance drop on PostgreSQL 9.2 from kernel 3.5.3 to 3.6-rc5 on AMD chipsets - bisected
On Fri, Sep 14, 2012 at 2:40 PM, Peter Zijlstra wrote: > > The problem the patch is trying to address is not having to scan an > entire package for idle cores on every wakeup now that packages are > getting stupid big. No, it does something *else* too. That whole "left-right" logic to (according to the commit message) "prevent bouncing" is entirely new, afaik. So it is *not* just about avoiding to have to scan the whole package. It changes actual semantics too. No? 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: 20% performance drop on PostgreSQL 9.2 from kernel 3.5.3 to 3.6-rc5 on AMD chipsets - bisected
On Fri, Sep 14, 2012 at 2:27 PM, Borislav Petkov wrote: > > as Nikolay says below, we have a regression in 3.6 with pgbench's > benchmark in postgresql. > > I was able to reproduce it on another box here and did a bisection run. > It pointed to the commit below. Ok. I guess we should just revert it. However, before we do that, maybe Mike can make it just use the exact old semantics of select_idle_sibling() in the update_top_cache_domain() logic. Because the patch in question seems to do two things: (a) cache the "idle_buggy" logic, so that we don't have those costly loops (b) change it to do that "left-right" thing. and that (b) thing may be what causes a regression for you. So my gut feel is that the patch was wrong to begin with, exactly because it did two independent changes. It *should* have treated those two issues as independent changes and separate commits. Maybe I'm mis-reading it. Mike? Peter? Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 03/24] ARM: ebsa110: use __iomem pointers for MMIO
ARM is moving to stricter checks on readl/write functions,
so we need to use the correct types everywhere.
Signed-off-by: Arnd Bergmann
---
arch/arm/mach-ebsa110/core.c |8
arch/arm/mach-ebsa110/core.h | 12 ++--
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-ebsa110/core.c b/arch/arm/mach-ebsa110/core.c
index 6f80686..f0fe6b5 100644
--- a/arch/arm/mach-ebsa110/core.c
+++ b/arch/arm/mach-ebsa110/core.c
@@ -74,22 +74,22 @@ static struct map_desc ebsa110_io_desc[] __initdata = {
* sparse external-decode ISAIO space
*/
{ /* IRQ_STAT/IRQ_MCLR */
- .virtual= IRQ_STAT,
+ .virtual= (unsigned long)IRQ_STAT,
.pfn= __phys_to_pfn(TRICK4_PHYS),
.length = TRICK4_SIZE,
.type = MT_DEVICE
}, {/* IRQ_MASK/IRQ_MSET */
- .virtual= IRQ_MASK,
+ .virtual= (unsigned long)IRQ_MASK,
.pfn= __phys_to_pfn(TRICK3_PHYS),
.length = TRICK3_SIZE,
.type = MT_DEVICE
}, {/* SOFT_BASE */
- .virtual= SOFT_BASE,
+ .virtual= (unsigned long)SOFT_BASE,
.pfn= __phys_to_pfn(TRICK1_PHYS),
.length = TRICK1_SIZE,
.type = MT_DEVICE
}, {/* PIT_BASE */
- .virtual= PIT_BASE,
+ .virtual= (unsigned long)PIT_BASE,
.pfn= __phys_to_pfn(TRICK0_PHYS),
.length = TRICK0_SIZE,
.type = MT_DEVICE
diff --git a/arch/arm/mach-ebsa110/core.h b/arch/arm/mach-ebsa110/core.h
index c93c9e4..afe137e 100644
--- a/arch/arm/mach-ebsa110/core.h
+++ b/arch/arm/mach-ebsa110/core.h
@@ -31,11 +31,11 @@
#define TRICK7_PHYS0xf3c0
/* Virtual addresses */
-#define PIT_BASE 0xfc00 /* trick 0 */
-#define SOFT_BASE 0xfd00 /* trick 1 */
-#define IRQ_MASK 0xfe00 /* trick 3 - read */
-#define IRQ_MSET 0xfe00 /* trick 3 - write */
-#define IRQ_STAT 0xff00 /* trick 4 - read */
-#define IRQ_MCLR 0xff00 /* trick 4 - write */
+#define PIT_BASE IOMEM(0xfc00) /* trick 0 */
+#define SOFT_BASE IOMEM(0xfd00) /* trick 1 */
+#define IRQ_MASK IOMEM(0xfe00) /* trick 3 - read */
+#define IRQ_MSET IOMEM(0xfe00) /* trick 3 - write */
+#define IRQ_STAT IOMEM(0xff00) /* trick 4 - read */
+#define IRQ_MCLR IOMEM(0xff00) /* trick 4 - write */
#endif
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 14/24] ARM: prima2: use __iomem pointers for MMIO
ARM is moving to stricter checks on readl/write functions, so we need to use the correct types everywhere. Cc: Barry Song Signed-off-by: Arnd Bergmann --- arch/arm/mach-prima2/include/mach/uncompress.h |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-prima2/include/mach/uncompress.h b/arch/arm/mach-prima2/include/mach/uncompress.h index 83125c6..0c898fc 100644 --- a/arch/arm/mach-prima2/include/mach/uncompress.h +++ b/arch/arm/mach-prima2/include/mach/uncompress.h @@ -25,11 +25,11 @@ static __inline__ void putc(char c) * during kernel decompression, all mappings are flat: * virt_addr == phys_addr */ - while (__raw_readl(SIRFSOC_UART1_PA_BASE + SIRFSOC_UART_TXFIFO_STATUS) + while (__raw_readl((void __iomem *)SIRFSOC_UART1_PA_BASE + SIRFSOC_UART_TXFIFO_STATUS) & SIRFSOC_UART1_TXFIFO_FULL) barrier(); - __raw_writel(c, SIRFSOC_UART1_PA_BASE + SIRFSOC_UART_TXFIFO_DATA); + __raw_writel(c, (void __iomem *)SIRFSOC_UART1_PA_BASE + SIRFSOC_UART_TXFIFO_DATA); } static inline void flush(void) -- 1.7.10 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 11/24] ARM: lpc32xx: use __iomem pointers for MMIO
ARM is moving to stricter checks on readl/write functions,
so we need to use the correct types everywhere.
Cc: Roland Stigge
Cc: Wolfram Sang
Signed-off-by: Arnd Bergmann
---
arch/arm/mach-lpc32xx/common.c|8
arch/arm/mach-lpc32xx/include/mach/hardware.h |2 +-
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-lpc32xx/common.c b/arch/arm/mach-lpc32xx/common.c
index a48dc2d..0d4db8c 100644
--- a/arch/arm/mach-lpc32xx/common.c
+++ b/arch/arm/mach-lpc32xx/common.c
@@ -177,25 +177,25 @@ u32 clk_get_pclk_div(void)
static struct map_desc lpc32xx_io_desc[] __initdata = {
{
- .virtual= IO_ADDRESS(LPC32XX_AHB0_START),
+ .virtual= (unsigned long)IO_ADDRESS(LPC32XX_AHB0_START),
.pfn= __phys_to_pfn(LPC32XX_AHB0_START),
.length = LPC32XX_AHB0_SIZE,
.type = MT_DEVICE
},
{
- .virtual= IO_ADDRESS(LPC32XX_AHB1_START),
+ .virtual= (unsigned long)IO_ADDRESS(LPC32XX_AHB1_START),
.pfn= __phys_to_pfn(LPC32XX_AHB1_START),
.length = LPC32XX_AHB1_SIZE,
.type = MT_DEVICE
},
{
- .virtual= IO_ADDRESS(LPC32XX_FABAPB_START),
+ .virtual= (unsigned
long)IO_ADDRESS(LPC32XX_FABAPB_START),
.pfn= __phys_to_pfn(LPC32XX_FABAPB_START),
.length = LPC32XX_FABAPB_SIZE,
.type = MT_DEVICE
},
{
- .virtual= IO_ADDRESS(LPC32XX_IRAM_BASE),
+ .virtual= (unsigned long)IO_ADDRESS(LPC32XX_IRAM_BASE),
.pfn= __phys_to_pfn(LPC32XX_IRAM_BASE),
.length = (LPC32XX_IRAM_BANK_SIZE * 2),
.type = MT_DEVICE
diff --git a/arch/arm/mach-lpc32xx/include/mach/hardware.h
b/arch/arm/mach-lpc32xx/include/mach/hardware.h
index 33e1dde..69065de 100644
--- a/arch/arm/mach-lpc32xx/include/mach/hardware.h
+++ b/arch/arm/mach-lpc32xx/include/mach/hardware.h
@@ -25,7 +25,7 @@
/*
* This macro relies on fact that for all HW i/o addresses bits 20-23 are 0
*/
-#define IO_ADDRESS(x) (x) & 0xff00) >> 4) | ((x) & 0xf)) |\
+#define IO_ADDRESS(x) IOMEM(x) & 0xff00) >> 4) | ((x) & 0xf)) |\
IO_BASE)
#define io_p2v(x) ((void __iomem *) (unsigned long) IO_ADDRESS(x))
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: 20% performance drop on PostgreSQL 9.2 from kernel 3.5.3 to 3.6-rc5 on AMD chipsets - bisected
On Fri, 2012-09-14 at 23:27 +0200, Borislav Petkov wrote: > > I was able to reproduce it on another box here and did a bisection run. > It pointed to the commit below. > > And yes, reverting that commit fixes the issue here. Hmm, cute. What kind of machine did you test it on? Nikolay's machines look to be smallish AMD X6 or ancient Intel c2d (the patch will indeed have absolutely no effect on a dual core). I'll see about running pgbench on a bigger Intel tomorrow if Mike doesn't beat me to it. The problem the patch is trying to address is not having to scan an entire package for idle cores on every wakeup now that packages are getting stupid big. Regressing Postgres otoh isn't nice either.. Anyway, I guess I'm fine with nixing this patch until we figure out something smarter.. I'm also curious to know wth postgres does that this patch makes such a big difference... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 08/24] ARM: iop32x: use __iomem pointers for MMIO
ARM is moving to stricter checks on readl/write functions,
so we need to use the correct types everywhere.
Cc: Imre Kaloz
Cc: Krzysztof Halasa
Cc: Lennert Buytenhek
Signed-off-by: Arnd Bergmann
---
arch/arm/mach-iop32x/glantank.c |2 +-
arch/arm/mach-ixp4xx/common.c |6 +++---
arch/arm/mach-ixp4xx/include/mach/cpu.h |5 +++--
arch/arm/mach-ixp4xx/include/mach/ixp4xx-regs.h |2 +-
4 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-iop32x/glantank.c b/arch/arm/mach-iop32x/glantank.c
index c15a100..02e20c3 100644
--- a/arch/arm/mach-iop32x/glantank.c
+++ b/arch/arm/mach-iop32x/glantank.c
@@ -183,7 +183,7 @@ static struct i2c_board_info __initdata
glantank_i2c_devices[] = {
static void glantank_power_off(void)
{
- __raw_writeb(0x01, 0xfe8d0004);
+ __raw_writeb(0x01, IOMEM(0xfe8d0004));
while (1)
;
diff --git a/arch/arm/mach-ixp4xx/common.c b/arch/arm/mach-ixp4xx/common.c
index a9f8094..8c9cd5d 100644
--- a/arch/arm/mach-ixp4xx/common.c
+++ b/arch/arm/mach-ixp4xx/common.c
@@ -53,17 +53,17 @@ static struct clock_event_device clockevent_ixp4xx;
*/
static struct map_desc ixp4xx_io_desc[] __initdata = {
{ /* UART, Interrupt ctrl, GPIO, timers, NPEs, MACs, USB */
- .virtual= IXP4XX_PERIPHERAL_BASE_VIRT,
+ .virtual= (unsigned long)IXP4XX_PERIPHERAL_BASE_VIRT,
.pfn= __phys_to_pfn(IXP4XX_PERIPHERAL_BASE_PHYS),
.length = IXP4XX_PERIPHERAL_REGION_SIZE,
.type = MT_DEVICE
}, {/* Expansion Bus Config Registers */
- .virtual= IXP4XX_EXP_CFG_BASE_VIRT,
+ .virtual= (unsigned long)IXP4XX_EXP_CFG_BASE_VIRT,
.pfn= __phys_to_pfn(IXP4XX_EXP_CFG_BASE_PHYS),
.length = IXP4XX_EXP_CFG_REGION_SIZE,
.type = MT_DEVICE
}, {/* PCI Registers */
- .virtual= IXP4XX_PCI_CFG_BASE_VIRT,
+ .virtual= (unsigned long)IXP4XX_PCI_CFG_BASE_VIRT,
.pfn= __phys_to_pfn(IXP4XX_PCI_CFG_BASE_PHYS),
.length = IXP4XX_PCI_CFG_REGION_SIZE,
.type = MT_DEVICE
diff --git a/arch/arm/mach-ixp4xx/include/mach/cpu.h
b/arch/arm/mach-ixp4xx/include/mach/cpu.h
index b2ef65d..e3d5a2e 100644
--- a/arch/arm/mach-ixp4xx/include/mach/cpu.h
+++ b/arch/arm/mach-ixp4xx/include/mach/cpu.h
@@ -14,6 +14,7 @@
#ifndef __ASM_ARCH_CPU_H__
#define __ASM_ARCH_CPU_H__
+#include
#include
/* Processor id value in CP15 Register 0 */
@@ -37,7 +38,7 @@
static inline u32 ixp4xx_read_feature_bits(void)
{
- u32 val = ~*IXP4XX_EXP_CFG2;
+ u32 val = ~__raw_readl(IXP4XX_EXP_CFG2);
if (cpu_is_ixp42x_rev_a0())
return IXP42X_FEATURE_MASK & ~(IXP4XX_FEATURE_RCOMP |
@@ -51,7 +52,7 @@ static inline u32 ixp4xx_read_feature_bits(void)
static inline void ixp4xx_write_feature_bits(u32 value)
{
- *IXP4XX_EXP_CFG2 = ~value;
+ __raw_writel(~cpu_to_le32(value), IXP4XX_EXP_CFG2);
}
#endif /* _ASM_ARCH_CPU_H */
diff --git a/arch/arm/mach-ixp4xx/include/mach/ixp4xx-regs.h
b/arch/arm/mach-ixp4xx/include/mach/ixp4xx-regs.h
index 97c530f..2272f5a 100644
--- a/arch/arm/mach-ixp4xx/include/mach/ixp4xx-regs.h
+++ b/arch/arm/mach-ixp4xx/include/mach/ixp4xx-regs.h
@@ -92,7 +92,7 @@
/*
* Expansion Bus Controller registers.
*/
-#define IXP4XX_EXP_REG(x) ((volatile u32 *)(IXP4XX_EXP_CFG_BASE_VIRT+(x)))
+#define IXP4XX_EXP_REG(x) ((volatile u32 __iomem
*)(IXP4XX_EXP_CFG_BASE_VIRT+(x)))
#define IXP4XX_EXP_CS0 IXP4XX_EXP_REG(IXP4XX_EXP_CS0_OFFSET)
#define IXP4XX_EXP_CS1 IXP4XX_EXP_REG(IXP4XX_EXP_CS1_OFFSET)
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 13/24] ARM: nomadik: use __iomem pointers for MMIO
ARM is moving to stricter checks on readl/write functions,
so we need to use the correct types everywhere.
Cc: Alessandro Rubini
Cc: Linus Walleij
Cc: STEricsson
Signed-off-by: Arnd Bergmann
---
arch/arm/mach-nomadik/board-nhk8815.c |3 +--
arch/arm/mach-nomadik/include/mach/hardware.h |2 +-
arch/arm/mach-nomadik/include/mach/uncompress.h |8
3 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-nomadik/board-nhk8815.c
b/arch/arm/mach-nomadik/board-nhk8815.c
index f4535a7..c3841a9 100644
--- a/arch/arm/mach-nomadik/board-nhk8815.c
+++ b/arch/arm/mach-nomadik/board-nhk8815.c
@@ -112,8 +112,7 @@ static struct mtd_partition nhk8815_partitions[] = {
static struct nomadik_nand_platform_data nhk8815_nand_data = {
.parts = nhk8815_partitions,
.nparts = ARRAY_SIZE(nhk8815_partitions),
- .options= NAND_COPYBACK | NAND_CACHEPRG | NAND_NO_PADDING \
- | NAND_NO_READRDY,
+ .options= NAND_COPYBACK | NAND_CACHEPRG | NAND_NO_PADDING,
.init = nhk8815_nand_init,
};
diff --git a/arch/arm/mach-nomadik/include/mach/hardware.h
b/arch/arm/mach-nomadik/include/mach/hardware.h
index 6316dba..02035e4 100644
--- a/arch/arm/mach-nomadik/include/mach/hardware.h
+++ b/arch/arm/mach-nomadik/include/mach/hardware.h
@@ -30,7 +30,7 @@
- NOMADIK_IO_VIRTUAL + NOMADIK_IO_PHYSICAL)
/* used in asm code, so no casts */
-#define IO_ADDRESS(x) ((x) - NOMADIK_IO_PHYSICAL + NOMADIK_IO_VIRTUAL)
+#define IO_ADDRESS(x) IOMEM((x) - NOMADIK_IO_PHYSICAL + NOMADIK_IO_VIRTUAL)
/*
* Base address defination for Nomadik Onchip Logic Block
diff --git a/arch/arm/mach-nomadik/include/mach/uncompress.h
b/arch/arm/mach-nomadik/include/mach/uncompress.h
index 071003b..7d4687e 100644
--- a/arch/arm/mach-nomadik/include/mach/uncompress.h
+++ b/arch/arm/mach-nomadik/include/mach/uncompress.h
@@ -27,10 +27,10 @@
struct amba_device;
#include
-#define NOMADIK_UART_DR0x101FB000
-#define NOMADIK_UART_LCRH 0x101FB02c
-#define NOMADIK_UART_CR0x101FB030
-#define NOMADIK_UART_FR0x101FB018
+#define NOMADIK_UART_DR(void __iomem *)0x101FB000
+#define NOMADIK_UART_LCRH (void __iomem *)0x101FB02c
+#define NOMADIK_UART_CR(void __iomem *)0x101FB030
+#define NOMADIK_UART_FR(void __iomem *)0x101FB018
static void putc(const char c)
{
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 07/24] ARM: iop13xx: use __iomem pointers for MMIO
ARM is moving to stricter checks on readl/write functions,
so we need to use the correct types everywhere.
Cc: Rob Herring
Cc: Lennert Buytenhek
Signed-off-by: Arnd Bergmann
---
arch/arm/mach-iop13xx/include/mach/iop13xx.h | 20 +---
arch/arm/mach-iop13xx/include/mach/memory.h | 14 +++---
arch/arm/mach-iop13xx/io.c | 12 ++--
arch/arm/mach-iop13xx/pci.c | 16 +++-
arch/arm/mach-iop13xx/pci.h |4 ++--
arch/arm/mach-iop13xx/setup.c| 10 +-
6 files changed, 36 insertions(+), 40 deletions(-)
diff --git a/arch/arm/mach-iop13xx/include/mach/iop13xx.h
b/arch/arm/mach-iop13xx/include/mach/iop13xx.h
index e190dcd..01b41ab 100644
--- a/arch/arm/mach-iop13xx/include/mach/iop13xx.h
+++ b/arch/arm/mach-iop13xx/include/mach/iop13xx.h
@@ -148,18 +148,16 @@ extern unsigned long get_iop_tick_rate(void);
* IOP13XX chipset registers
*/
#define IOP13XX_PMMR_PHYS_MEM_BASE0xffd8UL /* PMMR phys. address
*/
-#define IOP13XX_PMMR_VIRT_MEM_BASE0xfee8UL /* PMMR phys. address
*/
+#define IOP13XX_PMMR_VIRT_MEM_BASE(void __iomem *)(0xfee8UL) /*
PMMR phys. address */
#define IOP13XX_PMMR_MEM_WINDOW_SIZE 0x8
#define IOP13XX_PMMR_UPPER_MEM_VA (IOP13XX_PMMR_VIRT_MEM_BASE +\
IOP13XX_PMMR_MEM_WINDOW_SIZE - 1)
#define IOP13XX_PMMR_UPPER_MEM_PA (IOP13XX_PMMR_PHYS_MEM_BASE +\
IOP13XX_PMMR_MEM_WINDOW_SIZE - 1)
-#define IOP13XX_PMMR_VIRT_TO_PHYS(addr) (u32) ((u32) addr +\
- (IOP13XX_PMMR_PHYS_MEM_BASE\
- - IOP13XX_PMMR_VIRT_MEM_BASE))
-#define IOP13XX_PMMR_PHYS_TO_VIRT(addr) (u32) ((u32) addr -\
- (IOP13XX_PMMR_PHYS_MEM_BASE\
- - IOP13XX_PMMR_VIRT_MEM_BASE))
+#define IOP13XX_PMMR_VIRT_TO_PHYS(addr) (((addr) -
IOP13XX_PMMR_VIRT_MEM_BASE)\
+ + IOP13XX_PMMR_PHYS_MEM_BASE)
+#define IOP13XX_PMMR_PHYS_TO_VIRT(addr) (((addr) -
IOP13XX_PMMR_PHYS_MEM_BASE)\
+ + IOP13XX_PMMR_VIRT_MEM_BASE)
#define IOP13XX_REG_ADDR32(reg) (IOP13XX_PMMR_VIRT_MEM_BASE + (reg))
#define IOP13XX_REG_ADDR16(reg) (IOP13XX_PMMR_VIRT_MEM_BASE + (reg))
#define IOP13XX_REG_ADDR8(reg)(IOP13XX_PMMR_VIRT_MEM_BASE + (reg))
@@ -169,10 +167,10 @@ extern unsigned long get_iop_tick_rate(void);
#define IOP13XX_PMMR_SIZE 0x0008
/*=== Defines for Platform Devices =*/
-#define IOP13XX_UART0_PHYS (IOP13XX_PMMR_PHYS_MEM_BASE | 0x2300)
-#define IOP13XX_UART1_PHYS (IOP13XX_PMMR_PHYS_MEM_BASE | 0x2340)
-#define IOP13XX_UART0_VIRT (IOP13XX_PMMR_VIRT_MEM_BASE | 0x2300)
-#define IOP13XX_UART1_VIRT (IOP13XX_PMMR_VIRT_MEM_BASE | 0x2340)
+#define IOP13XX_UART0_PHYS (IOP13XX_PMMR_PHYS_MEM_BASE + 0x2300)
+#define IOP13XX_UART1_PHYS (IOP13XX_PMMR_PHYS_MEM_BASE + 0x2340)
+#define IOP13XX_UART0_VIRT (IOP13XX_PMMR_VIRT_MEM_BASE + 0x2300)
+#define IOP13XX_UART1_VIRT (IOP13XX_PMMR_VIRT_MEM_BASE + 0x2340)
#define IOP13XX_I2C0_PHYS (IOP13XX_PMMR_PHYS_MEM_BASE | 0x2500)
#define IOP13XX_I2C1_PHYS (IOP13XX_PMMR_PHYS_MEM_BASE | 0x2520)
diff --git a/arch/arm/mach-iop13xx/include/mach/memory.h
b/arch/arm/mach-iop13xx/include/mach/memory.h
index 1afa99e..7c032d0 100644
--- a/arch/arm/mach-iop13xx/include/mach/memory.h
+++ b/arch/arm/mach-iop13xx/include/mach/memory.h
@@ -16,12 +16,12 @@
#define IOP13XX_PMMR_P_START (IOP13XX_PMMR_PHYS_MEM_BASE)
#define IOP13XX_PMMR_P_END (IOP13XX_PMMR_PHYS_MEM_BASE + IOP13XX_PMMR_SIZE)
-static inline dma_addr_t __virt_to_lbus(unsigned long x)
+static inline dma_addr_t __virt_to_lbus(void __iomem *x)
{
return x + IOP13XX_PMMR_PHYS_MEM_BASE - IOP13XX_PMMR_VIRT_MEM_BASE;
}
-static inline unsigned long __lbus_to_virt(dma_addr_t x)
+static inline void __iomem *__lbus_to_virt(dma_addr_t x)
{
return x + IOP13XX_PMMR_VIRT_MEM_BASE - IOP13XX_PMMR_PHYS_MEM_BASE;
}
@@ -38,23 +38,23 @@ static inline unsigned long __lbus_to_virt(dma_addr_t x)
#define __arch_dma_to_virt(dev, addr) \
({ \
- unsigned long __virt; \
+ void * __virt; \
dma_addr_t __dma = addr;\
if (is_lbus_device(dev) && __is_lbus_dma(__dma))\
__virt = __lbus_to_virt(__dma); \
else\
- __virt =
[PATCH 20/24] input: rpcmouse: use __iomem pointers for MMIO
ARM is moving to stricter checks on readl/write functions, so we need to use the correct types everywhere. Cc: Dmitry Torokhov Cc: linux-in...@vger.kernel.org Signed-off-by: Arnd Bergmann --- drivers/input/mouse/rpcmouse.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/input/mouse/rpcmouse.c b/drivers/input/mouse/rpcmouse.c index 272dedd..21c60fe 100644 --- a/drivers/input/mouse/rpcmouse.c +++ b/drivers/input/mouse/rpcmouse.c @@ -42,7 +42,7 @@ static irqreturn_t rpcmouse_irq(int irq, void *dev_id) x = (short) iomd_readl(IOMD_MOUSEX); y = (short) iomd_readl(IOMD_MOUSEY); - b = (short) (__raw_readl(0xe031) ^ 0x70); + b = (short) (__raw_readl(IOMEM(0xe031)) ^ 0x70); dx = x - rpcmouse_lastx; dy = y - rpcmouse_lasty; -- 1.7.10 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 06/24] ARM: integrator: use __iomem pointers for MMIO
ARM is moving to stricter checks on readl/write functions,
so we need to use the correct types everywhere.
This patch has a few small conflicts with stuff in linux-next, which
we have to sort out in arm-soc.
Cc: Linus Walleij
Cc: Russell King
Signed-off-by: Arnd Bergmann
---
arch/arm/mach-integrator/core.c |4 ++--
arch/arm/mach-integrator/cpu.c |8
arch/arm/mach-integrator/integrator_ap.c | 12 ++--
arch/arm/mach-integrator/integrator_cp.c |6 +++---
arch/arm/mach-integrator/pci_v3.c| 12 ++--
5 files changed, 21 insertions(+), 21 deletions(-)
diff --git a/arch/arm/mach-integrator/core.c b/arch/arm/mach-integrator/core.c
index 3fa6c51..a432d43 100644
--- a/arch/arm/mach-integrator/core.c
+++ b/arch/arm/mach-integrator/core.c
@@ -95,8 +95,8 @@ arch_initcall(integrator_init);
* UART0 76
* UART1 54
*/
-#define SC_CTRLC IO_ADDRESS(INTEGRATOR_SC_CTRLC)
-#define SC_CTRLS IO_ADDRESS(INTEGRATOR_SC_CTRLS)
+#define SC_CTRLC __io_address(INTEGRATOR_SC_CTRLC)
+#define SC_CTRLS __io_address(INTEGRATOR_SC_CTRLS)
static void integrator_uart_set_mctrl(struct amba_device *dev, void __iomem
*base, unsigned int mctrl)
{
diff --git a/arch/arm/mach-integrator/cpu.c b/arch/arm/mach-integrator/cpu.c
index fbb4577..590c192 100644
--- a/arch/arm/mach-integrator/cpu.c
+++ b/arch/arm/mach-integrator/cpu.c
@@ -25,10 +25,10 @@
static struct cpufreq_driver integrator_driver;
-#define CM_ID IO_ADDRESS(INTEGRATOR_HDR_ID)
-#define CM_OSC IO_ADDRESS(INTEGRATOR_HDR_OSC)
-#define CM_STAT IO_ADDRESS(INTEGRATOR_HDR_STAT)
-#define CM_LOCK IO_ADDRESS(INTEGRATOR_HDR_LOCK)
+#define CM_ID __io_address(INTEGRATOR_HDR_ID)
+#define CM_OSC __io_address(INTEGRATOR_HDR_OSC)
+#define CM_STAT __io_address(INTEGRATOR_HDR_STAT)
+#define CM_LOCK __io_address(INTEGRATOR_HDR_LOCK)
static const struct icst_params lclk_params = {
.ref= 2400,
diff --git a/arch/arm/mach-integrator/integrator_ap.c
b/arch/arm/mach-integrator/integrator_ap.c
index 3b22675..c8e448e 100644
--- a/arch/arm/mach-integrator/integrator_ap.c
+++ b/arch/arm/mach-integrator/integrator_ap.c
@@ -133,17 +133,17 @@ static struct map_desc ap_io_desc[] __initdata = {
.length = SZ_4K,
.type = MT_DEVICE
}, {
- .virtual= PCI_MEMORY_VADDR,
+ .virtual= (unsigned long)PCI_MEMORY_VADDR,
.pfn= __phys_to_pfn(PHYS_PCI_MEM_BASE),
.length = SZ_16M,
.type = MT_DEVICE
}, {
- .virtual= PCI_CONFIG_VADDR,
+ .virtual= (unsigned long)PCI_CONFIG_VADDR,
.pfn= __phys_to_pfn(PHYS_PCI_CONFIG_BASE),
.length = SZ_16M,
.type = MT_DEVICE
}, {
- .virtual= PCI_V3_VADDR,
+ .virtual= (unsigned long)PCI_V3_VADDR,
.pfn= __phys_to_pfn(PHYS_PCI_V3_BASE),
.length = SZ_64K,
.type = MT_DEVICE
@@ -317,9 +317,9 @@ static void __init ap_init(void)
/*
* Where is the timer (VA)?
*/
-#define TIMER0_VA_BASE IO_ADDRESS(INTEGRATOR_TIMER0_BASE)
-#define TIMER1_VA_BASE IO_ADDRESS(INTEGRATOR_TIMER1_BASE)
-#define TIMER2_VA_BASE IO_ADDRESS(INTEGRATOR_TIMER2_BASE)
+#define TIMER0_VA_BASE __io_address(INTEGRATOR_TIMER0_BASE)
+#define TIMER1_VA_BASE __io_address(INTEGRATOR_TIMER1_BASE)
+#define TIMER2_VA_BASE __io_address(INTEGRATOR_TIMER2_BASE)
static unsigned long timer_reload;
diff --git a/arch/arm/mach-integrator/integrator_cp.c
b/arch/arm/mach-integrator/integrator_cp.c
index 82d5c83..3df5fc3 100644
--- a/arch/arm/mach-integrator/integrator_cp.c
+++ b/arch/arm/mach-integrator/integrator_cp.c
@@ -59,7 +59,7 @@
#define INTCP_ETH_SIZE 0x10
-#define INTCP_VA_CTRL_BASE IO_ADDRESS(INTEGRATOR_CP_CTL_BASE)
+#define INTCP_VA_CTRL_BASE __io_address(INTEGRATOR_CP_CTL_BASE)
#define INTCP_FLASHPROG0x04
#define CINTEGRATOR_FLASHPROG_FLVPPEN (1 << 0)
#define CINTEGRATOR_FLASHPROG_FLWREN (1 << 1)
@@ -265,8 +265,8 @@ static struct platform_device *intcp_devs[] __initdata = {
*/
static unsigned int mmc_status(struct device *dev)
{
- unsigned int status = readl(IO_ADDRESS(0xca00 + 4));
- writel(8, IO_ADDRESS(INTEGRATOR_CP_CTL_BASE + 8));
+ unsigned int status = readl(__io_address(0xca00 + 4));
+ writel(8, __io_address(INTEGRATOR_CP_CTL_BASE + 8));
return status & 8;
}
diff --git a/arch/arm/mach-integrator/pci_v3.c
b/arch/arm/mach-integrator/pci_v3.c
index b866880..e6145a85 100644
--- a/arch/arm/mach-integrator/pci_v3.c
+++ b/arch/arm/mach-integrator/pci_v3.c
@@ -181,7 +181,7 @@ static DEFINE_RAW_SPINLOCK(v3_lock);
#undef
Re: [RFC] cgroup TODOs
Hello, Vivek. On Fri, Sep 14, 2012 at 10:25:39AM -0400, Vivek Goyal wrote: > On Thu, Sep 13, 2012 at 01:58:27PM -0700, Tejun Heo wrote: > > [..] > > * blkio is the most problematic. It has two sub-controllers - cfq > > and blk-throttle. Both are utterly broken in terms of hierarchy > > support and the former is known to have pretty hairy code base. I > > don't see any other way than just biting the bullet and fixing it. > > I am still little concerned about changing the blkio behavior > unexpectedly. Can we have some kind of mount time flag which retains > the old flat behavior and we warn user that this mode is deprecated > and will soon be removed. Move over to hierarchical mode. Then after > few release we can drop the flag and cleanup any extra code which > supports flat mode in CFQ. This will atleast make transition smooth. I don't know. That essentially is what we're doing with memcg now and it doesn't seem any less messy. Given the already scary complexity, do we really want to support both flat and hierarchy models at the same time? > > memcg can be handled by memcg people and I can handle cgroup_freezer > > and others with help from the authors. The problematic one is > > blkio. If anyone is interested in working on blkio, please be my > > guest. Vivek? Glauber? > > I will try to spend some time on this. Doing changes in blk-throttle > should be relatively easy. Painful part if CFQ. It does so much that > it is not clear whether a particular change will bite us badly or > not. So doing changes becomes hard. There are heuristics, preemptions, > queue selection logic, service tree and bringing it all together > for full hierarchy becomes interesting. > > I think first thing which needs to be done is merge group scheduling > and cfqq scheduling. Because of flat hierarchy currently we use two > scheduling algorithm. Old logic for queue selection and new logic > for group scheduling. If we treat task and group at same level then > we have to merge two and come up with single logic. I think this depends on how we decide to handle tasks vs. groups, right? > [..] > > * Vivek brought up the issue of distributing resources to tasks and > > groups in the same cgroup. I don't know. Need to think more > > about it. > > This one will require some thought. I have heard arguments for both the > models. Treating tasks and groups at same level seem to have one > disadvantange and that is that people can't think of system resources > in terms of %. People often say, give 20% of disk resources to a > particular cgroup. But it is not possible as there are all kernel > threads running in root cgroup and tasks come and go and that means > % share of a group is variable and not fixed. Another problem is that configuration isn't contained in cgroup proper. We need a way to assign weights to individual tasks which can be somehow directly compared against group weights. cpu cooks priority for this and blkcg may be able to cook ioprio but it's nasty and unobvious. Also, let's say we grow network bandwidth controller for whatever reason. What value are we gonna use? > To make it fixed, we will need to make sure that number of entities > fighting for resources are not variable. That means only group fight > for resources at a level and tasks with-in groups. > > Now the question is should kernel enforce it or should it be left to > user space. I think doing it in user space is also messy as different > agents control different part of hiearchy. For example, if somebody says > that give a particular virtual machine a x% of system resource, libvirt > has no way to do that. At max it can ensure x% of parent group but above > that hierarchy is controlled by systemd and libvirtd has no control > over that. > > Only possible way to do this will seem to be that systemd creates libvirt > group at top level with a minimum fixed % of quota and then libvirt can > figure out % share of each virtual machine. But it is hard to do. > > So while % model is more intutive to users, it is hard to implement. So > an easier way is to stick to the model of relative weights/share and > let user specify relative importance of a virtual machine and actual > quota or % will vary dynamically depending on other tasks/components > in the system. Why is it hard to implement? You just need to treat tasks in the current node as another group competing with other cgroups on equal terms. If anything, isn't that simpler than treating scheduling "entities"? Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 23/24] video: da8xx-fb: use __iomem pointers for MMIO
ARM is moving to stricter checks on readl/write functions,
so we need to use the correct types everywhere.
Cc: Florian Tobias Schandinat
Cc: linux-fb...@vger.kernel.org
Signed-off-by: Arnd Bergmann
---
drivers/video/da8xx-fb.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index 7ae9d53..113d43a 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -131,7 +131,7 @@
#define UPPER_MARGIN 32
#define LOWER_MARGIN 32
-static resource_size_t da8xx_fb_reg_base;
+static void __iomem *da8xx_fb_reg_base;
static struct resource *lcdc_regs;
static unsigned int lcd_revision;
static irq_handler_t lcdc_irq_handler;
@@ -951,7 +951,7 @@ static int __devexit fb_remove(struct platform_device *dev)
clk_disable(par->lcdc_clk);
clk_put(par->lcdc_clk);
framebuffer_release(info);
- iounmap((void __iomem *)da8xx_fb_reg_base);
+ iounmap(da8xx_fb_reg_base);
release_mem_region(lcdc_regs->start, resource_size(lcdc_regs));
}
@@ -1171,7 +1171,7 @@ static int __devinit fb_probe(struct platform_device
*device)
if (!lcdc_regs)
return -EBUSY;
- da8xx_fb_reg_base = (resource_size_t)ioremap(lcdc_regs->start, len);
+ da8xx_fb_reg_base = ioremap(lcdc_regs->start, len);
if (!da8xx_fb_reg_base) {
ret = -EBUSY;
goto err_request_mem;
@@ -1392,7 +1392,7 @@ err_clk_put:
clk_put(fb_clk);
err_ioremap:
- iounmap((void __iomem *)da8xx_fb_reg_base);
+ iounmap(da8xx_fb_reg_base);
err_request_mem:
release_mem_region(lcdc_regs->start, len);
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 01/24] ARM: shmobile: use __iomem pointers for MMIO
ARM is moving to stricter checks on readl/write functions,
so we need to use the correct types everywhere.
This patch is a bit ugly for shmobile, which is the only platform
that just uses integer literals all over the place, but I can't
see a better way to do this.
Cc: Magnus Damm
Cc: Kuninori Morimoto
Cc: Simon Horman
Cc: Paul Mundt
Cc: linux...@vger.kernel.org
Signed-off-by: Arnd Bergmann
---
arch/arm/mach-shmobile/board-ap4evb.c | 12 ++--
arch/arm/mach-shmobile/board-armadillo800eva.c |6 +-
arch/arm/mach-shmobile/board-bonito.c |8 +--
arch/arm/mach-shmobile/board-g3evm.c | 12 ++--
arch/arm/mach-shmobile/board-g4evm.c | 30 +-
arch/arm/mach-shmobile/board-kzm9g.c |8 +--
arch/arm/mach-shmobile/board-mackerel.c| 22
arch/arm/mach-shmobile/clock-r8a7740.c | 46
arch/arm/mach-shmobile/clock-sh7367.c | 44 +++
arch/arm/mach-shmobile/clock-sh7372.c | 60 ++--
arch/arm/mach-shmobile/clock-sh7377.c | 50 -
arch/arm/mach-shmobile/clock-sh73a0.c | 70
arch/arm/mach-shmobile/include/mach/gpio.h |6 +-
arch/arm/mach-shmobile/intc-r8a7779.c | 14 ++---
arch/arm/mach-shmobile/intc-sh7372.c | 27 +
arch/arm/mach-shmobile/intc-sh73a0.c | 20 ---
arch/arm/mach-shmobile/pm-rmobile.c|6 +-
arch/arm/mach-shmobile/pm-sh7372.c | 57 +--
arch/arm/mach-shmobile/setup-sh7367.c |2 +-
arch/arm/mach-shmobile/setup-sh7377.c |2 +-
arch/arm/mach-shmobile/setup-sh73a0.c |2 +-
include/linux/serial_sci.h |2 +-
22 files changed, 256 insertions(+), 250 deletions(-)
diff --git a/arch/arm/mach-shmobile/board-ap4evb.c
b/arch/arm/mach-shmobile/board-ap4evb.c
index f172ca8..1089ee5 100644
--- a/arch/arm/mach-shmobile/board-ap4evb.c
+++ b/arch/arm/mach-shmobile/board-ap4evb.c
@@ -432,7 +432,7 @@ static void usb1_host_port_power(int port, int power)
return;
/* set VBOUT/PWEN and EXTLP1 in DVSTCTR */
- __raw_writew(__raw_readw(0xE68B0008) | 0x600, 0xE68B0008);
+ __raw_writew(__raw_readw(IOMEM(0xE68B0008)) | 0x600, IOMEM(0xE68B0008));
}
static struct r8a66597_platdata usb1_host_data = {
@@ -1224,9 +1224,9 @@ static struct i2c_board_info i2c1_devices[] = {
};
-#define GPIO_PORT9CR 0xE6051009
-#define GPIO_PORT10CR 0xE605100A
-#define USCCR1 0xE6058144
+#define GPIO_PORT9CR IOMEM(0xE6051009)
+#define GPIO_PORT10CR IOMEM(0xE605100A)
+#define USCCR1 IOMEM(0xE6058144)
static void __init ap4evb_init(void)
{
u32 srcr4;
@@ -1304,7 +1304,7 @@ static void __init ap4evb_init(void)
gpio_request(GPIO_FN_OVCN2_1,NULL);
/* setup USB phy */
- __raw_writew(0x8a0a, 0xE6058130); /* USBCR4 */
+ __raw_writew(0x8a0a, IOMEM(0xE6058130));/* USBCR4 */
/* enable FSI2 port A (ak4643) */
gpio_request(GPIO_FN_FSIAIBT, NULL);
@@ -1453,7 +1453,7 @@ static void __init ap4evb_init(void)
gpio_request(GPIO_FN_HDMI_CEC, NULL);
/* Reset HDMI, must be held at least one EXTALR (32768Hz) period */
-#define SRCR4 0xe61580bc
+#define SRCR4 IOMEM(0xe61580bc)
srcr4 = __raw_readl(SRCR4);
__raw_writel(srcr4 | (1 << 13), SRCR4);
udelay(50);
diff --git a/arch/arm/mach-shmobile/board-armadillo800eva.c
b/arch/arm/mach-shmobile/board-armadillo800eva.c
index cf10f92..2f32aa6 100644
--- a/arch/arm/mach-shmobile/board-armadillo800eva.c
+++ b/arch/arm/mach-shmobile/board-armadillo800eva.c
@@ -135,7 +135,7 @@
* usbhsf_power_ctrl()
*/
#define IRQ7 evt2irq(0x02e0)
-#define USBCR1 0xe605810a
+#define USBCR1 IOMEM(0xe605810a)
#define USBH 0xC670
#define USBH_USBCTR0x10834
@@ -949,8 +949,8 @@ clock_error:
/*
* board init
*/
-#define GPIO_PORT7CR 0xe6050007
-#define GPIO_PORT8CR 0xe6050008
+#define GPIO_PORT7CR IOMEM(0xe6050007)
+#define GPIO_PORT8CR IOMEM(0xe6050008)
static void __init eva_init(void)
{
struct platform_device *usb = NULL;
diff --git a/arch/arm/mach-shmobile/board-bonito.c
b/arch/arm/mach-shmobile/board-bonito.c
index 4129008..cb8c994 100644
--- a/arch/arm/mach-shmobile/board-bonito.c
+++ b/arch/arm/mach-shmobile/board-bonito.c
@@ -108,12 +108,12 @@ static struct regulator_consumer_supply dummy_supplies[]
= {
#define FPGA_ETH_IRQ (FPGA_IRQ0 + 15)
static u16 bonito_fpga_read(u32 offset)
{
- return __raw_readw(0xf0003000 + offset);
+ return __raw_readw(IOMEM(0xf0003000) + offset);
}
static void bonito_fpga_write(u32 offset, u16 val)
{
- __raw_writew(val, 0xf0003000 + offset);
+ __raw_writew(val, IOMEM(0xf0003000) + offset);
}
static void bonito_fpga_irq_disable(struct
[PATCH 24/24] net: seeq: use __iomem pointers for MMIO
ARM is moving to stricter checks on readl/write functions,
so we need to use the correct types everywhere.
Cc: net...@vger.kernel.org
Cc: "David S. Miller"
Signed-off-by: Arnd Bergmann
---
drivers/net/ethernet/seeq/ether3.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/seeq/ether3.c
b/drivers/net/ethernet/seeq/ether3.c
index df808ac..6a40dd0 100644
--- a/drivers/net/ethernet/seeq/ether3.c
+++ b/drivers/net/ethernet/seeq/ether3.c
@@ -99,13 +99,13 @@ typedef enum {
* The SEEQ8005 doesn't like us writing to its registers
* too quickly.
*/
-static inline void ether3_outb(int v, const void __iomem *r)
+static inline void ether3_outb(int v, void __iomem *r)
{
writeb(v, r);
udelay(1);
}
-static inline void ether3_outw(int v, const void __iomem *r)
+static inline void ether3_outw(int v, void __iomem *r)
{
writew(v, r);
udelay(1);
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
