[PATCH RESEND 1/1] arch Kconfig: remove references to IRQ_PER_CPU
The IRQ_PER_CPU Kconfig symbol was removed in the following commit: Commit 6a58fb3bad099076f36f0f30f44507bc3275cdb6 (genirq: Remove CONFIG_IRQ_PER_CPU) merged in v2.6.39-rc1. But IRQ_PER_CPU wasn't removed from any of the architecture Kconfig files where it was defined or selected. It's completely unused so remove the remaining references. Signed-off-by: James Hogan james.ho...@imgtec.com Cc: Thomas Gleixner t...@linutronix.de Cc: Mike Frysinger vap...@gentoo.org Cc: Fenghua Yu fenghua...@intel.com Cc: Ralf Baechle r...@linux-mips.org Cc: James E.J. Bottomley j...@parisc-linux.org Cc: Helge Deller del...@gmx.de Cc: Benjamin Herrenschmidt b...@kernel.crashing.org Cc: Paul Mackerras pau...@samba.org Cc: Paul Mundt let...@linux-sh.org Acked-by: Tony Luck tony.l...@intel.com Acked-by: Richard Kuo r...@codeaurora.org --- Does anybody want to pick this patch up? arch/blackfin/Kconfig |1 - arch/hexagon/Kconfig |1 - arch/ia64/Kconfig |1 - arch/mips/Kconfig |1 - arch/parisc/Kconfig |1 - arch/powerpc/Kconfig |1 - arch/sh/Kconfig |3 --- 7 files changed, 0 insertions(+), 9 deletions(-) diff --git a/arch/blackfin/Kconfig b/arch/blackfin/Kconfig index b6f3ad5..c709715 100644 --- a/arch/blackfin/Kconfig +++ b/arch/blackfin/Kconfig @@ -38,7 +38,6 @@ config BLACKFIN select HAVE_GENERIC_HARDIRQS select GENERIC_ATOMIC64 select GENERIC_IRQ_PROBE - select IRQ_PER_CPU if SMP select USE_GENERIC_SMP_HELPERS if SMP select HAVE_NMI_WATCHDOG if NMI_WATCHDOG select GENERIC_SMP_IDLE_THREAD diff --git a/arch/hexagon/Kconfig b/arch/hexagon/Kconfig index 0744f7d..800dd9c 100644 --- a/arch/hexagon/Kconfig +++ b/arch/hexagon/Kconfig @@ -12,7 +12,6 @@ config HEXAGON # select ARCH_WANT_OPTIONAL_GPIOLIB # select ARCH_REQUIRE_GPIOLIB # select HAVE_CLK - # select IRQ_PER_CPU # select GENERIC_PENDING_IRQ if SMP select HAVE_IRQ_WORK select GENERIC_ATOMIC64 diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig index 3279646..00c2e88 100644 --- a/arch/ia64/Kconfig +++ b/arch/ia64/Kconfig @@ -29,7 +29,6 @@ config IA64 select ARCH_DISCARD_MEMBLOCK select GENERIC_IRQ_PROBE select GENERIC_PENDING_IRQ if SMP - select IRQ_PER_CPU select GENERIC_IRQ_SHOW select ARCH_WANT_OPTIONAL_GPIOLIB select ARCH_HAVE_NMI_SAFE_CMPXCHG diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index 2ac626a..451c2e7 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -2161,7 +2161,6 @@ source mm/Kconfig config SMP bool Multi-Processing support depends on SYS_SUPPORTS_SMP - select IRQ_PER_CPU select USE_GENERIC_SMP_HELPERS help This enables support for systems with more than one CPU. If you have diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig index b77feff..8525be4 100644 --- a/arch/parisc/Kconfig +++ b/arch/parisc/Kconfig @@ -16,7 +16,6 @@ config PARISC select BROKEN_RODATA select GENERIC_IRQ_PROBE select GENERIC_PCI_IOMAP - select IRQ_PER_CPU select ARCH_HAVE_NMI_SAFE_CMPXCHG select GENERIC_SMP_IDLE_THREAD select GENERIC_STRNCPY_FROM_USER diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 17903f1..f3d7090a 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -125,7 +125,6 @@ config PPC select HAVE_GENERIC_HARDIRQS select ARCH_WANT_IPC_PARSE_VERSION select SPARSE_IRQ - select IRQ_PER_CPU select IRQ_DOMAIN select GENERIC_IRQ_SHOW select GENERIC_IRQ_SHOW_LEVEL diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig index babc2b8..6f799ec 100644 --- a/arch/sh/Kconfig +++ b/arch/sh/Kconfig @@ -91,9 +91,6 @@ config GENERIC_CSUM config GENERIC_HWEIGHT def_bool y -config IRQ_PER_CPU - def_bool y - config GENERIC_GPIO def_bool n -- 1.7.7.6 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2] powerpc/512x: add function for chip select parameter configuration
Add ability to configure chip select (CS) parameters for devices
that need different CS parameters setup after their configuration.
I.e. an FPGA device on LP bus can require different CS parameters
for its bus interface after loading firmware into it. A driver
can easily reconfigure the LPC CS parameters using this function.
Signed-off-by: Anatolij Gustschin ag...@denx.de
---
v2:
- define CS in commit log
- use unsigned int type for cs argument to simplify
valid CS range check
- use EXPORT_SYMBOL
arch/powerpc/include/asm/mpc5121.h | 16 +
arch/powerpc/platforms/512x/mpc512x_shared.c | 30 ++
2 files changed, 46 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/mpc5121.h
b/arch/powerpc/include/asm/mpc5121.h
index 8c0ab2c..8ae133e 100644
--- a/arch/powerpc/include/asm/mpc5121.h
+++ b/arch/powerpc/include/asm/mpc5121.h
@@ -53,4 +53,20 @@ struct mpc512x_ccm {
u32 m4ccr; /* MSCAN4 CCR */
u8 res[0x98]; /* Reserved */
};
+
+/*
+ * LPC Module
+ */
+struct mpc512x_lpc {
+ u32 cs_cfg[8]; /* CS config */
+ u32 cs_ctrl;/* CS Control Register */
+ u32 cs_status; /* CS Status Register */
+ u32 burst_ctrl; /* CS Burst Control Register */
+ u32 deadcycle_ctrl; /* CS Deadcycle Control Register */
+ u32 holdcycle_ctrl; /* CS Holdcycle Control Register */
+ u32 alt;/* Address Latch Timing Register */
+};
+
+int mpc512x_cs_config(unsigned int cs, u32 val);
+
#endif /* __ASM_POWERPC_MPC5121_H__ */
diff --git a/arch/powerpc/platforms/512x/mpc512x_shared.c
b/arch/powerpc/platforms/512x/mpc512x_shared.c
index 39d5630..8e2bde9 100644
--- a/arch/powerpc/platforms/512x/mpc512x_shared.c
+++ b/arch/powerpc/platforms/512x/mpc512x_shared.c
@@ -456,3 +456,33 @@ void __init mpc512x_init(void)
mpc512x_restart_init();
mpc512x_psc_fifo_init();
}
+
+/**
+ * mpc512x_cs_config - Setup chip select configuration
+ * @cs: chip select number
+ * @val: chip select configuration value
+ *
+ * Perform chip select configuration for devices on LocalPlus Bus.
+ * Intended to dynamically reconfigure the chip select parameters
+ * for configurable devices on the bus.
+ */
+int mpc512x_cs_config(unsigned int cs, u32 val)
+{
+ static struct mpc512x_lpc __iomem *lpc;
+ struct device_node *np;
+
+ if (cs 7)
+ return -EINVAL;
+
+ if (!lpc) {
+ np = of_find_compatible_node(NULL, NULL, fsl,mpc5121-lpc);
+ lpc = of_iomap(np, 0);
+ of_node_put(np);
+ if (!lpc)
+ return -ENOMEM;
+ }
+
+ out_be32(lpc-cs_cfg[cs], val);
+ return 0;
+}
+EXPORT_SYMBOL(mpc512x_cs_config);
--
1.7.5.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH RESEND 1/1] arch Kconfig: remove references to IRQ_PER_CPU
On Mon, Feb 04, 2013 at 10:09:43AM +, James Hogan wrote: The IRQ_PER_CPU Kconfig symbol was removed in the following commit: Commit 6a58fb3bad099076f36f0f30f44507bc3275cdb6 (genirq: Remove CONFIG_IRQ_PER_CPU) merged in v2.6.39-rc1. But IRQ_PER_CPU wasn't removed from any of the architecture Kconfig files where it was defined or selected. It's completely unused so remove the remaining references. Signed-off-by: James Hogan james.ho...@imgtec.com Cc: Thomas Gleixner t...@linutronix.de Cc: Mike Frysinger vap...@gentoo.org Cc: Fenghua Yu fenghua...@intel.com Cc: Ralf Baechle r...@linux-mips.org Cc: James E.J. Bottomley j...@parisc-linux.org Cc: Helge Deller del...@gmx.de Cc: Benjamin Herrenschmidt b...@kernel.crashing.org Cc: Paul Mackerras pau...@samba.org Cc: Paul Mundt let...@linux-sh.org Acked-by: Tony Luck tony.l...@intel.com Acked-by: Richard Kuo r...@codeaurora.org Acked-by: Paul Mundt let...@linux-sh.org ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH?] Move ACPI device nodes under /sys/firmware/acpi (was: Re: [RFC PATCH v2 01/12] Add sys_hotplug.h for system device hotplug framework)
On Sunday, February 03, 2013 07:24:47 PM Greg KH wrote: On Sat, Feb 02, 2013 at 11:18:20PM +0100, Rafael J. Wysocki wrote: On Saturday, February 02, 2013 09:15:37 PM Rafael J. Wysocki wrote: On Saturday, February 02, 2013 03:58:01 PM Greg KH wrote: [...] I know it's more complicated with these types of devices, and I think we are getting closer to the correct solution, I just don't want to ever see duplicate devices in the driver model for the same physical device. Do you mean two things based on struct device for the same hardware component? That's been happening already pretty much forever for every PCI device known to the ACPI layer, for PNP and many others. However, those ACPI things are (or rather should be, but we're going to clean that up) only for convenience (to be able to see the namespace structure and related things in sysfs). So the stuff under /sys/devices/LNXSYSTM\:00/ is not real. In my view it shouldn't even be under /sys/devices/ (/sys/firmware/acpi/ seems to be a better place for it), but that may be difficult to change without breaking user space (maybe we can just symlink it from /sys/devices/ or something). And the ACPI bus type shouldn't even exist in my opinion. Well, well. In fact, the appended patch moves the whole ACPI device nodes tree under /sys/firmware/acpi/ and I'm not seeing any negative consequences of that on my test box (events work and so on). User space is quite new on it, though, and the patch is hackish. Try booting a RHEL 5 image on this type of kernel, or some old Fedora releases, they were sensitive to changes in sysfs. Well, I've found a machine where it causes problems to happen. I'll try to add a symlink from /sys/devices to that and see what happens then. Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH v2 01/12] Add sys_hotplug.h for system device hotplug framework
On Sun, Feb 03, 2013 at 05:28:09PM -0700, Toshi Kani wrote: On Sat, 2013-02-02 at 16:01 +0100, Greg KH wrote: On Fri, Feb 01, 2013 at 01:40:10PM -0700, Toshi Kani wrote: On Fri, 2013-02-01 at 07:30 +, Greg KH wrote: On Thu, Jan 31, 2013 at 06:32:18PM -0700, Toshi Kani wrote: This is already done for PCI host bridges and platform devices and I don't see why we can't do that for the other types of devices too. The only missing piece I see is a way to handle the eject problem, i.e. when we try do eject a device at the top of a subtree and need to tear down the entire subtree below it, but if that's going to lead to a system crash, for example, we want to cancel the eject. It seems to me that we'll need some help from the driver core here. There are three different approaches suggested for system device hot-plug: A. Proceed within system device bus scan. B. Proceed within ACPI bus scan. C. Proceed with a sequence (as a mini-boot). Option A uses system devices as tokens, option B uses acpi devices as tokens, and option C uses resource tables as tokens, for their handlers. Here is summary of key questions answers so far. I hope this clarifies why I am suggesting option 3. 1. What are the system devices? System devices provide system-wide core computing resources, which are essential to compose a computer system. System devices are not connected to any particular standard buses. Not a problem, lots of devices are not connected to any particular standard busses. All this means is that system devices are connected to the system bus, nothing more. Can you give me a few examples of other devices that support hotplug and are not connected to any particular buses? I will investigate them to see how they are managed to support hotplug. Any device that is attached to any bus in the driver model can be hotunplugged from userspace by telling it to be unbound from the driver controlling it. Try it for any platform device in your system to see how it happens. The unbind operation, as I understand from you, is to detach a driver from a device. Yes, unbinding can be done for any devices. It is however different from hot-plug operation, which unplugs a device. Physically, yes, but to the driver involved, and the driver core, there is no difference. That was one of the primary goals of the driver core creation so many years ago. Today, the unbind operation to an ACPI cpu/memory devices causes hot-unplug (offline) operation to them, which is one of the major issues for us since unbind cannot fail. This patchset addresses this issue by making the unbind operation of ACPI cpu/memory devices to do the unbinding only. ACPI drivers no longer control cpu and memory as they are supposed to be controlled by their drivers, cpu and memory modules. I think that's the problem right there, solve that, please. 2. Why are the system devices special? The system devices are initialized during early boot-time, by multiple subsystems, from the boot-up sequence, in pre-defined order. They provide low-level services to enable other subsystems to come up. Sorry, no, that doesn't mean they are special, nothing here is unique for the point of view of the driver model from any other device or bus. I think system devices are unique in a sense that they are initialized before drivers run. No, most all devices are initialized before a driver runs on it, USB is one such example, PCI another, and I'm pretty sure that there are others. USB devices can be initialized after the USB bus driver is initialized. Similarly, PCI devices can be initialized after the PCI bus driver is initialized. However, CPU and memory are initialized without any dependency to their bus driver since there is no such thing. You can create such a thing if you want :) In addition, CPU and memory have two drivers -- their actual drivers/subsystems and their ACPI drivers. Again, I feel that is the root of the problem. Rafael seems to be working on solving this, which I think is essencial to your work as well. thanks, greg k-h ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH v2 01/12] Add sys_hotplug.h for system device hotplug framework
On Sun, Feb 03, 2013 at 09:44:39PM +0100, Rafael J. Wysocki wrote: Yes, but those are just remove events and we can only see how destructive they were after the removal. The point is to be able to figure out whether or not we *want* to do the removal in the first place. Say you have a computing node which signals a hardware problem in a processor package (the container with CPU cores, memory, PCI host bridge etc.). You may want to eject that package, but you don't want to kill the system this way. So if the eject is doable, it is very much desirable to do it, but if it is not doable, you'd rather shut the box down and do the replacement afterward. That may be costly, however (maybe weeks of computations), so it should be avoided if possible, but not at the expense of crashing the box if the eject doesn't work out. It seems to me that we could handle that with the help of a new flag, say no_eject, in struct device, a global mutex, and a function that will walk the given subtree of the device hierarchy and check if no_eject is set for any devices in there. Plus a global no_eject switch, perhaps. I think this will always be racy, or at worst, slow things down on normal device operations as you will always be having to grab this flag whenever you want to do something new. See my comments earlier about pci hotplug and the design decisions there about no eject capabilities for why. thanks, greg k-h ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 3.8: possible circular locking dependency detected
On Sun, 2013-02-03 at 21:09 -0800, Christian Kujau wrote:
Hi,
similar to what I reported earlier [0] for 3.8.0-rc1, this happens during
ifup wlan0 (which in effect starts wpa_supplicant to bring up a Broadcom
b43 wifi network interface). The interface is working though and continues
to work over several ifup/ifdown iterations.
The backtrace looks awfully similar to the earlier[0] report, but this
time it had b43* stuff in it so I thought I should report it. Full dmesg
and .config here: http://nerdbynature.de/bits/3.8.0-rc6/
[0] https://lkml.org/lkml/2013/1/3/543
Actually the backtrace looks very different, that was fb vs
console_lock.
This one should probably go to linux-wirel...@vger.kernel.org (CC-ed).
IIUI it's actually the work handling that is the problem. In
b43_wireless_core_stop() it calls cancel_work_sync() with the RTNL held,
but the work function (b43_request_firmware()) also takes the RTNL via
ieee80211_register_hw() and wiphy_register(). eg:
[ 807.767412]CPU0CPU1
[ 807.768561]
[ 807.769690] lock(rtnl_mutex);
[ 807.770822]process_one_work(...,
wl-firmware_load);
[ 807.771970]lock(rtnl_mutex);
[ 807.773115] cancel_work_sync(wl-firmware_load);
cheers
[ 807.693791]
[ 807.695519] ==
[ 807.697198] [ INFO: possible circular locking dependency detected ]
[ 807.698890] 3.8.0-rc6-8-g8b31849 #1 Not tainted
[ 807.700573] ---
[ 807.702255] wpa_supplicant/4129 is trying to acquire lock:
[ 807.703925] ((wl-firmware_load)){+.+.+.}, at: [c0049d1c]
flush_work+0x0/0x2b0
[ 807.705696]
[ 807.705696] but task is already holding lock:
[ 807.709023] (rtnl_mutex){+.+.+.}, at: [c04362d4] rtnl_lock+0x1c/0x2c
[ 807.710743]
[ 807.710743] which lock already depends on the new lock.
[ 807.710743]
[ 807.715541]
[ 807.715541] the existing dependency chain (in reverse order) is:
[ 807.718691]
[ 807.718691] - #1 (rtnl_mutex){+.+.+.}:
[ 807.721903][c04f69ac] mutex_lock_nested+0x6c/0x2bc
[ 807.723533][c04362d4] rtnl_lock+0x1c/0x2c
[ 807.725138][f20be0d8] wiphy_register+0x510/0x53c [cfg80211]
[ 807.726798][f64815ec] ieee80211_register_hw+0x3f8/0x82c
[mac80211]
[ 807.728431][f64c6890] b43_request_firmware+0x8c/0x198 [b43]
[ 807.730025][c004b1f4] process_one_work+0x1a4/0x498
[ 807.731549][c004b8b4] worker_thread+0x17c/0x428
[ 807.733025][c0051280] kthread+0xa8/0xac
[ 807.734439][c0010990] ret_from_kernel_thread+0x64/0x6c
[ 807.735810]
[ 807.735810] - #0 ((wl-firmware_load)){+.+.+.}:
[ 807.738389][c0071b38] lock_acquire+0x50/0x6c
[ 807.739694][c0049d58] flush_work+0x3c/0x2b0
[ 807.740980][c004c30c] __cancel_work_timer+0x94/0xec
[ 807.742271][f64c748c] b43_wireless_core_stop+0x5c/0x234 [b43]
[ 807.743574][f64c76b0] b43_op_stop+0x4c/0x88 [b43]
[ 807.744888][f64a4c08] ieee80211_stop_device+0x4c/0x8c [mac80211]
[ 807.746240][f64913a8] ieee80211_do_stop+0x2c0/0x5dc [mac80211]
[ 807.747582][f64916dc] ieee80211_stop+0x18/0x2c [mac80211]
[ 807.748925][c0423d94] __dev_close_many+0xb0/0x100
[ 807.750257][c0423e10] __dev_close+0x2c/0x4c
[ 807.751560][c0427514] __dev_change_flags+0x124/0x178
[ 807.752868][c042761c] dev_change_flags+0x1c/0x64
[ 807.754177][c047db9c] devinet_ioctl+0x69c/0x74c
[ 807.755459][c047ecf8] inet_ioctl+0xcc/0xf8
[ 807.756709][c040eab0] sock_ioctl+0x70/0x2e8
[ 807.757948][c00d9f70] do_vfs_ioctl+0xa4/0x7c0
[ 807.759182][c00da6d0] sys_ioctl+0x44/0x70
[ 807.760407][c001084c] ret_from_syscall+0x0/0x38
[ 807.761622]
[ 807.761622] other info that might help us debug this:
[ 807.761622]
[ 807.765107] Possible unsafe locking scenario:
[ 807.765107]
[ 807.767412]CPU0CPU1
[ 807.768561]
[ 807.769690] lock(rtnl_mutex);
[ 807.770822]lock((wl-firmware_load));
[ 807.771970]lock(rtnl_mutex);
[ 807.773115] lock((wl-firmware_load));
[ 807.774244]
[ 807.774244] *** DEADLOCK ***
[ 807.774244]
[ 807.777405] 1 lock held by wpa_supplicant/4129:
[ 807.778475] #0: (rtnl_mutex){+.+.+.}, at: [c04362d4]
rtnl_lock+0x1c/0x2c
[ 807.779628]
[ 807.779628] stack backtrace:
[ 807.781720] Call Trace:
[ 807.782765] [eea2db20] [c0009160] show_stack+0x48/0x15c (unreliable)
[ 807.784087] [eea2db60] [c04fae24] print_circular_bug+0x2b0/0x2c8
[ 807.785169] [eea2db90] [c0071300] __lock_acquire+0x14f4/0x18c8
[ 807.786254] [eea2dc30] [c0071b38] lock_acquire+0x50/0x6c
[ 807.787335] [eea2dc50]
Re: [RFC PATCH v2 01/12] Add sys_hotplug.h for system device hotplug framework
On Sunday, February 03, 2013 07:23:49 PM Greg KH wrote: On Sat, Feb 02, 2013 at 09:15:37PM +0100, Rafael J. Wysocki wrote: On Saturday, February 02, 2013 03:58:01 PM Greg KH wrote: On Fri, Feb 01, 2013 at 11:12:59PM +0100, Rafael J. Wysocki wrote: On Friday, February 01, 2013 08:23:12 AM Greg KH wrote: On Thu, Jan 31, 2013 at 09:54:51PM +0100, Rafael J. Wysocki wrote: But, again, I'm going to ask why you aren't using the existing cpu / memory / bridge / node devices that we have in the kernel. Please use them, or give me a _really_ good reason why they will not work. We cannot use the existing system devices or ACPI devices here. During hot-plug, ACPI handler sets this shp_device info, so that cpu and memory handlers (drivers/cpu.c and mm/memory_hotplug.c) can obtain their target device information in a platform-neutral way. During hot-add, we first creates an ACPI device node (i.e. device under /sys/bus/acpi/devices), but platform-neutral modules cannot use them as they are ACPI-specific. But suppose we're smart and have ACPI scan handlers that will create physical device nodes for those devices during the ACPI namespace scan. Then, the platform-neutral nodes will be able to bind to those physical nodes. Moreover, it should be possible to get a hierarchy of device objects this way that will reflect all of the dependencies we need to take into account during hot-add and hot-remove operations. That may not be what we have today, but I don't see any *fundamental* obstacles preventing us from using this approach. I would _much_ rather see that be the solution here as I think it is the proper one. This is already done for PCI host bridges and platform devices and I don't see why we can't do that for the other types of devices too. I agree. The only missing piece I see is a way to handle the eject problem, i.e. when we try do eject a device at the top of a subtree and need to tear down the entire subtree below it, but if that's going to lead to a system crash, for example, we want to cancel the eject. It seems to me that we'll need some help from the driver core here. I say do what we always have done here, if the user asked us to tear something down, let it happen as they are the ones that know best :) Seriously, I guess this gets back to the fail disconnect idea that the ACPI developers keep harping on. I thought we already resolved this properly by having them implement it in their bus code, no reason the same thing couldn't happen here, right? Not really. :-) We haven't ever resolved that particular issue I'm afraid. Ah, I didn't realize that. I don't think the core needs to do anything special, but if so, I'll be glad to review it. OK, so this is the use case. We have eject defined for something like a container with a number of CPU cores, PCI host bridge, and a memory controller under it. And a few pretty much arbitrary I/O devices as a bonus. Now, there's a button on the system case labeled as Eject and if that button is pressed, we're supposed to _try_ to eject all of those things at once. We are allowed to fail that request, though, if that's problematic for some reason, but we're supposed to let the BIOS know about that. Do you seriously think that if that button is pressed, we should just proceed with removing all that stuff no matter what? That'd be kind of like Russian roulette for whoever pressed that button, because s/he could only press it and wait for the system to either crash or not. Or maybe to crash a bit later because of some delayed stuff that would hit one of those devices that had just gone. Surely not a situation any admin of a high-availability system would like to be in. :-) Quite frankly, I have no idea how that can be addressed in a single bus type, let alone ACPI (which is not even a proper bus type, just something pretending to be one). You don't have it as a single bus type, you have a controller somewhere, off of the bus being destroyed, that handles sending remove events to the device and tearing everything down. PCI does this from the very beginning. Yes, but those are just remove events and we can only see how destructive they were after the removal. The point is to be able to figure out whether or not we *want* to do the removal in the first place. Yes, but, you will always race if you try to test to see if you can shut down a
Re: [RFC PATCH v2 01/12] Add sys_hotplug.h for system device hotplug framework
On Monday, February 04, 2013 04:48:10 AM Greg KH wrote: On Sun, Feb 03, 2013 at 09:44:39PM +0100, Rafael J. Wysocki wrote: Yes, but those are just remove events and we can only see how destructive they were after the removal. The point is to be able to figure out whether or not we *want* to do the removal in the first place. Say you have a computing node which signals a hardware problem in a processor package (the container with CPU cores, memory, PCI host bridge etc.). You may want to eject that package, but you don't want to kill the system this way. So if the eject is doable, it is very much desirable to do it, but if it is not doable, you'd rather shut the box down and do the replacement afterward. That may be costly, however (maybe weeks of computations), so it should be avoided if possible, but not at the expense of crashing the box if the eject doesn't work out. It seems to me that we could handle that with the help of a new flag, say no_eject, in struct device, a global mutex, and a function that will walk the given subtree of the device hierarchy and check if no_eject is set for any devices in there. Plus a global no_eject switch, perhaps. I think this will always be racy, or at worst, slow things down on normal device operations as you will always be having to grab this flag whenever you want to do something new. I don't see why this particular scheme should be racy, at least I don't see any obvious races in it (although I'm not that good at races detection in general, admittedly). Also, I don't expect that flag to be used for everything, just for things known to seriously break if forcible eject is done. That may be not precise enough, so that's a matter of defining its purpose more precisely. We can do something like that on the ACPI level (ie. introduce a no_eject flag in struct acpi_device and provide an iterface for the layers above ACPI to manipulate it) but then devices without ACPI namespace objects won't be covered. That may not be a big deal, though. So say dev is about to be used for something incompatible with ejecting, so to speak. Then, one would do platform_lock_eject(dev), which would check if dev has an ACPI handle and then take acpi_eject_lock (if so). The return value of platform_lock_eject(dev) would need to be checked to see if the device is not gone. If it returns success (0), one would do something to the device and call platform_no_eject(dev) and then platform_unlock_eject(dev). To clear no_eject one would just call platform_allow_to_eject(dev) that would do all of the locking and clearing in one operation. The ACPI eject side would be similar to the thing I described previously, so it would (1) take acpi_eject_lock, (2) see if any struct acpi_device involved has no_eject set and if not, then (3) do acpi_bus_trim(), (4) carry out the eject and (5) release acpi_eject_lock. Step (2) above might be optional, ie. if eject is forcible, we would just do (3) etc. without (2). The locking should prevent races from happening (and it should prevent two ejects from happening at the same time too, which is not a bad thing by itself). See my comments earlier about pci hotplug and the design decisions there about no eject capabilities for why. Well, I replied to that one too. :-) Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH v2 01/12] Add sys_hotplug.h for system device hotplug framework
On Mon, Feb 04, 2013 at 03:21:22PM +0100, Rafael J. Wysocki wrote: On Monday, February 04, 2013 04:48:10 AM Greg KH wrote: On Sun, Feb 03, 2013 at 09:44:39PM +0100, Rafael J. Wysocki wrote: Yes, but those are just remove events and we can only see how destructive they were after the removal. The point is to be able to figure out whether or not we *want* to do the removal in the first place. Say you have a computing node which signals a hardware problem in a processor package (the container with CPU cores, memory, PCI host bridge etc.). You may want to eject that package, but you don't want to kill the system this way. So if the eject is doable, it is very much desirable to do it, but if it is not doable, you'd rather shut the box down and do the replacement afterward. That may be costly, however (maybe weeks of computations), so it should be avoided if possible, but not at the expense of crashing the box if the eject doesn't work out. It seems to me that we could handle that with the help of a new flag, say no_eject, in struct device, a global mutex, and a function that will walk the given subtree of the device hierarchy and check if no_eject is set for any devices in there. Plus a global no_eject switch, perhaps. I think this will always be racy, or at worst, slow things down on normal device operations as you will always be having to grab this flag whenever you want to do something new. I don't see why this particular scheme should be racy, at least I don't see any obvious races in it (although I'm not that good at races detection in general, admittedly). Also, I don't expect that flag to be used for everything, just for things known to seriously break if forcible eject is done. That may be not precise enough, so that's a matter of defining its purpose more precisely. We can do something like that on the ACPI level (ie. introduce a no_eject flag in struct acpi_device and provide an iterface for the layers above ACPI to manipulate it) but then devices without ACPI namespace objects won't be covered. That may not be a big deal, though. So say dev is about to be used for something incompatible with ejecting, so to speak. Then, one would do platform_lock_eject(dev), which would check if dev has an ACPI handle and then take acpi_eject_lock (if so). The return value of platform_lock_eject(dev) would need to be checked to see if the device is not gone. If it returns success (0), one would do something to the device and call platform_no_eject(dev) and then platform_unlock_eject(dev). How does a device know it is doing something that is incompatible with ejecting? That's a non-trivial task from what I can tell. What happens if a device wants to set that flag, right after it was told to eject and the device was in the middle of being removed? How can you fail the I can't be removed me now, so don't requirement that it now has? thanks, greg k-h ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 1/1] powerpc/85xx: Board support for ppa8548
On 02/03/2013 01:39 PM, Stef van Os wrote:
+ pci0: pci@fe0008000 {
+ status = disabled;
+ };
+
+ pci1: pci@fe0009000 {
+ status = disabled;
+ };
+
+ pci2: pcie@fe000a000 {
+ status = disabled;
+ };
I was hoping you'd follow my example and include a comment indicating
why the PCI devices are all disabled.
+static void ppa8548_show_cpuinfo(struct seq_file *m)
+{
+ uint svid, phid1;
Please don't used unsized integers for hardware registers.
uint32_t svid, phid1;
--
Timur Tabi
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH v2 01/12] Add sys_hotplug.h for system device hotplug framework
On Mon, 2013-02-04 at 14:41 +0100, Rafael J. Wysocki wrote: On Sunday, February 03, 2013 07:23:49 PM Greg KH wrote: On Sat, Feb 02, 2013 at 09:15:37PM +0100, Rafael J. Wysocki wrote: On Saturday, February 02, 2013 03:58:01 PM Greg KH wrote: : Yes, but those are just remove events and we can only see how destructive they were after the removal. The point is to be able to figure out whether or not we *want* to do the removal in the first place. Yes, but, you will always race if you try to test to see if you can shut down a device and then trying to do it. So walking the bus ahead of time isn't a good idea. And, we really don't have a viable way to recover if disconnect() fails, do we. What do we do in that situation, restore the other devices we disconnected successfully? How do we remember/know what they were? PCI hotplug almost had this same problem until the designers finally realized that they just had to accept the fact that removing a PCI device could either happen by: - a user yanking out the device, at which time the OS better clean up properly no matter what happens - the user asked nicely to remove a device, and the OS can take as long as it wants to complete that action, including stalling for noticable amounts of time before eventually, always letting the action succeed. I think the second thing is what you have to do here. If a user tells the OS it wants to remove these devices, you better do it. If you can't, because memory is being used by someone else, either move them off, or just hope that nothing bad happens, before the user gets frustrated and yanks out the CPU/memory module themselves physically :) Well, that we can't help, but sometimes users really *want* the OS to tell them if it is safe to unplug something at this particualr time (think about the Windows' safe remove feature for USB sticks, for example; that came out of users' demand AFAIR). So in my opinion it would be good to give them an option to do safe eject or forcible eject, whichever they prefer. For system device hot-plug, it always needs to be safe eject. This feature will be implemented on mission critical servers, which are managed by professional IT folks. Crashing a server causes serious money to the business. A user yanking out a system device won't happen, and it immediately crashes the system if it is done. So, we have nothing to do with this case. The 2nd case can hang the operation, waiting forever to proceed, which is still a serious issue for enterprise customers. Say you have a computing node which signals a hardware problem in a processor package (the container with CPU cores, memory, PCI host bridge etc.). You may want to eject that package, but you don't want to kill the system this way. So if the eject is doable, it is very much desirable to do it, but if it is not doable, you'd rather shut the box down and do the replacement afterward. That may be costly, however (maybe weeks of computations), so it should be avoided if possible, but not at the expense of crashing the box if the eject doesn't work out. These same situations came up for PCI hotplug, and I still say the same resolution there holds true, as described above. The user wants to remove something, so let them do it. They always know best, and get mad at us if we think otherwise :) Well, not necessarily. Users sometimes really don't know what they are doing and want us to give them a hint. My opinion is that if we can give them a hint, there's no reason not to. What does the ACPI spec say about this type of thing? Surely the same people that did the PCI Hotplug spec were consulted when doing this part of the spec, right? Yeah, I know, I can dream... It's not very specific (as usual), but it gives hints. :-) For example, there is the _OST method (Section 6.3.5 of ACPI 5) that we are supposed to use to notify the platform of ejection failures and there are status codes like 0x81: Device in use by application or 0x82: Device busy that can be used in there. So definitely the authors took ejection failures for software-related reasons into consideration. That is correct. Also, ACPI spec deliberately does not define implementation details, so we defined DIG64 hotplug spec below (which I contributed to the spec.) http://www.dig64.org/home/DIG64_HPPF_R1_0.pdf For example, Figure 2 in page 14 states memory hot-remove flow. The operation needs to either succeed or fail. Crash or hang is not an option. Thanks, -Toshi ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH v2 01/12] Add sys_hotplug.h for system device hotplug framework
On Mon, 2013-02-04 at 15:21 +0100, Rafael J. Wysocki wrote: On Monday, February 04, 2013 04:48:10 AM Greg KH wrote: On Sun, Feb 03, 2013 at 09:44:39PM +0100, Rafael J. Wysocki wrote: Yes, but those are just remove events and we can only see how destructive they were after the removal. The point is to be able to figure out whether or not we *want* to do the removal in the first place. Say you have a computing node which signals a hardware problem in a processor package (the container with CPU cores, memory, PCI host bridge etc.). You may want to eject that package, but you don't want to kill the system this way. So if the eject is doable, it is very much desirable to do it, but if it is not doable, you'd rather shut the box down and do the replacement afterward. That may be costly, however (maybe weeks of computations), so it should be avoided if possible, but not at the expense of crashing the box if the eject doesn't work out. It seems to me that we could handle that with the help of a new flag, say no_eject, in struct device, a global mutex, and a function that will walk the given subtree of the device hierarchy and check if no_eject is set for any devices in there. Plus a global no_eject switch, perhaps. I think this will always be racy, or at worst, slow things down on normal device operations as you will always be having to grab this flag whenever you want to do something new. I don't see why this particular scheme should be racy, at least I don't see any obvious races in it (although I'm not that good at races detection in general, admittedly). Also, I don't expect that flag to be used for everything, just for things known to seriously break if forcible eject is done. That may be not precise enough, so that's a matter of defining its purpose more precisely. We can do something like that on the ACPI level (ie. introduce a no_eject flag in struct acpi_device and provide an iterface for the layers above ACPI to manipulate it) but then devices without ACPI namespace objects won't be covered. That may not be a big deal, though. I am afraid that bringing the device status management into the ACPI level would not a good idea. acpi_device should only reflect ACPI device object information, not how its actual device is being used. I like your initiative of acpi_scan_driver and I think scanning / trimming of ACPI object info is what the ACPI drivers should do. Thanks, -Toshi ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/1] powerpc/85xx: Board support for ppa8548
On 02/01/2013 10:34:44 PM, Timur Tabi wrote:
On Fri, Feb 1, 2013 at 6:31 PM, Scott Wood scottw...@freescale.com
wrote:
I guess the reason you're not using fsl/mpc8548si-post.dtsi is that
you
don't want PCI. Maybe PCI and srio should be moved out of that
file, or
ifdeffed if 85xx ever ends up using the preprocessor for its device
trees.
Wouldn't it be easier to add status=disabled in this dts file? I do
something similar with the LBC on the p1022rdk.
board_lbc: lbc: localbus@ffe05000 {
/* The P1022 RDK does not have any localbus devices */
status = disabled;
};
Yeah, that'd work.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH v2 01/12] Add sys_hotplug.h for system device hotplug framework
On Mon, 2013-02-04 at 04:46 -0800, Greg KH wrote: On Sun, Feb 03, 2013 at 05:28:09PM -0700, Toshi Kani wrote: On Sat, 2013-02-02 at 16:01 +0100, Greg KH wrote: On Fri, Feb 01, 2013 at 01:40:10PM -0700, Toshi Kani wrote: On Fri, 2013-02-01 at 07:30 +, Greg KH wrote: On Thu, Jan 31, 2013 at 06:32:18PM -0700, Toshi Kani wrote: This is already done for PCI host bridges and platform devices and I don't see why we can't do that for the other types of devices too. The only missing piece I see is a way to handle the eject problem, i.e. when we try do eject a device at the top of a subtree and need to tear down the entire subtree below it, but if that's going to lead to a system crash, for example, we want to cancel the eject. It seems to me that we'll need some help from the driver core here. There are three different approaches suggested for system device hot-plug: A. Proceed within system device bus scan. B. Proceed within ACPI bus scan. C. Proceed with a sequence (as a mini-boot). Option A uses system devices as tokens, option B uses acpi devices as tokens, and option C uses resource tables as tokens, for their handlers. Here is summary of key questions answers so far. I hope this clarifies why I am suggesting option 3. 1. What are the system devices? System devices provide system-wide core computing resources, which are essential to compose a computer system. System devices are not connected to any particular standard buses. Not a problem, lots of devices are not connected to any particular standard busses. All this means is that system devices are connected to the system bus, nothing more. Can you give me a few examples of other devices that support hotplug and are not connected to any particular buses? I will investigate them to see how they are managed to support hotplug. Any device that is attached to any bus in the driver model can be hotunplugged from userspace by telling it to be unbound from the driver controlling it. Try it for any platform device in your system to see how it happens. The unbind operation, as I understand from you, is to detach a driver from a device. Yes, unbinding can be done for any devices. It is however different from hot-plug operation, which unplugs a device. Physically, yes, but to the driver involved, and the driver core, there is no difference. That was one of the primary goals of the driver core creation so many years ago. Today, the unbind operation to an ACPI cpu/memory devices causes hot-unplug (offline) operation to them, which is one of the major issues for us since unbind cannot fail. This patchset addresses this issue by making the unbind operation of ACPI cpu/memory devices to do the unbinding only. ACPI drivers no longer control cpu and memory as they are supposed to be controlled by their drivers, cpu and memory modules. I think that's the problem right there, solve that, please. We cannot eliminate the ACPI drivers since we have to scan ACPI. But we can limit the ACPI drivers to do the scanning stuff only. This is precisely the intend of this patchset. The real stuff, removing actual devices, is done by the system device drivers/modules. 2. Why are the system devices special? The system devices are initialized during early boot-time, by multiple subsystems, from the boot-up sequence, in pre-defined order. They provide low-level services to enable other subsystems to come up. Sorry, no, that doesn't mean they are special, nothing here is unique for the point of view of the driver model from any other device or bus. I think system devices are unique in a sense that they are initialized before drivers run. No, most all devices are initialized before a driver runs on it, USB is one such example, PCI another, and I'm pretty sure that there are others. USB devices can be initialized after the USB bus driver is initialized. Similarly, PCI devices can be initialized after the PCI bus driver is initialized. However, CPU and memory are initialized without any dependency to their bus driver since there is no such thing. You can create such a thing if you want :) Well, a pseudo driver could be created for it, but it does not make any difference. Access to CPU and memory does not go thru any bus controller visible to the OS. CPU and memory are connected with links (which are up at begging) and do not have bus structure any more. In addition, CPU and memory have two drivers -- their actual drivers/subsystems and their ACPI drivers. Again, I feel that is the root of the problem. Rafael seems to be working on solving this, which
[tip:irq/core] arch Kconfig: Remove references to IRQ_PER_CPU
Commit-ID: f7c819c020db9796ae3a662b82a310617f92b15b Gitweb: http://git.kernel.org/tip/f7c819c020db9796ae3a662b82a310617f92b15b Author: James Hogan james.ho...@imgtec.com AuthorDate: Mon, 4 Feb 2013 10:09:43 + Committer: Thomas Gleixner t...@linutronix.de CommitDate: Mon, 4 Feb 2013 18:53:20 +0100 arch Kconfig: Remove references to IRQ_PER_CPU The IRQ_PER_CPU Kconfig symbol was removed in the following commit: Commit 6a58fb3bad099076f36f0f30f44507bc3275cdb6 (genirq: Remove CONFIG_IRQ_PER_CPU) merged in v2.6.39-rc1. But IRQ_PER_CPU wasn't removed from any of the architecture Kconfig files where it was defined or selected. It's completely unused so remove the remaining references. Signed-off-by: James Hogan james.ho...@imgtec.com Cc: uclinux-dist-de...@blackfin.uclinux.org Cc: linux-m...@linux-mips.org Cc: linuxppc-dev@lists.ozlabs.org Cc: Mike Frysinger vap...@gentoo.org Cc: Fenghua Yu fenghua...@intel.com Acked-by: Ralf Baechle r...@linux-mips.org Cc: James E.J. Bottomley j...@parisc-linux.org Cc: Helge Deller del...@gmx.de Cc: Benjamin Herrenschmidt b...@kernel.crashing.org Cc: Paul Mackerras pau...@samba.org Acked-by: Paul Mundt let...@linux-sh.org Acked-by: Tony Luck tony.l...@intel.com Acked-by: Richard Kuo r...@codeaurora.org Link: http://lkml.kernel.org/r/1359972583-17134-1-git-send-email-james.ho...@imgtec.com Signed-off-by: Thomas Gleixner t...@linutronix.de --- arch/blackfin/Kconfig | 1 - arch/hexagon/Kconfig | 1 - arch/ia64/Kconfig | 1 - arch/mips/Kconfig | 1 - arch/parisc/Kconfig | 1 - arch/powerpc/Kconfig | 1 - arch/sh/Kconfig | 3 --- 7 files changed, 9 deletions(-) diff --git a/arch/blackfin/Kconfig b/arch/blackfin/Kconfig index 86f891f..67e4aaa 100644 --- a/arch/blackfin/Kconfig +++ b/arch/blackfin/Kconfig @@ -37,7 +37,6 @@ config BLACKFIN select HAVE_GENERIC_HARDIRQS select GENERIC_ATOMIC64 select GENERIC_IRQ_PROBE - select IRQ_PER_CPU if SMP select USE_GENERIC_SMP_HELPERS if SMP select HAVE_NMI_WATCHDOG if NMI_WATCHDOG select GENERIC_SMP_IDLE_THREAD diff --git a/arch/hexagon/Kconfig b/arch/hexagon/Kconfig index 40a3185..e4decc6 100644 --- a/arch/hexagon/Kconfig +++ b/arch/hexagon/Kconfig @@ -12,7 +12,6 @@ config HEXAGON # select ARCH_WANT_OPTIONAL_GPIOLIB # select ARCH_REQUIRE_GPIOLIB # select HAVE_CLK - # select IRQ_PER_CPU # select GENERIC_PENDING_IRQ if SMP select GENERIC_ATOMIC64 select HAVE_PERF_EVENTS diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig index 3279646..00c2e88 100644 --- a/arch/ia64/Kconfig +++ b/arch/ia64/Kconfig @@ -29,7 +29,6 @@ config IA64 select ARCH_DISCARD_MEMBLOCK select GENERIC_IRQ_PROBE select GENERIC_PENDING_IRQ if SMP - select IRQ_PER_CPU select GENERIC_IRQ_SHOW select ARCH_WANT_OPTIONAL_GPIOLIB select ARCH_HAVE_NMI_SAFE_CMPXCHG diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index 121ed51..9becc44 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -2160,7 +2160,6 @@ source mm/Kconfig config SMP bool Multi-Processing support depends on SYS_SUPPORTS_SMP - select IRQ_PER_CPU select USE_GENERIC_SMP_HELPERS help This enables support for systems with more than one CPU. If you have diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig index 9dd5c18..a32e34e 100644 --- a/arch/parisc/Kconfig +++ b/arch/parisc/Kconfig @@ -15,7 +15,6 @@ config PARISC select BROKEN_RODATA select GENERIC_IRQ_PROBE select GENERIC_PCI_IOMAP - select IRQ_PER_CPU select ARCH_HAVE_NMI_SAFE_CMPXCHG select GENERIC_SMP_IDLE_THREAD select GENERIC_STRNCPY_FROM_USER diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index d45edca..561ccca 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -124,7 +124,6 @@ config PPC select HAVE_GENERIC_HARDIRQS select ARCH_WANT_IPC_PARSE_VERSION select SPARSE_IRQ - select IRQ_PER_CPU select IRQ_DOMAIN select GENERIC_IRQ_SHOW select GENERIC_IRQ_SHOW_LEVEL diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig index 996e008..9c833c5 100644 --- a/arch/sh/Kconfig +++ b/arch/sh/Kconfig @@ -90,9 +90,6 @@ config GENERIC_CSUM config GENERIC_HWEIGHT def_bool y -config IRQ_PER_CPU - def_bool y - config GENERIC_GPIO def_bool n ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH RESEND 1/1] arch Kconfig: remove references to IRQ_PER_CPU
On Mon, 2013-02-04 at 10:09 +, James Hogan wrote: The IRQ_PER_CPU Kconfig symbol was removed in the following commit: Commit 6a58fb3bad099076f36f0f30f44507bc3275cdb6 (genirq: Remove CONFIG_IRQ_PER_CPU) merged in v2.6.39-rc1. But IRQ_PER_CPU wasn't removed from any of the architecture Kconfig files where it was defined or selected. It's completely unused so remove the remaining references. Signed-off-by: James Hogan james.ho...@imgtec.com Cc: Thomas Gleixner t...@linutronix.de Cc: Mike Frysinger vap...@gentoo.org Cc: Fenghua Yu fenghua...@intel.com Cc: Ralf Baechle r...@linux-mips.org Cc: James E.J. Bottomley j...@parisc-linux.org Cc: Helge Deller del...@gmx.de Cc: Benjamin Herrenschmidt b...@kernel.crashing.org Cc: Paul Mackerras pau...@samba.org Cc: Paul Mundt let...@linux-sh.org Acked-by: Tony Luck tony.l...@intel.com Acked-by: Richard Kuo r...@codeaurora.org For what it's worth ACK, but I don't really think you need it since the patch is trivial and obviously correct. Does anybody want to pick this patch up? I see Thomas already has. Thanks, by the way, for not doing this as one patch per architecture ... James ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH v2 01/12] Add sys_hotplug.h for system device hotplug framework
On Monday, February 04, 2013 09:19:09 AM Toshi Kani wrote: On Mon, 2013-02-04 at 15:21 +0100, Rafael J. Wysocki wrote: On Monday, February 04, 2013 04:48:10 AM Greg KH wrote: On Sun, Feb 03, 2013 at 09:44:39PM +0100, Rafael J. Wysocki wrote: Yes, but those are just remove events and we can only see how destructive they were after the removal. The point is to be able to figure out whether or not we *want* to do the removal in the first place. Say you have a computing node which signals a hardware problem in a processor package (the container with CPU cores, memory, PCI host bridge etc.). You may want to eject that package, but you don't want to kill the system this way. So if the eject is doable, it is very much desirable to do it, but if it is not doable, you'd rather shut the box down and do the replacement afterward. That may be costly, however (maybe weeks of computations), so it should be avoided if possible, but not at the expense of crashing the box if the eject doesn't work out. It seems to me that we could handle that with the help of a new flag, say no_eject, in struct device, a global mutex, and a function that will walk the given subtree of the device hierarchy and check if no_eject is set for any devices in there. Plus a global no_eject switch, perhaps. I think this will always be racy, or at worst, slow things down on normal device operations as you will always be having to grab this flag whenever you want to do something new. I don't see why this particular scheme should be racy, at least I don't see any obvious races in it (although I'm not that good at races detection in general, admittedly). Also, I don't expect that flag to be used for everything, just for things known to seriously break if forcible eject is done. That may be not precise enough, so that's a matter of defining its purpose more precisely. We can do something like that on the ACPI level (ie. introduce a no_eject flag in struct acpi_device and provide an iterface for the layers above ACPI to manipulate it) but then devices without ACPI namespace objects won't be covered. That may not be a big deal, though. I am afraid that bringing the device status management into the ACPI level would not a good idea. acpi_device should only reflect ACPI device object information, not how its actual device is being used. I like your initiative of acpi_scan_driver and I think scanning / trimming of ACPI object info is what the ACPI drivers should do. ACPI drivers, yes, but the users of ACPI already rely on information in struct acpi_device. Like ACPI device power states, for example. So platform_no_eject(dev) is not much different in that respect from platform_pci_set_power_state(pci_dev). The whole eject concept is somewhat ACPI-specific, though, and the eject notifications come from ACPI, so I don't have a problem with limiting it to ACPI-backed devices for the time being. If it turns out the be useful outside of ACPI, then we can move it up to the driver core. For now I don't see a compelling reason to do that. Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH v2 01/12] Add sys_hotplug.h for system device hotplug framework
On Monday, February 04, 2013 09:46:18 AM Toshi Kani wrote: On Mon, 2013-02-04 at 04:46 -0800, Greg KH wrote: On Sun, Feb 03, 2013 at 05:28:09PM -0700, Toshi Kani wrote: On Sat, 2013-02-02 at 16:01 +0100, Greg KH wrote: On Fri, Feb 01, 2013 at 01:40:10PM -0700, Toshi Kani wrote: On Fri, 2013-02-01 at 07:30 +, Greg KH wrote: On Thu, Jan 31, 2013 at 06:32:18PM -0700, Toshi Kani wrote: This is already done for PCI host bridges and platform devices and I don't see why we can't do that for the other types of devices too. The only missing piece I see is a way to handle the eject problem, i.e. when we try do eject a device at the top of a subtree and need to tear down the entire subtree below it, but if that's going to lead to a system crash, for example, we want to cancel the eject. It seems to me that we'll need some help from the driver core here. There are three different approaches suggested for system device hot-plug: A. Proceed within system device bus scan. B. Proceed within ACPI bus scan. C. Proceed with a sequence (as a mini-boot). Option A uses system devices as tokens, option B uses acpi devices as tokens, and option C uses resource tables as tokens, for their handlers. Here is summary of key questions answers so far. I hope this clarifies why I am suggesting option 3. 1. What are the system devices? System devices provide system-wide core computing resources, which are essential to compose a computer system. System devices are not connected to any particular standard buses. Not a problem, lots of devices are not connected to any particular standard busses. All this means is that system devices are connected to the system bus, nothing more. Can you give me a few examples of other devices that support hotplug and are not connected to any particular buses? I will investigate them to see how they are managed to support hotplug. Any device that is attached to any bus in the driver model can be hotunplugged from userspace by telling it to be unbound from the driver controlling it. Try it for any platform device in your system to see how it happens. The unbind operation, as I understand from you, is to detach a driver from a device. Yes, unbinding can be done for any devices. It is however different from hot-plug operation, which unplugs a device. Physically, yes, but to the driver involved, and the driver core, there is no difference. That was one of the primary goals of the driver core creation so many years ago. Today, the unbind operation to an ACPI cpu/memory devices causes hot-unplug (offline) operation to them, which is one of the major issues for us since unbind cannot fail. This patchset addresses this issue by making the unbind operation of ACPI cpu/memory devices to do the unbinding only. ACPI drivers no longer control cpu and memory as they are supposed to be controlled by their drivers, cpu and memory modules. I think that's the problem right there, solve that, please. We cannot eliminate the ACPI drivers since we have to scan ACPI. But we can limit the ACPI drivers to do the scanning stuff only. This is precisely the intend of this patchset. The real stuff, removing actual devices, is done by the system device drivers/modules. In case you haven't realized that yet, the $subject patchset has no future. Let's just talk about how we can get what we need in more general terms. Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH v2 01/12] Add sys_hotplug.h for system device hotplug framework
On Monday, February 04, 2013 09:02:46 AM Toshi Kani wrote: On Mon, 2013-02-04 at 14:41 +0100, Rafael J. Wysocki wrote: On Sunday, February 03, 2013 07:23:49 PM Greg KH wrote: On Sat, Feb 02, 2013 at 09:15:37PM +0100, Rafael J. Wysocki wrote: On Saturday, February 02, 2013 03:58:01 PM Greg KH wrote: : Yes, but those are just remove events and we can only see how destructive they were after the removal. The point is to be able to figure out whether or not we *want* to do the removal in the first place. Yes, but, you will always race if you try to test to see if you can shut down a device and then trying to do it. So walking the bus ahead of time isn't a good idea. And, we really don't have a viable way to recover if disconnect() fails, do we. What do we do in that situation, restore the other devices we disconnected successfully? How do we remember/know what they were? PCI hotplug almost had this same problem until the designers finally realized that they just had to accept the fact that removing a PCI device could either happen by: - a user yanking out the device, at which time the OS better clean up properly no matter what happens - the user asked nicely to remove a device, and the OS can take as long as it wants to complete that action, including stalling for noticable amounts of time before eventually, always letting the action succeed. I think the second thing is what you have to do here. If a user tells the OS it wants to remove these devices, you better do it. If you can't, because memory is being used by someone else, either move them off, or just hope that nothing bad happens, before the user gets frustrated and yanks out the CPU/memory module themselves physically :) Well, that we can't help, but sometimes users really *want* the OS to tell them if it is safe to unplug something at this particualr time (think about the Windows' safe remove feature for USB sticks, for example; that came out of users' demand AFAIR). So in my opinion it would be good to give them an option to do safe eject or forcible eject, whichever they prefer. For system device hot-plug, it always needs to be safe eject. This feature will be implemented on mission critical servers, which are managed by professional IT folks. Crashing a server causes serious money to the business. Well, always is a bit too strong a word as far as human behavior is concerned in my opinion. That said I would be perfectly fine with not supporting the forcible eject to start with and waiting for the first request to add support for it. I also would be fine with taking bets on how much time it's going to take for such a request to appear. :-) Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC/PATCH 29/32] usb: gadget: pxa27x_udc: let udc-core manage gadget-dev
On Mon, Jan 28, 2013 at 09:18:29PM +0100, Robert Jarzmik wrote: Felipe Balbi ba...@ti.com writes: By simply setting a flag, we can drop some boilerplate code. Signed-off-by: Felipe Balbi ba...@ti.com --- drivers/usb/gadget/pxa27x_udc.c | 9 + Acked-by: Robert Jarzmik robert.jarz...@free.fr And I tested also your patch and it works in my environment. For next patches I'd like to be CCed for pxa27x_udc stuff as I'm maintaining that one since its beginning (and yes, I know, I didn't put that in MAINTAINERS ...). you should add yourself to MAINTAINERS. Please send a patch to Greg when you have time. No need to prepare a tree, though. I just need you to give your Acked-by and I'll queue the patches myself. cheers -- balbi signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH v2 01/12] Add sys_hotplug.h for system device hotplug framework
On Mon, 2013-02-04 at 20:48 +0100, Rafael J. Wysocki wrote: On Monday, February 04, 2013 09:02:46 AM Toshi Kani wrote: On Mon, 2013-02-04 at 14:41 +0100, Rafael J. Wysocki wrote: On Sunday, February 03, 2013 07:23:49 PM Greg KH wrote: On Sat, Feb 02, 2013 at 09:15:37PM +0100, Rafael J. Wysocki wrote: On Saturday, February 02, 2013 03:58:01 PM Greg KH wrote: : Yes, but those are just remove events and we can only see how destructive they were after the removal. The point is to be able to figure out whether or not we *want* to do the removal in the first place. Yes, but, you will always race if you try to test to see if you can shut down a device and then trying to do it. So walking the bus ahead of time isn't a good idea. And, we really don't have a viable way to recover if disconnect() fails, do we. What do we do in that situation, restore the other devices we disconnected successfully? How do we remember/know what they were? PCI hotplug almost had this same problem until the designers finally realized that they just had to accept the fact that removing a PCI device could either happen by: - a user yanking out the device, at which time the OS better clean up properly no matter what happens - the user asked nicely to remove a device, and the OS can take as long as it wants to complete that action, including stalling for noticable amounts of time before eventually, always letting the action succeed. I think the second thing is what you have to do here. If a user tells the OS it wants to remove these devices, you better do it. If you can't, because memory is being used by someone else, either move them off, or just hope that nothing bad happens, before the user gets frustrated and yanks out the CPU/memory module themselves physically :) Well, that we can't help, but sometimes users really *want* the OS to tell them if it is safe to unplug something at this particualr time (think about the Windows' safe remove feature for USB sticks, for example; that came out of users' demand AFAIR). So in my opinion it would be good to give them an option to do safe eject or forcible eject, whichever they prefer. For system device hot-plug, it always needs to be safe eject. This feature will be implemented on mission critical servers, which are managed by professional IT folks. Crashing a server causes serious money to the business. Well, always is a bit too strong a word as far as human behavior is concerned in my opinion. That said I would be perfectly fine with not supporting the forcible eject to start with and waiting for the first request to add support for it. I also would be fine with taking bets on how much time it's going to take for such a request to appear. :-) Sounds good. In my experience, though, it actually takes a LONG time to convince customers that safe eject is actually safe. Enterprise customers are so afraid of doing anything risky that might cause the system to crash or hang due to some defect. I would be very surprised to see a customer asking for a force operation when we do not guarantee its outcome. I have not seen such enterprise customers yet. Thanks, -Toshi ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH v2 01/12] Add sys_hotplug.h for system device hotplug framework
On Monday, February 04, 2013 06:33:52 AM Greg KH wrote: On Mon, Feb 04, 2013 at 03:21:22PM +0100, Rafael J. Wysocki wrote: On Monday, February 04, 2013 04:48:10 AM Greg KH wrote: On Sun, Feb 03, 2013 at 09:44:39PM +0100, Rafael J. Wysocki wrote: Yes, but those are just remove events and we can only see how destructive they were after the removal. The point is to be able to figure out whether or not we *want* to do the removal in the first place. Say you have a computing node which signals a hardware problem in a processor package (the container with CPU cores, memory, PCI host bridge etc.). You may want to eject that package, but you don't want to kill the system this way. So if the eject is doable, it is very much desirable to do it, but if it is not doable, you'd rather shut the box down and do the replacement afterward. That may be costly, however (maybe weeks of computations), so it should be avoided if possible, but not at the expense of crashing the box if the eject doesn't work out. It seems to me that we could handle that with the help of a new flag, say no_eject, in struct device, a global mutex, and a function that will walk the given subtree of the device hierarchy and check if no_eject is set for any devices in there. Plus a global no_eject switch, perhaps. I think this will always be racy, or at worst, slow things down on normal device operations as you will always be having to grab this flag whenever you want to do something new. I don't see why this particular scheme should be racy, at least I don't see any obvious races in it (although I'm not that good at races detection in general, admittedly). Also, I don't expect that flag to be used for everything, just for things known to seriously break if forcible eject is done. That may be not precise enough, so that's a matter of defining its purpose more precisely. We can do something like that on the ACPI level (ie. introduce a no_eject flag in struct acpi_device and provide an iterface for the layers above ACPI to manipulate it) but then devices without ACPI namespace objects won't be covered. That may not be a big deal, though. So say dev is about to be used for something incompatible with ejecting, so to speak. Then, one would do platform_lock_eject(dev), which would check if dev has an ACPI handle and then take acpi_eject_lock (if so). The return value of platform_lock_eject(dev) would need to be checked to see if the device is not gone. If it returns success (0), one would do something to the device and call platform_no_eject(dev) and then platform_unlock_eject(dev). How does a device know it is doing something that is incompatible with ejecting? That's a non-trivial task from what I can tell. I agree that this is complicated in general. But. There are devices known to have software offline and online operations such that after the offline the given device is guaranteed to be not used until online. We have that for CPU cores, for example, and user space can do it via /sys/devices/system/cpu/cpuX/online . So, why don't we make the online set the no_eject flag (under the lock as appropriate) and the offline clear it? And why don't we define such online and offline for all of the other system stuff, like memory, PCI host bridges etc. and make it behave analogously? Then, it is quite simple to say which devices should use the no_eject flag: devices that have online and offline exported to user space. And guess who's responsible for offlining all of those things before trying to eject them: user space is. From the kernel's point of view it is all clear. Hands clean. :-) Now, there's a different problem how to expose all of the relevant information to user space so that it knows what to offline for the specific eject operation to succeed, but that's kind of separate and worth addressing anyway. What happens if a device wants to set that flag, right after it was told to eject and the device was in the middle of being removed? How can you fail the I can't be removed me now, so don't requirement that it now has? This one is easy. :-) If platform_lock_eject() is called when an eject is under way, it will block on acpi_eject_lock until the eject is complete and if the device is gone as a result of the eject, it will return an error code. In turn, if an eject happens after platform_lock_eject(), it will block until platform_unlock_eject() and if platform_no_eject() is called in between the lock and unlock, it will notice the device with no_eject set and bail out. Quite obviously, it would be a bug to call platform_lock_eject() from within an eject code path. Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center.
Re: Why is the e500v2 core not using cpuidle?
On 02/02/2013 03:41:27 AM, Thomas Waldecker wrote: Hi Scott, Why is there no support for the cpuidle framework? Because nobody implemented it. :-) That's the reason I thought before :-) The only reason I can think of to implement it on this chip would be to dynamically choose when to enter nap versus doze, rather than always just using doze. It's not clear whether the difference in power savings is worth it -- do you have any way of measuring? Is the e500 only using doze? There are comments in the file arch/powerpc/kernel/idle_e500.S which are stating: /* Go to NAP or DOZE now */ or /* Return from NAP/DOZE ...*/ and because of this comments I thought that both modes are in use. e500 can use nap instead, but it's statically chosen via sysctl. The default is doze. Entering nap requires flushing the cache, so you'd only use nap if you care more about lowering idle power consumption than performance, and you wake infrequently enough that you're not burning more power on the cache flushes than you save with the deeper idle state. I have a way of measuring the power and it is also a small part of my masterthesis, but it is not very meaningful because at the measuring point there are other peripheral components too. According to the comments can I activate the nap mode somehow? echo 1 /proc/sys/kernel/powersave-nap If you're able to measure a meaningful difference between the two, I'd be interested in hearing your results. How can I debug the e500 idle modes? Are there any statistics? Top reports idle percentage... If the e500 and e500v2 are indeed using only the doze mode it would be enough statistics. Whichever mode you have selected, that will be used for all idling. Statistics would only be useful if the idle mode were dynamically chosen. Such statistics would be great for the doze, nap (and sleep for the whole package). The only way you'll get into sleep mode is through /sys/power/state. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH v2 01/12] Add sys_hotplug.h for system device hotplug framework
On Monday, February 04, 2013 12:46:24 PM Toshi Kani wrote: On Mon, 2013-02-04 at 20:48 +0100, Rafael J. Wysocki wrote: On Monday, February 04, 2013 09:02:46 AM Toshi Kani wrote: On Mon, 2013-02-04 at 14:41 +0100, Rafael J. Wysocki wrote: On Sunday, February 03, 2013 07:23:49 PM Greg KH wrote: On Sat, Feb 02, 2013 at 09:15:37PM +0100, Rafael J. Wysocki wrote: On Saturday, February 02, 2013 03:58:01 PM Greg KH wrote: : Yes, but those are just remove events and we can only see how destructive they were after the removal. The point is to be able to figure out whether or not we *want* to do the removal in the first place. Yes, but, you will always race if you try to test to see if you can shut down a device and then trying to do it. So walking the bus ahead of time isn't a good idea. And, we really don't have a viable way to recover if disconnect() fails, do we. What do we do in that situation, restore the other devices we disconnected successfully? How do we remember/know what they were? PCI hotplug almost had this same problem until the designers finally realized that they just had to accept the fact that removing a PCI device could either happen by: - a user yanking out the device, at which time the OS better clean up properly no matter what happens - the user asked nicely to remove a device, and the OS can take as long as it wants to complete that action, including stalling for noticable amounts of time before eventually, always letting the action succeed. I think the second thing is what you have to do here. If a user tells the OS it wants to remove these devices, you better do it. If you can't, because memory is being used by someone else, either move them off, or just hope that nothing bad happens, before the user gets frustrated and yanks out the CPU/memory module themselves physically :) Well, that we can't help, but sometimes users really *want* the OS to tell them if it is safe to unplug something at this particualr time (think about the Windows' safe remove feature for USB sticks, for example; that came out of users' demand AFAIR). So in my opinion it would be good to give them an option to do safe eject or forcible eject, whichever they prefer. For system device hot-plug, it always needs to be safe eject. This feature will be implemented on mission critical servers, which are managed by professional IT folks. Crashing a server causes serious money to the business. Well, always is a bit too strong a word as far as human behavior is concerned in my opinion. That said I would be perfectly fine with not supporting the forcible eject to start with and waiting for the first request to add support for it. I also would be fine with taking bets on how much time it's going to take for such a request to appear. :-) Sounds good. In my experience, though, it actually takes a LONG time to convince customers that safe eject is actually safe. Enterprise customers are so afraid of doing anything risky that might cause the system to crash or hang due to some defect. I would be very surprised to see a customer asking for a force operation when we do not guarantee its outcome. I have not seen such enterprise customers yet. But we're talking about a kernel that is supposed to run on mobile phones too, among other things. Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH v2 01/12] Add sys_hotplug.h for system device hotplug framework
On Mon, 2013-02-04 at 21:12 +0100, Rafael J. Wysocki wrote: On Monday, February 04, 2013 12:46:24 PM Toshi Kani wrote: On Mon, 2013-02-04 at 20:48 +0100, Rafael J. Wysocki wrote: On Monday, February 04, 2013 09:02:46 AM Toshi Kani wrote: On Mon, 2013-02-04 at 14:41 +0100, Rafael J. Wysocki wrote: On Sunday, February 03, 2013 07:23:49 PM Greg KH wrote: On Sat, Feb 02, 2013 at 09:15:37PM +0100, Rafael J. Wysocki wrote: On Saturday, February 02, 2013 03:58:01 PM Greg KH wrote: : Yes, but those are just remove events and we can only see how destructive they were after the removal. The point is to be able to figure out whether or not we *want* to do the removal in the first place. Yes, but, you will always race if you try to test to see if you can shut down a device and then trying to do it. So walking the bus ahead of time isn't a good idea. And, we really don't have a viable way to recover if disconnect() fails, do we. What do we do in that situation, restore the other devices we disconnected successfully? How do we remember/know what they were? PCI hotplug almost had this same problem until the designers finally realized that they just had to accept the fact that removing a PCI device could either happen by: - a user yanking out the device, at which time the OS better clean up properly no matter what happens - the user asked nicely to remove a device, and the OS can take as long as it wants to complete that action, including stalling for noticable amounts of time before eventually, always letting the action succeed. I think the second thing is what you have to do here. If a user tells the OS it wants to remove these devices, you better do it. If you can't, because memory is being used by someone else, either move them off, or just hope that nothing bad happens, before the user gets frustrated and yanks out the CPU/memory module themselves physically :) Well, that we can't help, but sometimes users really *want* the OS to tell them if it is safe to unplug something at this particualr time (think about the Windows' safe remove feature for USB sticks, for example; that came out of users' demand AFAIR). So in my opinion it would be good to give them an option to do safe eject or forcible eject, whichever they prefer. For system device hot-plug, it always needs to be safe eject. This feature will be implemented on mission critical servers, which are managed by professional IT folks. Crashing a server causes serious money to the business. Well, always is a bit too strong a word as far as human behavior is concerned in my opinion. That said I would be perfectly fine with not supporting the forcible eject to start with and waiting for the first request to add support for it. I also would be fine with taking bets on how much time it's going to take for such a request to appear. :-) Sounds good. In my experience, though, it actually takes a LONG time to convince customers that safe eject is actually safe. Enterprise customers are so afraid of doing anything risky that might cause the system to crash or hang due to some defect. I would be very surprised to see a customer asking for a force operation when we do not guarantee its outcome. I have not seen such enterprise customers yet. But we're talking about a kernel that is supposed to run on mobile phones too, among other things. I think using this feature for RAS i.e. replacing a faulty device on-line, will continue to be limited for high-end systems. For low-end systems, it does not make sense for customers to pay much $$ for this feature. They can just shut the system down for replacement, or they can simply buy a new system instead of repairing. That said, using this feature on VM for workload balancing does not require any special hardware. So, I can see someone willing to try out to see how it goes with a force option on VM for personal use. Thanks, -Toshi ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH v2 01/12] Add sys_hotplug.h for system device hotplug framework
On Mon, 2013-02-04 at 20:45 +0100, Rafael J. Wysocki wrote: On Monday, February 04, 2013 09:46:18 AM Toshi Kani wrote: On Mon, 2013-02-04 at 04:46 -0800, Greg KH wrote: On Sun, Feb 03, 2013 at 05:28:09PM -0700, Toshi Kani wrote: On Sat, 2013-02-02 at 16:01 +0100, Greg KH wrote: On Fri, Feb 01, 2013 at 01:40:10PM -0700, Toshi Kani wrote: On Fri, 2013-02-01 at 07:30 +, Greg KH wrote: On Thu, Jan 31, 2013 at 06:32:18PM -0700, Toshi Kani wrote: This is already done for PCI host bridges and platform devices and I don't see why we can't do that for the other types of devices too. The only missing piece I see is a way to handle the eject problem, i.e. when we try do eject a device at the top of a subtree and need to tear down the entire subtree below it, but if that's going to lead to a system crash, for example, we want to cancel the eject. It seems to me that we'll need some help from the driver core here. There are three different approaches suggested for system device hot-plug: A. Proceed within system device bus scan. B. Proceed within ACPI bus scan. C. Proceed with a sequence (as a mini-boot). Option A uses system devices as tokens, option B uses acpi devices as tokens, and option C uses resource tables as tokens, for their handlers. Here is summary of key questions answers so far. I hope this clarifies why I am suggesting option 3. 1. What are the system devices? System devices provide system-wide core computing resources, which are essential to compose a computer system. System devices are not connected to any particular standard buses. Not a problem, lots of devices are not connected to any particular standard busses. All this means is that system devices are connected to the system bus, nothing more. Can you give me a few examples of other devices that support hotplug and are not connected to any particular buses? I will investigate them to see how they are managed to support hotplug. Any device that is attached to any bus in the driver model can be hotunplugged from userspace by telling it to be unbound from the driver controlling it. Try it for any platform device in your system to see how it happens. The unbind operation, as I understand from you, is to detach a driver from a device. Yes, unbinding can be done for any devices. It is however different from hot-plug operation, which unplugs a device. Physically, yes, but to the driver involved, and the driver core, there is no difference. That was one of the primary goals of the driver core creation so many years ago. Today, the unbind operation to an ACPI cpu/memory devices causes hot-unplug (offline) operation to them, which is one of the major issues for us since unbind cannot fail. This patchset addresses this issue by making the unbind operation of ACPI cpu/memory devices to do the unbinding only. ACPI drivers no longer control cpu and memory as they are supposed to be controlled by their drivers, cpu and memory modules. I think that's the problem right there, solve that, please. We cannot eliminate the ACPI drivers since we have to scan ACPI. But we can limit the ACPI drivers to do the scanning stuff only. This is precisely the intend of this patchset. The real stuff, removing actual devices, is done by the system device drivers/modules. In case you haven't realized that yet, the $subject patchset has no future. That's really disappointing, esp. the fact that this basic approach has been proven to work on other OS for years... Let's just talk about how we can get what we need in more general terms. So, are we heading to an approach of doing everything in ACPI? I am not clear about which direction we have agreed with or disagreed with. As for the eject flag approach, I agree with Greg. Thanks, -Toshi ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc/512x: add function for chip select parameter configuration
On Mon, Feb 4, 2013 at 4:16 AM, Anatolij Gustschin ag...@denx.de wrote: Add ability to configure chip select (CS) parameters for devices that need different CS parameters setup after their configuration. I.e. an FPGA device on LP bus can require different CS parameters for its bus interface after loading firmware into it. A driver can easily reconfigure the LPC CS parameters using this function. Signed-off-by: Anatolij Gustschin ag...@denx.de --- Acked-by: Timur Tabi ti...@tabi.org -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH v2 01/12] Add sys_hotplug.h for system device hotplug framework
On Mon, 2013-02-04 at 21:07 +0100, Rafael J. Wysocki wrote: On Monday, February 04, 2013 06:33:52 AM Greg KH wrote: On Mon, Feb 04, 2013 at 03:21:22PM +0100, Rafael J. Wysocki wrote: On Monday, February 04, 2013 04:48:10 AM Greg KH wrote: On Sun, Feb 03, 2013 at 09:44:39PM +0100, Rafael J. Wysocki wrote: Yes, but those are just remove events and we can only see how destructive they were after the removal. The point is to be able to figure out whether or not we *want* to do the removal in the first place. Say you have a computing node which signals a hardware problem in a processor package (the container with CPU cores, memory, PCI host bridge etc.). You may want to eject that package, but you don't want to kill the system this way. So if the eject is doable, it is very much desirable to do it, but if it is not doable, you'd rather shut the box down and do the replacement afterward. That may be costly, however (maybe weeks of computations), so it should be avoided if possible, but not at the expense of crashing the box if the eject doesn't work out. It seems to me that we could handle that with the help of a new flag, say no_eject, in struct device, a global mutex, and a function that will walk the given subtree of the device hierarchy and check if no_eject is set for any devices in there. Plus a global no_eject switch, perhaps. I think this will always be racy, or at worst, slow things down on normal device operations as you will always be having to grab this flag whenever you want to do something new. I don't see why this particular scheme should be racy, at least I don't see any obvious races in it (although I'm not that good at races detection in general, admittedly). Also, I don't expect that flag to be used for everything, just for things known to seriously break if forcible eject is done. That may be not precise enough, so that's a matter of defining its purpose more precisely. We can do something like that on the ACPI level (ie. introduce a no_eject flag in struct acpi_device and provide an iterface for the layers above ACPI to manipulate it) but then devices without ACPI namespace objects won't be covered. That may not be a big deal, though. So say dev is about to be used for something incompatible with ejecting, so to speak. Then, one would do platform_lock_eject(dev), which would check if dev has an ACPI handle and then take acpi_eject_lock (if so). The return value of platform_lock_eject(dev) would need to be checked to see if the device is not gone. If it returns success (0), one would do something to the device and call platform_no_eject(dev) and then platform_unlock_eject(dev). How does a device know it is doing something that is incompatible with ejecting? That's a non-trivial task from what I can tell. I agree that this is complicated in general. But. There are devices known to have software offline and online operations such that after the offline the given device is guaranteed to be not used until online. We have that for CPU cores, for example, and user space can do it via /sys/devices/system/cpu/cpuX/online . So, why don't we make the online set the no_eject flag (under the lock as appropriate) and the offline clear it? And why don't we define such online and offline for all of the other system stuff, like memory, PCI host bridges etc. and make it behave analogously? Then, it is quite simple to say which devices should use the no_eject flag: devices that have online and offline exported to user space. And guess who's responsible for offlining all of those things before trying to eject them: user space is. From the kernel's point of view it is all clear. Hands clean. :-) Now, there's a different problem how to expose all of the relevant information to user space so that it knows what to offline for the specific eject operation to succeed, but that's kind of separate and worth addressing anyway. So, the idea is to run a user space program that off-lines all relevant devices before trimming ACPI devices. Is that right? That sounds like a worth idea to consider with. This basically moves the sequencer part into user space instead of the kernel space in my proposal. I agree that how to expose all of the relevant info to user space is an issue. Also, we will need to make sure that the user program always runs per a kernel request and then informs a result back to the kernel, so that the kernel can do the rest of an operation and inform a result to FW with _OST or _EJ0. This loop has to close. I think it is going to be more complicated than the kernel-only approach. In addition, I am not sure if the no_eject flag in acpi_device is
Re: [PATCH v6 08/15] memory-hotplug: Common APIs to support page tables hot-remove
On Wed, 9 Jan 2013 17:32:32 +0800
Tang Chen tangc...@cn.fujitsu.com wrote:
+static void __meminit
+remove_pagetable(unsigned long start, unsigned long end, bool direct)
+{
+ unsigned long next;
+ pgd_t *pgd;
+ pud_t *pud;
+ bool pgd_changed = false;
+
+ for (; start end; start = next) {
+ pgd = pgd_offset_k(start);
+ if (!pgd_present(*pgd))
+ continue;
+
+ next = pgd_addr_end(start, end);
+
+ pud = (pud_t *)map_low_page((pud_t *)pgd_page_vaddr(*pgd));
+ remove_pud_table(pud, start, next, direct);
+ if (free_pud_table(pud, pgd))
+ pgd_changed = true;
+ unmap_low_page(pud);
+ }
+
+ if (pgd_changed)
+ sync_global_pgds(start, end - 1);
+
+ flush_tlb_all();
+}
This generates a compiler warning saying that `next' may be used
uninitialised.
The warning is correct. If we take that `continue' on the first pass
through the loop, the start = next will copy uninitialised data into
`start'.
Is this the correct fix?
---
a/arch/x86/mm/init_64.c~memory-hotplug-common-apis-to-support-page-tables-hot-remove-fix-fix-fix-fix-fix-fix-fix
+++ a/arch/x86/mm/init_64.c
@@ -993,12 +993,12 @@ remove_pagetable(unsigned long start, un
bool pgd_changed = false;
for (; start end; start = next) {
+ next = pgd_addr_end(start, end);
+
pgd = pgd_offset_k(start);
if (!pgd_present(*pgd))
continue;
- next = pgd_addr_end(start, end);
-
pud = (pud_t *)pgd_page_vaddr(*pgd);
remove_pud_table(pud, start, next, direct);
if (free_pud_table(pud, pgd))
_
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH v2 01/12] Add sys_hotplug.h for system device hotplug framework
On Monday, February 04, 2013 01:34:18 PM Toshi Kani wrote: On Mon, 2013-02-04 at 21:12 +0100, Rafael J. Wysocki wrote: On Monday, February 04, 2013 12:46:24 PM Toshi Kani wrote: On Mon, 2013-02-04 at 20:48 +0100, Rafael J. Wysocki wrote: On Monday, February 04, 2013 09:02:46 AM Toshi Kani wrote: On Mon, 2013-02-04 at 14:41 +0100, Rafael J. Wysocki wrote: On Sunday, February 03, 2013 07:23:49 PM Greg KH wrote: On Sat, Feb 02, 2013 at 09:15:37PM +0100, Rafael J. Wysocki wrote: On Saturday, February 02, 2013 03:58:01 PM Greg KH wrote: : Yes, but those are just remove events and we can only see how destructive they were after the removal. The point is to be able to figure out whether or not we *want* to do the removal in the first place. Yes, but, you will always race if you try to test to see if you can shut down a device and then trying to do it. So walking the bus ahead of time isn't a good idea. And, we really don't have a viable way to recover if disconnect() fails, do we. What do we do in that situation, restore the other devices we disconnected successfully? How do we remember/know what they were? PCI hotplug almost had this same problem until the designers finally realized that they just had to accept the fact that removing a PCI device could either happen by: - a user yanking out the device, at which time the OS better clean up properly no matter what happens - the user asked nicely to remove a device, and the OS can take as long as it wants to complete that action, including stalling for noticable amounts of time before eventually, always letting the action succeed. I think the second thing is what you have to do here. If a user tells the OS it wants to remove these devices, you better do it. If you can't, because memory is being used by someone else, either move them off, or just hope that nothing bad happens, before the user gets frustrated and yanks out the CPU/memory module themselves physically :) Well, that we can't help, but sometimes users really *want* the OS to tell them if it is safe to unplug something at this particualr time (think about the Windows' safe remove feature for USB sticks, for example; that came out of users' demand AFAIR). So in my opinion it would be good to give them an option to do safe eject or forcible eject, whichever they prefer. For system device hot-plug, it always needs to be safe eject. This feature will be implemented on mission critical servers, which are managed by professional IT folks. Crashing a server causes serious money to the business. Well, always is a bit too strong a word as far as human behavior is concerned in my opinion. That said I would be perfectly fine with not supporting the forcible eject to start with and waiting for the first request to add support for it. I also would be fine with taking bets on how much time it's going to take for such a request to appear. :-) Sounds good. In my experience, though, it actually takes a LONG time to convince customers that safe eject is actually safe. Enterprise customers are so afraid of doing anything risky that might cause the system to crash or hang due to some defect. I would be very surprised to see a customer asking for a force operation when we do not guarantee its outcome. I have not seen such enterprise customers yet. But we're talking about a kernel that is supposed to run on mobile phones too, among other things. I think using this feature for RAS i.e. replacing a faulty device on-line, will continue to be limited for high-end systems. For low-end systems, it does not make sense for customers to pay much $$ for this feature. They can just shut the system down for replacement, or they can simply buy a new system instead of repairing. That said, using this feature on VM for workload balancing does not require any special hardware. So, I can see someone willing to try out to see how it goes with a force option on VM for personal use. Besides, SMP was a $$ enterprise feature not so long ago, so things tend to change. :-) Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH v2 01/12] Add sys_hotplug.h for system device hotplug framework
On Monday, February 04, 2013 01:59:27 PM Toshi Kani wrote: On Mon, 2013-02-04 at 20:45 +0100, Rafael J. Wysocki wrote: On Monday, February 04, 2013 09:46:18 AM Toshi Kani wrote: On Mon, 2013-02-04 at 04:46 -0800, Greg KH wrote: On Sun, Feb 03, 2013 at 05:28:09PM -0700, Toshi Kani wrote: On Sat, 2013-02-02 at 16:01 +0100, Greg KH wrote: On Fri, Feb 01, 2013 at 01:40:10PM -0700, Toshi Kani wrote: On Fri, 2013-02-01 at 07:30 +, Greg KH wrote: On Thu, Jan 31, 2013 at 06:32:18PM -0700, Toshi Kani wrote: This is already done for PCI host bridges and platform devices and I don't see why we can't do that for the other types of devices too. The only missing piece I see is a way to handle the eject problem, i.e. when we try do eject a device at the top of a subtree and need to tear down the entire subtree below it, but if that's going to lead to a system crash, for example, we want to cancel the eject. It seems to me that we'll need some help from the driver core here. There are three different approaches suggested for system device hot-plug: A. Proceed within system device bus scan. B. Proceed within ACPI bus scan. C. Proceed with a sequence (as a mini-boot). Option A uses system devices as tokens, option B uses acpi devices as tokens, and option C uses resource tables as tokens, for their handlers. Here is summary of key questions answers so far. I hope this clarifies why I am suggesting option 3. 1. What are the system devices? System devices provide system-wide core computing resources, which are essential to compose a computer system. System devices are not connected to any particular standard buses. Not a problem, lots of devices are not connected to any particular standard busses. All this means is that system devices are connected to the system bus, nothing more. Can you give me a few examples of other devices that support hotplug and are not connected to any particular buses? I will investigate them to see how they are managed to support hotplug. Any device that is attached to any bus in the driver model can be hotunplugged from userspace by telling it to be unbound from the driver controlling it. Try it for any platform device in your system to see how it happens. The unbind operation, as I understand from you, is to detach a driver from a device. Yes, unbinding can be done for any devices. It is however different from hot-plug operation, which unplugs a device. Physically, yes, but to the driver involved, and the driver core, there is no difference. That was one of the primary goals of the driver core creation so many years ago. Today, the unbind operation to an ACPI cpu/memory devices causes hot-unplug (offline) operation to them, which is one of the major issues for us since unbind cannot fail. This patchset addresses this issue by making the unbind operation of ACPI cpu/memory devices to do the unbinding only. ACPI drivers no longer control cpu and memory as they are supposed to be controlled by their drivers, cpu and memory modules. I think that's the problem right there, solve that, please. We cannot eliminate the ACPI drivers since we have to scan ACPI. But we can limit the ACPI drivers to do the scanning stuff only. This is precisely the intend of this patchset. The real stuff, removing actual devices, is done by the system device drivers/modules. In case you haven't realized that yet, the $subject patchset has no future. That's really disappointing, esp. the fact that this basic approach has been proven to work on other OS for years... Let's just talk about how we can get what we need in more general terms. So, are we heading to an approach of doing everything in ACPI? I am not clear about which direction we have agreed with or disagreed with. As for the eject flag approach, I agree with Greg. Well, I'm not sure which of the Greg's thoughts you agree with. :-) Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH v2 01/12] Add sys_hotplug.h for system device hotplug framework
On Tue, 2013-02-05 at 00:23 +0100, Rafael J. Wysocki wrote: On Monday, February 04, 2013 01:59:27 PM Toshi Kani wrote: On Mon, 2013-02-04 at 20:45 +0100, Rafael J. Wysocki wrote: On Monday, February 04, 2013 09:46:18 AM Toshi Kani wrote: On Mon, 2013-02-04 at 04:46 -0800, Greg KH wrote: On Sun, Feb 03, 2013 at 05:28:09PM -0700, Toshi Kani wrote: On Sat, 2013-02-02 at 16:01 +0100, Greg KH wrote: On Fri, Feb 01, 2013 at 01:40:10PM -0700, Toshi Kani wrote: On Fri, 2013-02-01 at 07:30 +, Greg KH wrote: On Thu, Jan 31, 2013 at 06:32:18PM -0700, Toshi Kani wrote: This is already done for PCI host bridges and platform devices and I don't see why we can't do that for the other types of devices too. The only missing piece I see is a way to handle the eject problem, i.e. when we try do eject a device at the top of a subtree and need to tear down the entire subtree below it, but if that's going to lead to a system crash, for example, we want to cancel the eject. It seems to me that we'll need some help from the driver core here. There are three different approaches suggested for system device hot-plug: A. Proceed within system device bus scan. B. Proceed within ACPI bus scan. C. Proceed with a sequence (as a mini-boot). Option A uses system devices as tokens, option B uses acpi devices as tokens, and option C uses resource tables as tokens, for their handlers. Here is summary of key questions answers so far. I hope this clarifies why I am suggesting option 3. 1. What are the system devices? System devices provide system-wide core computing resources, which are essential to compose a computer system. System devices are not connected to any particular standard buses. Not a problem, lots of devices are not connected to any particular standard busses. All this means is that system devices are connected to the system bus, nothing more. Can you give me a few examples of other devices that support hotplug and are not connected to any particular buses? I will investigate them to see how they are managed to support hotplug. Any device that is attached to any bus in the driver model can be hotunplugged from userspace by telling it to be unbound from the driver controlling it. Try it for any platform device in your system to see how it happens. The unbind operation, as I understand from you, is to detach a driver from a device. Yes, unbinding can be done for any devices. It is however different from hot-plug operation, which unplugs a device. Physically, yes, but to the driver involved, and the driver core, there is no difference. That was one of the primary goals of the driver core creation so many years ago. Today, the unbind operation to an ACPI cpu/memory devices causes hot-unplug (offline) operation to them, which is one of the major issues for us since unbind cannot fail. This patchset addresses this issue by making the unbind operation of ACPI cpu/memory devices to do the unbinding only. ACPI drivers no longer control cpu and memory as they are supposed to be controlled by their drivers, cpu and memory modules. I think that's the problem right there, solve that, please. We cannot eliminate the ACPI drivers since we have to scan ACPI. But we can limit the ACPI drivers to do the scanning stuff only. This is precisely the intend of this patchset. The real stuff, removing actual devices, is done by the system device drivers/modules. In case you haven't realized that yet, the $subject patchset has no future. That's really disappointing, esp. the fact that this basic approach has been proven to work on other OS for years... Let's just talk about how we can get what we need in more general terms. So, are we heading to an approach of doing everything in ACPI? I am not clear about which direction we have agreed with or disagreed with. As for the eject flag approach, I agree with Greg. Well, I'm not sure which of the Greg's thoughts you agree with. :-) Sorry, that was the Greg's comment below. But then, I saw your other email clarifying that the no_eject flag only reflects online/offline status, not how the device is being used. So, I replied with my thoughts in a separate email. :) === How does a device know it
Re: [RFC PATCH v2 01/12] Add sys_hotplug.h for system device hotplug framework
On Monday, February 04, 2013 03:13:29 PM Toshi Kani wrote: On Mon, 2013-02-04 at 21:07 +0100, Rafael J. Wysocki wrote: On Monday, February 04, 2013 06:33:52 AM Greg KH wrote: On Mon, Feb 04, 2013 at 03:21:22PM +0100, Rafael J. Wysocki wrote: On Monday, February 04, 2013 04:48:10 AM Greg KH wrote: On Sun, Feb 03, 2013 at 09:44:39PM +0100, Rafael J. Wysocki wrote: Yes, but those are just remove events and we can only see how destructive they were after the removal. The point is to be able to figure out whether or not we *want* to do the removal in the first place. Say you have a computing node which signals a hardware problem in a processor package (the container with CPU cores, memory, PCI host bridge etc.). You may want to eject that package, but you don't want to kill the system this way. So if the eject is doable, it is very much desirable to do it, but if it is not doable, you'd rather shut the box down and do the replacement afterward. That may be costly, however (maybe weeks of computations), so it should be avoided if possible, but not at the expense of crashing the box if the eject doesn't work out. It seems to me that we could handle that with the help of a new flag, say no_eject, in struct device, a global mutex, and a function that will walk the given subtree of the device hierarchy and check if no_eject is set for any devices in there. Plus a global no_eject switch, perhaps. I think this will always be racy, or at worst, slow things down on normal device operations as you will always be having to grab this flag whenever you want to do something new. I don't see why this particular scheme should be racy, at least I don't see any obvious races in it (although I'm not that good at races detection in general, admittedly). Also, I don't expect that flag to be used for everything, just for things known to seriously break if forcible eject is done. That may be not precise enough, so that's a matter of defining its purpose more precisely. We can do something like that on the ACPI level (ie. introduce a no_eject flag in struct acpi_device and provide an iterface for the layers above ACPI to manipulate it) but then devices without ACPI namespace objects won't be covered. That may not be a big deal, though. So say dev is about to be used for something incompatible with ejecting, so to speak. Then, one would do platform_lock_eject(dev), which would check if dev has an ACPI handle and then take acpi_eject_lock (if so). The return value of platform_lock_eject(dev) would need to be checked to see if the device is not gone. If it returns success (0), one would do something to the device and call platform_no_eject(dev) and then platform_unlock_eject(dev). How does a device know it is doing something that is incompatible with ejecting? That's a non-trivial task from what I can tell. I agree that this is complicated in general. But. There are devices known to have software offline and online operations such that after the offline the given device is guaranteed to be not used until online. We have that for CPU cores, for example, and user space can do it via /sys/devices/system/cpu/cpuX/online . So, why don't we make the online set the no_eject flag (under the lock as appropriate) and the offline clear it? And why don't we define such online and offline for all of the other system stuff, like memory, PCI host bridges etc. and make it behave analogously? Then, it is quite simple to say which devices should use the no_eject flag: devices that have online and offline exported to user space. And guess who's responsible for offlining all of those things before trying to eject them: user space is. From the kernel's point of view it is all clear. Hands clean. :-) Now, there's a different problem how to expose all of the relevant information to user space so that it knows what to offline for the specific eject operation to succeed, but that's kind of separate and worth addressing anyway. So, the idea is to run a user space program that off-lines all relevant devices before trimming ACPI devices. Is that right? That sounds like a worth idea to consider with. This basically moves the sequencer part into user space instead of the kernel space in my proposal. I agree that how to expose all of the relevant info to user space is an issue. Also, we will need to make sure that the user program always runs per a kernel request and then informs a result back to the kernel, so that the kernel can do the rest of an operation and inform a result to FW
Re: [RFC PATCH v2 01/12] Add sys_hotplug.h for system device hotplug framework
On Tue, Feb 05, 2013 at 12:52:30AM +0100, Rafael J. Wysocki wrote: You'd probably never try to hot-remove a disk before unmounting filesystems mounted from it or failing it as a RAID component and nobody sane wants the kernel to do things like that automatically when the user presses the eject button. In my opinion we should treat memory eject, or CPU package eject, or PCI host bridge eject in exactly the same way: Don't eject if it is not prepared for ejecting in the first place. Bad example, we have disks hot-removed all the time without any filesystems being unmounted, and have supported this since the 2.2 days (although we didn't get it right until 2.6.) PCI Host bridge eject is the same as PCI eject today, the user asks us to do it, and we can not fail it from happening. We also can have them removed without us being told about it in the first place, and can properly clean up from it all. And if you think about it, that makes things *massively* simpler, because now the kernel doesn't heed to worry about all of those synchronous removal scenarions that very well may involve every single device in the system and the whole problem is nicely split into several separate implement offline/online problems that are subsystem-specific and a single eject if everything relevant is offline problem which is kind of trivial. Plus the one of exposing information to user space, which is separate too. Now, each of them can be worked on separately, *tested* separately and debugged separately if need be and it is much easier to isolate failures and so on. So you are agreeing with me in that we can not fail hot removing any device, nice :) greg k-h ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH v2 01/12] Add sys_hotplug.h for system device hotplug framework
On Monday, February 04, 2013 04:04:47 PM Greg KH wrote: On Tue, Feb 05, 2013 at 12:52:30AM +0100, Rafael J. Wysocki wrote: You'd probably never try to hot-remove a disk before unmounting filesystems mounted from it or failing it as a RAID component and nobody sane wants the kernel to do things like that automatically when the user presses the eject button. In my opinion we should treat memory eject, or CPU package eject, or PCI host bridge eject in exactly the same way: Don't eject if it is not prepared for ejecting in the first place. Bad example, we have disks hot-removed all the time without any filesystems being unmounted, and have supported this since the 2.2 days (although we didn't get it right until 2.6.) Well, that wasn't my point. My point was that we have tools for unmounting filesystems from disks that the user wants to hot-remove and the user is supposed to use those tools before hot-removing the disks. At least I wouldn't recommend anyone to do otherwise. :-) Now, for memory hot-removal we don't have anything like that, as far as I can say, so my point was why don't we add memory offline that can be done and tested separately from hot-removal and use that before we go and hot-remove stuff? And analogously for PCI host bridges etc.? [Now, there's a question if an eject button on the system case, if there is one, should *always* cause the eject to happen even though things are not offline. My opinion is that not necessarily, because users may not be aware that they are doing something wrong. Quite analogously, does the power button always cause the system to shut down? No. So why the heck should an eject button always cause an eject to happen? I see no reason. That said, the most straightforward approach may be simply to let user space disable eject events for specific devices when it wants and only enable them when it knows that the given devices are ready for removal. But I'm digressing.] PCI Host bridge eject is the same as PCI eject today, the user asks us to do it, and we can not fail it from happening. We also can have them removed without us being told about it in the first place, and can properly clean up from it all. Well, are you sure we'll always clean up? I kind of have my doubts. :-) And if you think about it, that makes things *massively* simpler, because now the kernel doesn't heed to worry about all of those synchronous removal scenarions that very well may involve every single device in the system and the whole problem is nicely split into several separate implement offline/online problems that are subsystem-specific and a single eject if everything relevant is offline problem which is kind of trivial. Plus the one of exposing information to user space, which is separate too. Now, each of them can be worked on separately, *tested* separately and debugged separately if need be and it is much easier to isolate failures and so on. So you are agreeing with me in that we can not fail hot removing any device, nice :) That depends on how you define hot-removing. If you regard the offline as a separate operation that can be carried out independently and hot-remove as the last step causing the device to actually go away, then I agree that it can't fail. The offline itself, however, is a different matter (pretty much like unmounting a file system). Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH v2 01/12] Add sys_hotplug.h for system device hotplug framework
On Tue, 2013-02-05 at 00:52 +0100, Rafael J. Wysocki wrote: On Monday, February 04, 2013 03:13:29 PM Toshi Kani wrote: On Mon, 2013-02-04 at 21:07 +0100, Rafael J. Wysocki wrote: On Monday, February 04, 2013 06:33:52 AM Greg KH wrote: On Mon, Feb 04, 2013 at 03:21:22PM +0100, Rafael J. Wysocki wrote: On Monday, February 04, 2013 04:48:10 AM Greg KH wrote: On Sun, Feb 03, 2013 at 09:44:39PM +0100, Rafael J. Wysocki wrote: Yes, but those are just remove events and we can only see how destructive they were after the removal. The point is to be able to figure out whether or not we *want* to do the removal in the first place. Say you have a computing node which signals a hardware problem in a processor package (the container with CPU cores, memory, PCI host bridge etc.). You may want to eject that package, but you don't want to kill the system this way. So if the eject is doable, it is very much desirable to do it, but if it is not doable, you'd rather shut the box down and do the replacement afterward. That may be costly, however (maybe weeks of computations), so it should be avoided if possible, but not at the expense of crashing the box if the eject doesn't work out. It seems to me that we could handle that with the help of a new flag, say no_eject, in struct device, a global mutex, and a function that will walk the given subtree of the device hierarchy and check if no_eject is set for any devices in there. Plus a global no_eject switch, perhaps. I think this will always be racy, or at worst, slow things down on normal device operations as you will always be having to grab this flag whenever you want to do something new. I don't see why this particular scheme should be racy, at least I don't see any obvious races in it (although I'm not that good at races detection in general, admittedly). Also, I don't expect that flag to be used for everything, just for things known to seriously break if forcible eject is done. That may be not precise enough, so that's a matter of defining its purpose more precisely. We can do something like that on the ACPI level (ie. introduce a no_eject flag in struct acpi_device and provide an iterface for the layers above ACPI to manipulate it) but then devices without ACPI namespace objects won't be covered. That may not be a big deal, though. So say dev is about to be used for something incompatible with ejecting, so to speak. Then, one would do platform_lock_eject(dev), which would check if dev has an ACPI handle and then take acpi_eject_lock (if so). The return value of platform_lock_eject(dev) would need to be checked to see if the device is not gone. If it returns success (0), one would do something to the device and call platform_no_eject(dev) and then platform_unlock_eject(dev). How does a device know it is doing something that is incompatible with ejecting? That's a non-trivial task from what I can tell. I agree that this is complicated in general. But. There are devices known to have software offline and online operations such that after the offline the given device is guaranteed to be not used until online. We have that for CPU cores, for example, and user space can do it via /sys/devices/system/cpu/cpuX/online . So, why don't we make the online set the no_eject flag (under the lock as appropriate) and the offline clear it? And why don't we define such online and offline for all of the other system stuff, like memory, PCI host bridges etc. and make it behave analogously? Then, it is quite simple to say which devices should use the no_eject flag: devices that have online and offline exported to user space. And guess who's responsible for offlining all of those things before trying to eject them: user space is. From the kernel's point of view it is all clear. Hands clean. :-) Now, there's a different problem how to expose all of the relevant information to user space so that it knows what to offline for the specific eject operation to succeed, but that's kind of separate and worth addressing anyway. So, the idea is to run a user space program that off-lines all relevant devices before trimming ACPI devices. Is that right? That sounds like a worth idea to consider with. This basically moves the sequencer part into user space instead of the kernel space in my proposal. I agree that how to expose all of the relevant info to user space is an issue. Also, we will need
[PATCH 3/4] KVM: PPC: Book3S HV: Preserve guest CFAR register value
The CFAR (Come-From Address Register) is a useful debugging aid that
exists on POWER7 processors. Currently HV KVM doesn't save or restore
the CFAR register for guest vcpus, making the CFAR of limited use in
guests.
This adds the necessary code to capture the CFAR value saved in the
early exception entry code (it has to be saved before any branch is
executed), save it in the vcpu.arch struct, and restore it on entry
to the guest.
Signed-off-by: Paul Mackerras pau...@samba.org
---
arch/powerpc/include/asm/exception-64s.h |8 ++--
arch/powerpc/include/asm/kvm_book3s_asm.h |3 +++
arch/powerpc/include/asm/kvm_host.h |1 +
arch/powerpc/kernel/asm-offsets.c |5 +
arch/powerpc/kvm/book3s_hv_rmhandlers.S |9 +
5 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/exception-64s.h
b/arch/powerpc/include/asm/exception-64s.h
index 4dfc515..05e6d2e 100644
--- a/arch/powerpc/include/asm/exception-64s.h
+++ b/arch/powerpc/include/asm/exception-64s.h
@@ -199,10 +199,14 @@ END_FTR_SECTION_NESTED(ftr,ftr,943)
#define __KVM_HANDLER(area, h, n) \
do_kvm_##n:\
+ BEGIN_FTR_SECTION_NESTED(947) \
+ ld r10,area+EX_CFAR(r13); \
+ std r10,HSTATE_CFAR(r13); \
+ END_FTR_SECTION_NESTED(CPU_FTR_CFAR,CPU_FTR_CFAR,947); \
ld r10,area+EX_R10(r13); \
- stw r9,HSTATE_SCRATCH1(r13);\
+ stw r9,HSTATE_SCRATCH1(r13);\
ld r9,area+EX_R9(r13); \
- std r12,HSTATE_SCRATCH0(r13); \
+ std r12,HSTATE_SCRATCH0(r13); \
li r12,n; \
b kvmppc_interrupt
diff --git a/arch/powerpc/include/asm/kvm_book3s_asm.h
b/arch/powerpc/include/asm/kvm_book3s_asm.h
index 88609b2..cdc3d27 100644
--- a/arch/powerpc/include/asm/kvm_book3s_asm.h
+++ b/arch/powerpc/include/asm/kvm_book3s_asm.h
@@ -93,6 +93,9 @@ struct kvmppc_host_state {
u64 host_dscr;
u64 dec_expires;
#endif
+#ifdef CONFIG_PPC_BOOK3S_64
+ u64 cfar;
+#endif
};
struct kvmppc_book3s_shadow_vcpu {
diff --git a/arch/powerpc/include/asm/kvm_host.h
b/arch/powerpc/include/asm/kvm_host.h
index ca9bf45..03d7bea 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -440,6 +440,7 @@ struct kvm_vcpu_arch {
ulong uamor;
u32 ctrl;
ulong dabr;
+ ulong cfar;
#endif
u32 vrsave; /* also USPRG0 */
u32 mmucr;
diff --git a/arch/powerpc/kernel/asm-offsets.c
b/arch/powerpc/kernel/asm-offsets.c
index e39ca55..9a73fb0 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -475,6 +475,7 @@ int main(void)
DEFINE(VCPU_LAST_INST, offsetof(struct kvm_vcpu, arch.last_inst));
DEFINE(VCPU_TRAP, offsetof(struct kvm_vcpu, arch.trap));
DEFINE(VCPU_PTID, offsetof(struct kvm_vcpu, arch.ptid));
+ DEFINE(VCPU_CFAR, offsetof(struct kvm_vcpu, arch.cfar));
DEFINE(VCORE_ENTRY_EXIT, offsetof(struct kvmppc_vcore,
entry_exit_count));
DEFINE(VCORE_NAP_COUNT, offsetof(struct kvmppc_vcore, nap_count));
DEFINE(VCORE_IN_GUEST, offsetof(struct kvmppc_vcore, in_guest));
@@ -554,6 +555,10 @@ int main(void)
DEFINE(IPI_PRIORITY, IPI_PRIORITY);
#endif /* CONFIG_KVM_BOOK3S_64_HV */
+#ifdef CONFIG_PPC_BOOK3S_64
+ HSTATE_FIELD(HSTATE_CFAR, cfar);
+#endif /* CONFIG_PPC_BOOK3S_64 */
+
#else /* CONFIG_PPC_BOOK3S */
DEFINE(VCPU_CR, offsetof(struct kvm_vcpu, arch.cr));
DEFINE(VCPU_XER, offsetof(struct kvm_vcpu, arch.xer));
diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
index 10b6c35..e33d11f 100644
--- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
+++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
@@ -539,6 +539,11 @@ fast_guest_return:
/* Enter guest */
+BEGIN_FTR_SECTION
+ ld r5, VCPU_CFAR(r4)
+ mtspr SPRN_CFAR, r5
+END_FTR_SECTION_IFSET(CPU_FTR_CFAR)
+
ld r5, VCPU_LR(r4)
lwz r6, VCPU_CR(r4)
mtlrr5
@@ -604,6 +609,10 @@ kvmppc_interrupt:
lwz r4, HSTATE_SCRATCH1(r13)
std r3, VCPU_GPR(R12)(r9)
stw r4, VCPU_CR(r9)
+BEGIN_FTR_SECTION
+ ld r3, HSTATE_CFAR(r13)
+ std r3, VCPU_CFAR(r9)
+END_FTR_SECTION_IFSET(CPU_FTR_CFAR)
/* Restore R1/R2 so we can handle faults */
ld r1, HSTATE_HOST_R1(r13)
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
[PATCH 0/4] Improve CFAR handling
The CFAR (Come From Address Register) is useful for debugging; it records the address of the most recent taken branch or rfid instructions. At present, KVM doesn't even try to context switch it, and the first-level interrupt handlers for some interrupts have a branch before it gets saved, which will corrupt it. This series fixes the interrupt handlers to not corrupt the CFAR, and makes KVM context-switch it. The series is against Ben H.'s next branch. The last patch in the series corrects a compile error for 32-bit PR KVM configs which was introduced by an earlier commit in Ben's next branch. I suggest this series should go via Ben's tree rather than the KVM tree, since most of the changes are to core powerpc interrupt handling code. Alex, if you could ack patch 3/4 that would be helpful. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/4] powerpc: Save CFAR before branching in interrupt entry paths
Some of the interrupt vectors on 64-bit POWER server processors are only 32 bytes long, which is not enough for the full first-level interrupt handler. For these we currently just have a branch to an out-of-line handler. However, this means that we corrupt the CFAR (come-from address register) on POWER7 and later processors. To fix this, we split the EXCEPTION_PROLOG_1 macro into two pieces: EXCEPTION_PROLOG_0 contains the part up to the point where the CFAR is saved in the PACA, and EXCEPTION_PROLOG_1 contains the rest. We then put EXCEPTION_PROLOG_0 in the short interrupt vectors before we branch to the out-of-line handler, which contains the rest of the first-level interrupt handler. To facilitate this, we define new _OOL (out of line) variants of STD_EXCEPTION_PSERIES, etc. In order to get EXCEPTION_PROLOG_0 to be short enough, i.e., no more than 6 instructions, it was necessary to move the stores that move the PPR and CFAR values into the PACA into __EXCEPTION_PROLOG_1 and to get rid of one of the two HMT_MEDIUM instructions. Previously there was a HMT_MEDIUM_PPR_DISCARD before the prolog, which was nop'd out on processors with the PPR (POWER7 and later), and then another HMT_MEDIUM inside the HMT_MEDIUM_PPR_SAVE macro call inside __EXCEPTION_PROLOG_1, which was nop'd out on processors without PPR. Now the HMT_MEDIUM inside EXCEPTION_PROLOG_0 is there unconditionally and the HMT_MEDIUM_PPR_DISCARD is not strictly necessary, although this leaves it in for the interrupt vectors where there is room for it. Previously we had a handler for hypervisor maintenance interrupts at 0xe50, which doesn't leave enough room for the vector for hypervisor emulation assist interrupts at 0xe40, since we need 8 instructions. The 0xe50 vector was only used on POWER6, as the HMI vector was moved to 0xe60 on POWER7. Since we don't support running in hypervisor mode on POWER6, we just remove the handler at 0xe50. This also changes denorm_exception_hv to use EXCEPTION_PROLOG_0 instead of open-coding it, and removes the HMT_MEDIUM_PPR_DISCARD from the relocation-on vectors (since any CPU that supports relocation-on interrupts also has the PPR). Signed-off-by: Paul Mackerras pau...@samba.org --- arch/powerpc/include/asm/exception-64s.h | 84 +- arch/powerpc/kernel/exceptions-64s.S | 95 -- 2 files changed, 133 insertions(+), 46 deletions(-) diff --git a/arch/powerpc/include/asm/exception-64s.h b/arch/powerpc/include/asm/exception-64s.h index 370298a..4dfc515 100644 --- a/arch/powerpc/include/asm/exception-64s.h +++ b/arch/powerpc/include/asm/exception-64s.h @@ -50,7 +50,7 @@ #define EX_PPR 88 /* SMT thread status register (priority) */ #ifdef CONFIG_RELOCATABLE -#define EXCEPTION_RELON_PROLOG_PSERIES_1(label, h) \ +#define __EXCEPTION_RELON_PROLOG_PSERIES_1(label, h) \ ld r12,PACAKBASE(r13); /* get high part of label */ \ mfspr r11,SPRN_##h##SRR0; /* save SRR0 */ \ LOAD_HANDLER(r12,label);\ @@ -61,13 +61,15 @@ blr; #else /* If not relocatable, we can jump directly -- and save messing with LR */ -#define EXCEPTION_RELON_PROLOG_PSERIES_1(label, h) \ +#define __EXCEPTION_RELON_PROLOG_PSERIES_1(label, h) \ mfspr r11,SPRN_##h##SRR0; /* save SRR0 */ \ mfspr r12,SPRN_##h##SRR1; /* and SRR1 */ \ li r10,MSR_RI; \ mtmsrd r10,1; /* Set RI (EE=0) */ \ b label; #endif +#define EXCEPTION_RELON_PROLOG_PSERIES_1(label, h) \ + __EXCEPTION_RELON_PROLOG_PSERIES_1(label, h)\ /* * As EXCEPTION_PROLOG_PSERIES(), except we've already got relocation on @@ -75,6 +77,7 @@ * case EXCEPTION_RELON_PROLOG_PSERIES_1 will be using lr. */ #define EXCEPTION_RELON_PROLOG_PSERIES(area, label, h, extra, vec) \ + EXCEPTION_PROLOG_0(area); \ EXCEPTION_PROLOG_1(area, extra, vec); \ EXCEPTION_RELON_PROLOG_PSERIES_1(label, h) @@ -135,25 +138,32 @@ BEGIN_FTR_SECTION_NESTED(942) \ END_FTR_SECTION_NESTED(CPU_FTR_HAS_PPR,0,942) /*non P7*/ /* - * Save PPR in paca whenever some register is available to use. - * Then increase the priority. + * Get an SPR into a register if the CPU has the given feature */ -#define HMT_MEDIUM_PPR_SAVE(area, ra) \ +#define OPT_GET_SPR(ra, spr, ftr) \ BEGIN_FTR_SECTION_NESTED(943) \ - mfspr ra,SPRN_PPR;\ - std
[PATCH 4/4] KVM: PPC: Book3S PR: Fix compilation on 32-bit machines
Commit a413f474a0 (powerpc: Disable relocation on exceptions whenever PR KVM is active) added calls to pSeries_disable_reloc_on_exc() and pSeries_enable_reloc_on_exc() to book3s_pr.c, and added declarations of those functions to asm/hvcall.h, but didn't add an include of asm/hvcall.h to book3s_pr.c. 64-bit kernels seem to get hvcall.h included via some other path, but 32-bit kernels fail to compile with: arch/powerpc/kvm/book3s_pr.c: In function ‘kvmppc_core_init_vm’: arch/powerpc/kvm/book3s_pr.c:1300:4: error: implicit declaration of function ‘pSeries_disable_reloc_on_exc’ [-Werror=implicit-function-declaration] arch/powerpc/kvm/book3s_pr.c: In function ‘kvmppc_core_destroy_vm’: arch/powerpc/kvm/book3s_pr.c:1316:4: error: implicit declaration of function ‘pSeries_enable_reloc_on_exc’ [-Werror=implicit-function-declaration] cc1: all warnings being treated as errors make[2]: *** [arch/powerpc/kvm/book3s_pr.o] Error 1 make[1]: *** [arch/powerpc/kvm] Error 2 make: *** [sub-make] Error 2 This fixes it by adding an include of hvcall.h. Signed-off-by: Paul Mackerras pau...@samba.org --- arch/powerpc/kvm/book3s_pr.c |1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c index 67e4708..6702442 100644 --- a/arch/powerpc/kvm/book3s_pr.c +++ b/arch/powerpc/kvm/book3s_pr.c @@ -35,6 +35,7 @@ #include asm/mmu_context.h #include asm/switch_to.h #include asm/firmware.h +#include asm/hvcall.h #include linux/gfp.h #include linux/sched.h #include linux/vmalloc.h -- 1.7.10.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/4] powerpc: Remove Cell-specific relocation-on interrupt vector code
The Cell processor doesn't support relocation-on interrupts, so we don't need relocation-on versions of the interrupt vectors that are purely Cell-specific. This removes them. Signed-off-by: Paul Mackerras pau...@samba.org --- arch/powerpc/kernel/exceptions-64s.S | 10 -- 1 file changed, 10 deletions(-) diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S index 7a1c87c..dc64165 100644 --- a/arch/powerpc/kernel/exceptions-64s.S +++ b/arch/powerpc/kernel/exceptions-64s.S @@ -817,26 +817,16 @@ vsx_unavailable_relon_pSeries_1: . = 0x4f40 b vsx_unavailable_relon_pSeries -#ifdef CONFIG_CBE_RAS - STD_RELON_EXCEPTION_HV(0x5200, 0x1202, cbe_system_error) -#endif /* CONFIG_CBE_RAS */ STD_RELON_EXCEPTION_PSERIES(0x5300, 0x1300, instruction_breakpoint) #ifdef CONFIG_PPC_DENORMALISATION . = 0x5500 b denorm_exception_hv #endif -#ifdef CONFIG_CBE_RAS - STD_RELON_EXCEPTION_HV(0x5600, 0x1602, cbe_maintenance) -#else #ifdef CONFIG_HVC_SCOM STD_RELON_EXCEPTION_HV(0x5600, 0x1600, maintence_interrupt) KVM_HANDLER_SKIP(PACA_EXGEN, EXC_HV, 0x1600) #endif /* CONFIG_HVC_SCOM */ -#endif /* CONFIG_CBE_RAS */ STD_RELON_EXCEPTION_PSERIES(0x5700, 0x1700, altivec_assist) -#ifdef CONFIG_CBE_RAS - STD_RELON_EXCEPTION_HV(0x5800, 0x1802, cbe_thermal) -#endif /* CONFIG_CBE_RAS */ /* Other future vectors */ .align 7 -- 1.7.10.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/3] powerpc/mpc512x: fix noderef sparse warnings
Fix:
warning: dereference of noderef expression
Signed-off-by: Anatolij Gustschin ag...@denx.de
---
arch/powerpc/platforms/512x/clock.c | 18 +-
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/platforms/512x/clock.c
b/arch/powerpc/platforms/512x/clock.c
index 7937361..8a784d4 100644
--- a/arch/powerpc/platforms/512x/clock.c
+++ b/arch/powerpc/platforms/512x/clock.c
@@ -184,7 +184,7 @@ static unsigned long spmf_mult(void)
36, 40, 44, 48,
52, 56, 60, 64
};
- int spmf = (clockctl-spmr 24) 0xf;
+ int spmf = (in_be32(clockctl-spmr) 24) 0xf;
return spmf_to_mult[spmf];
}
@@ -206,7 +206,7 @@ static unsigned long sysdiv_div_x_2(void)
52, 56, 58, 62,
60, 64, 66,
};
- int sysdiv = (clockctl-scfr2 26) 0x3f;
+ int sysdiv = (in_be32(clockctl-scfr2) 26) 0x3f;
return sysdiv_to_div_x_2[sysdiv];
}
@@ -230,7 +230,7 @@ static unsigned long sys_to_ref(unsigned long rate)
static long ips_to_ref(unsigned long rate)
{
- int ips_div = (clockctl-scfr1 23) 0x7;
+ int ips_div = (in_be32(clockctl-scfr1) 23) 0x7;
rate *= ips_div;/* csb_clk = ips_clk * ips_div */
rate *= 2; /* sys_clk = csb_clk * 2 */
@@ -284,7 +284,7 @@ static struct clk sys_clk = {
static void diu_clk_calc(struct clk *clk)
{
- int diudiv_x_2 = clockctl-scfr1 0xff;
+ int diudiv_x_2 = in_be32(clockctl-scfr1) 0xff;
unsigned long rate;
rate = sys_clk.rate;
@@ -311,7 +311,7 @@ static void half_clk_calc(struct clk *clk)
static void generic_div_clk_calc(struct clk *clk)
{
- int div = (clockctl-scfr1 clk-div_shift) 0x7;
+ int div = (in_be32(clockctl-scfr1) clk-div_shift) 0x7;
clk-rate = clk-parent-rate / div;
}
@@ -329,7 +329,7 @@ static struct clk csb_clk = {
static void e300_clk_calc(struct clk *clk)
{
- int spmf = (clockctl-spmr 16) 0xf;
+ int spmf = (in_be32(clockctl-spmr) 16) 0xf;
int ratex2 = clk-parent-rate * spmf;
clk-rate = ratex2 / 2;
@@ -648,12 +648,12 @@ static void psc_calc_rate(struct clk *clk, int pscnum,
struct device_node *np)
out_be32(clockctl-pccr[pscnum], 0x0002);
out_be32(clockctl-pccr[pscnum], 0x0003);
- if (clockctl-pccr[pscnum] 0x80) {
+ if (in_be32(clockctl-pccr[pscnum]) 0x80) {
clk-rate = spdif_rxclk.rate;
return;
}
- switch ((clockctl-pccr[pscnum] 14) 0x3) {
+ switch ((in_be32(clockctl-pccr[pscnum]) 14) 0x3) {
case 0:
mclk_src = sys_clk.rate;
break;
@@ -668,7 +668,7 @@ static void psc_calc_rate(struct clk *clk, int pscnum,
struct device_node *np)
break;
}
- mclk_div = ((clockctl-pccr[pscnum] 17) 0x7fff) + 1;
+ mclk_div = ((in_be32(clockctl-pccr[pscnum]) 17) 0x7fff) + 1;
clk-rate = mclk_src / mclk_div;
}
--
1.7.5.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/3] powerpc/mpc512x: fix sparce warnings for non static symbols
Fix warnings:
symbol 'clockctl' was not declared. Should it be static?
symbol 'rate_clks' was not declared. Should it be static?
symbol 'dev_clks' was not declared. Should it be static?
symbol 'mpc5121_clk_init' was not declared. Should it be static?
Signed-off-by: Anatolij Gustschin ag...@denx.de
---
arch/powerpc/include/asm/mpc5121.h |1 +
arch/powerpc/platforms/512x/clock.c |7 ---
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/mpc5121.h
b/arch/powerpc/include/asm/mpc5121.h
index e700c8b..1b0ce6d 100644
--- a/arch/powerpc/include/asm/mpc5121.h
+++ b/arch/powerpc/include/asm/mpc5121.h
@@ -147,5 +147,6 @@ struct mpc512x_axe_module {
int mpc512x_cs_config(int cs, u32 val);
+int __init mpc5121_clk_init(void);
#endif /* __ASM_POWERPC_MPC5121_H__ */
diff --git a/arch/powerpc/platforms/512x/clock.c
b/arch/powerpc/platforms/512x/clock.c
index 8a784d4..52d57d2 100644
--- a/arch/powerpc/platforms/512x/clock.c
+++ b/arch/powerpc/platforms/512x/clock.c
@@ -26,6 +26,7 @@
#include linux/of_platform.h
#include asm/mpc5xxx.h
+#include asm/mpc5121.h
#include asm/clk_interface.h
#undef CLK_DEBUG
@@ -122,7 +123,7 @@ struct mpc512x_clockctl {
u32 dccr; /* DIU Clk Cnfg Reg */
};
-struct mpc512x_clockctl __iomem *clockctl;
+static struct mpc512x_clockctl __iomem *clockctl;
static int mpc5121_clk_enable(struct clk *clk)
{
@@ -551,7 +552,7 @@ static struct clk ac97_clk = {
.calc = ac97_clk_calc,
};
-struct clk *rate_clks[] = {
+static struct clk *rate_clks[] = {
ref_clk,
sys_clk,
diu_clk,
@@ -607,7 +608,7 @@ static void rate_clks_init(void)
* There are two clk enable registers with 32 enable bits each
* psc clocks and device clocks are all stored in dev_clks
*/
-struct clk dev_clks[2][32];
+static struct clk dev_clks[2][32];
/*
* Given a psc number return the dev_clk
--
1.7.5.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 3/3] powerpc/mpc5xxx: fix sparse warning for non static symbol
Fix warning:
symbol 'mpc5xxx_get_bus_frequency' was not declared. Should it be static?
Signed-off-by: Anatolij Gustschin ag...@denx.de
---
arch/powerpc/sysdev/mpc5xxx_clocks.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/sysdev/mpc5xxx_clocks.c
b/arch/powerpc/sysdev/mpc5xxx_clocks.c
index 96f815a..5492dc5 100644
--- a/arch/powerpc/sysdev/mpc5xxx_clocks.c
+++ b/arch/powerpc/sysdev/mpc5xxx_clocks.c
@@ -9,9 +9,9 @@
#include linux/kernel.h
#include linux/of_platform.h
#include linux/export.h
+#include asm/mpc5xxx.h
-unsigned int
-mpc5xxx_get_bus_frequency(struct device_node *node)
+unsigned long mpc5xxx_get_bus_frequency(struct device_node *node)
{
struct device_node *np;
const unsigned int *p_bus_freq = NULL;
--
1.7.5.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
