Re: [PATCH V2 06/12] selftests, powerpc: Add test for system wide DSCR default
On Wed, Jan 14, 2015 at 10:44:31AM +1100, Michael Ellerman wrote: > > Also, I would like to see the test results reports using > > kselftest.h - it can be separate patch in the interest of > > getting tests in. > > Sorry but kselftest.h doesn't do anything useful for us. > > We have existing test reporting that uses the subunit protocol. > > I'm happy to convert that to TAP, or some other well defined output format, > but > not to something ad-hoc like kselftest.h currently provides. Something TAP-alike would also help reduce some of the spew from tests that are going to fail. eg, running execveat tests on a kernel that doesn't implement that syscall currently spews around 20 lines of [FAIL]. Adding something to the beginning of the test to set plan() accordingly if it detects -ENOSYS could make that output a little cleaner. That other projects (like jenkins, bug trackers etc) could consume the output of the test runs would be a nice bonus. I only recently started looking at kselftests and was surprised at the amount of variance we have in the way of printing 'Ok' '[OK]' 'ok...' etc. Dave ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [linux-pm] [PATCH -v4 6/6] fault-injection: add notifier error injection testing scripts
On Tue, Jun 26, 2012 at 04:31:47PM -0700, Andrew Morton wrote: > My overall take on the fault-injection code is that there has been a > disappointing amount of uptake: I don't see many developers using them > for whitebox testing their stuff. I guess this patchset addresses > that, in a way. I added support for make-it-fail to my syscall fuzzer a while ago. (if the file exists, the child processes set it before calling the fuzzed syscall). I've not had a chance to really play with it, because I find enough problems already even without it. Dave ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] misc: add CARMA DATA-FPGA Access Driver
On Tue, Feb 08, 2011 at 09:20:46AM -0800, Ira W. Snyder wrote: > > > +static DEVICE_ATTR(enable, S_IWUGO | S_IRUGO, data_en_show, > > > data_en_set); > > > > Are all of these really needed or most of them are for debug? > > > > Most are for debugging. They have proved useful a few times in > production to track down bugs. File mode should probably not be world writable. (checkpatch.pl should warn you about this now btw) Dave ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Add cpufreq driver for Momentum Maple boards
On Fri, Jun 17, 2011 at 03:12:56PM +0400, Dmitry Eremin-Solenikov wrote: > What about drivers/cpufreq/powerpc, or it's an unnecessary? We haven't done it so far for x86 & arm, so for now at least, just keeping them in drivers/cpufreq/ should be sufficient. > Should I resumbit it, or there will be massive arch/powerpc -> > drivers/cpufreq move? Good question. I haven't heard anything from any of the PPC maintainers on this subject, but I'll be happy to help out where I can if they decide to follow suit with x86/arm. Dave ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] Add cpufreq driver for Momentum Maple boards
On Wed, Jun 29, 2011 at 01:28:30PM +1000, Ben Herrenschmidt wrote: > Before I comment on this last one, a quick Q. for Dave: Do you want to > handle this or should I merge it via powerpc.git ? (It depends on > another change to the arch code to expose the SCOM functions that it > uses, and that patch is going to be in my -next branch). If you're carrying the dependancy, it sounds like it would make more sense for you to carry this too. There are some changes to the Kconfig/Makefile in drivers/cpufreq in my tree for 3.1 already, so you might get a collision when both trees end up in next & subsequently Linus' tree. Just trivial changes though. > > --- > > drivers/cpufreq/Kconfig |5 + > > drivers/cpufreq/Kconfig.powerpc |7 + > > drivers/cpufreq/Makefile|5 + > > drivers/cpufreq/maple-cpufreq.c | 314 > > +++ > > If we're going to have a Kconfig.powerpc, should we maybe just have a > powerpc subdirectory instead with the driver in it ? > > I'm happy at some later point to try moving some of my other ones there. So far we haven't bothered with additional subarch drivers/ directories for x86/arm. I'm not against the idea. As more archs move over, I could see drivers/cpufreq/ getting more cluttered. Dave ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] Add cpufreq driver for Momentum Maple boards
On Thu, Jun 30, 2011 at 01:23:03PM -0500, kevin diggs wrote: > Hi, > > On Wed, Jun 29, 2011 at 3:58 PM, Dmitry Eremin-Solenikov > wrote: > > > > drivers/cpufreq/powerpc. However my current version (as suggested by Ben) > > goes directly to drivers/cpufreq > > > Uh ... Just curious ... why is arch specific code now being put > outside of the arch directories? When I wrote the 750GX stuff > (~2.6.28) I put in a location similar to what x86 was doing? When did > this change? last release, ARM moved their cpufreq drivers. I moved the x86 ones afterwards. There's precedent for other arch specific drivers in drivers/ too, but the cpufreq move is a recent thing. Dave ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: cpu frequency governor regression (?)
On Tue, Dec 11, 2007 at 07:52:45PM +0100, Johannes Berg wrote: > Hi, > > No idea who to bother with this and maybe it's just a > misconfiguration... Apologies if my guesses are totally wrong. > > I'm currently on 2.6.24-rc3 (+wireless-2.6#everything) but couldn't find > any patches between that and 2.6.24-rc5 that seemed relevant. > > On my quad powermac, I'm seeing the cpufreq governor changed by a > hibernation cycle. My default governor is "userspace", which is driven > by powernowd (because the latency is too high "ondemand" doesn't like my > machine) but after a hibernation cycle I'm having the governor set to > "performance". bizarre. It should default back to whatever CONFIG_CPU_FREQ_DEFAULT_* option was set. (Arguably a bug in itself, as we don't track & restore them on resume, so if you changed from the default after booting: splat) Why you're getting the performance governor is puzzling though. Can you enable CONFIG_CPU_FREQ_DEBUG=y, and boot with cpufreq.debug=7 and send the log from a transition across hibernate? Also, does /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor have performance in *all* the cpus? Dave -- http://www.codemonkey.org.uk ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] ehea: kdump support using new shutdown hook
On Wed, Dec 12, 2007 at 05:53:43PM +0100, Thomas Klein wrote:
> +static void ehea_update_adapter_handles(struct ehea_adapter *adapter)
> +{
> +int i, k;
> +int j = 0;
> +
> +memset(adapter->res_handles, sizeof(adapter->res_handles), 0);
arguments wrong way around.
Dave
--
http://www.codemonkey.org.uk
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc/cell/cpufreq: add spu aware cpufreq governor
On Mon, Jul 07, 2008 at 05:02:30PM +0200, Arnd Bergmann wrote: > From: Christian Krafft <[EMAIL PROTECTED]> > > This patch adds a cpufreq governor that takes the number of running spus > into account. It's very similar to the ondemand governor, but not as complex. > Instead of hacking spu load into the ondemand governor it might be easier to > have cpufreq accepting multiple governors per cpu in future. > Don't know if this is the right way, but it would keep the governors simple. > > Signed-off-by: Christian Krafft <[EMAIL PROTECTED]> > Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]> > --- > > Dave or other cpufreq people, can you take a look at this > and add an Acked-by when you're happy? It looks ok on a quick look through. I'm wondering about the multiple governors thing though. This came up at last years power management summit, but no-one has mentioned it since. I think it's possible we want to look at things like this in the future, and not just for cell. I keep hearing mumblings about future generations of x86's having dedicated coprocessors for certain tasks that may benefit from the same thing. > We have one prerequisite patch in the powerpc code (in spufs), > so should it get merged through powerpc.git? That's fine with me. Conflicts should be minimal if any at all, I've got nothing queued up which touches that part of Kconfig/Makefile One question I do have though, is how userspace scripts are supposed to know they're to echo cbe_spu_governor into the relevant parts of sysfs. I've not used anything with a cell. Do they expose the SPUs as regular CPUs, or do they show up in a different part of the tree? Dave -- http://www.codemonkey.org.uk ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc/cell/cpufreq: add spu aware cpufreq governor
On Tue, Jul 08, 2008 at 08:43:43AM +0200, Arnd Bergmann wrote: > On Monday 07 July 2008, Dave Jones wrote: > > One question I do have though, is how userspace scripts are supposed > > to know they're to echo cbe_spu_governor into the relevant parts of > > sysfs. I've not used anything with a cell. Do they expose the SPUs > > as regular CPUs, or do they show up in a different part of the tree? > > An SPU is very different from a CPU from the user perspective. > SPUs show up in /sys/devices/system/spus, and if a user wants to access > them, the "spufs" file system needs to be mounted in the system, by > convention on /spu. Ok, that should be fairly simple to write scripts for. All sounds good to me. Dave -- http://www.codemonkey.org.uk ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc/cell/cpufreq: add spu aware cpufreq governor
On Wed, Jul 09, 2008 at 01:41:38PM +1000, Ben Herrenschmidt wrote: > On Tue, 2008-07-08 at 11:27 -0400, Dave Jones wrote: > > On Tue, Jul 08, 2008 at 08:43:43AM +0200, Arnd Bergmann wrote: > > > On Monday 07 July 2008, Dave Jones wrote: > > > > One question I do have though, is how userspace scripts are supposed > > > > to know they're to echo cbe_spu_governor into the relevant parts of > > > > sysfs. I've not used anything with a cell. Do they expose the SPUs > > > > as regular CPUs, or do they show up in a different part of the tree? > > > > > > An SPU is very different from a CPU from the user perspective. > > > SPUs show up in /sys/devices/system/spus, and if a user wants to access > > > them, the "spufs" file system needs to be mounted in the system, by > > > convention on /spu. > > > > Ok, that should be fairly simple to write scripts for. > > All sounds good to me. > > Can I add your Acked-by ? Absolutely. ACKed-by: Dave Jones <[EMAIL PROTECTED]> Dave -- http://www.codemonkey.org.uk ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc/cell/cpufreq: add spu aware cpufreq governor
On Wed, Jul 09, 2008 at 03:18:59PM +1000, Ben Herrenschmidt wrote: > On Mon, 2008-07-07 at 17:02 +0200, Arnd Bergmann wrote: > > From: Christian Krafft <[EMAIL PROTECTED]> > > > > This patch adds a cpufreq governor that takes the number of running spus > > into account. It's very similar to the ondemand governor, but not as > > complex. > > Instead of hacking spu load into the ondemand governor it might be easier > > to > > have cpufreq accepting multiple governors per cpu in future. > > Don't know if this is the right way, but it would keep the governors > > simple. > > > > Signed-off-by: Christian Krafft <[EMAIL PROTECTED]> > > Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]> > > --- > > > > Dave or other cpufreq people, can you take a look at this > > and add an Acked-by when you're happy? > > > > We have one prerequisite patch in the powerpc code (in spufs), > > so should it get merged through powerpc.git? > > Hrm... taking whatever test config I have at hand, applying the patch > and doing make oldconfig & make, I get: > > ERROR: ".cpufreq_register_governor" > [arch/powerpc/platforms/cell/cbe_spu_governor.ko] undefined! > ERROR: ".__cpufreq_driver_target" > [arch/powerpc/platforms/cell/cbe_spu_governor.ko] undefined! > ERROR: ".cpufreq_unregister_governor" > [arch/powerpc/platforms/cell/cbe_spu_governor.ko] undefined! > ERROR: ".cpufreq_frequency_table_target" > [arch/powerpc/platforms/cell/cbe-cpufreq.ko] undefined! > ERROR: ".cpufreq_register_driver" > [arch/powerpc/platforms/cell/cbe-cpufreq.ko] undefined! > ERROR: ".cpufreq_frequency_table_verify" > [arch/powerpc/platforms/cell/cbe-cpufreq.ko] undefined! > ERROR: ".cpufreq_frequency_table_get_attr" > [arch/powerpc/platforms/cell/cbe-cpufreq.ko] undefined! > ERROR: ".cpufreq_notify_transition" > [arch/powerpc/platforms/cell/cbe-cpufreq.ko] undefined! > ERROR: ".cpufreq_frequency_table_cpuinfo" > [arch/powerpc/platforms/cell/cbe-cpufreq.ko] undefined! > ERROR: ".cpufreq_unregister_driver" > [arch/powerpc/platforms/cell/cbe-cpufreq.ko] undefined! > ERROR: ".cpufreq_frequency_table_put_attr" > [arch/powerpc/platforms/cell/cbe-cpufreq.ko] undefined! Does this help ? Dave diff --git a/arch/powerpc/platforms/cell/Kconfig b/arch/powerpc/platforms/cell/Kconfig index 3959fcf..19f4b4d 100644 --- a/arch/powerpc/platforms/cell/Kconfig +++ b/arch/powerpc/platforms/cell/Kconfig @@ -91,6 +91,7 @@ config CBE_THERM config CBE_CPUFREQ tristate "CBE frequency scaling" depends on CBE_RAS && CPU_FREQ + select CPU_FREQ_TABLE default m help This adds the cpufreq driver for Cell BE processors. -- http://www.codemonkey.org.uk ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [git pull] Please pull from powerpc.git merge branch
On Wed, Jul 16, 2008 at 11:34:03AM +1000, Ben Herrenschmidt wrote: > Linus, > > I apologize in advance for the couple of merge commits in there. I > merged your tree yesterday in order to fix a (fairly minor) conflict, > and waited for our autobuilder to test a whole bunch of configs > overnight before asking you to pull, at which point, sfr informed me of > a bunch of this time non-trivial conflicts with whatever you pulled in > the meantime... > > So here it is with 2 merge csets at the top, I'll try to do better next > time. I don't want to rebase or my sub-maintainers will hate me. > > So please pull from: > > git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge Boom! arch/powerpc/platforms/built-in.o: In function `ep8248e_mdio_probe': /builddir/build/BUILD/kernel-2.6.26/linux-2.6.26.ppc/arch/powerpc/platforms/82xx/ep8248e.c:129: undefined reference to `alloc_mdio_bitbang' /builddir/build/BUILD/kernel-2.6.26/linux-2.6.26.ppc/arch/powerpc/platforms/82xx/ep8248e.c:143: undefined reference to `mdiobus_register' .config is at http://davej.fedorapeople.org/kernel-2.6.27-ppc.config Dave -- http://www.codemonkey.org.uk ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/ep8248e: Fix compile problem if !CONFIG_FS_ENET
On Wed, Jul 16, 2008 at 04:47:23PM -0500, Scott Wood wrote: > On Wed, Jul 16, 2008 at 08:39:12AM -0500, Kumar Gala wrote: > > If we don't enable FS_ENET we get build issues: > > > > arch/powerpc/platforms/built-in.o: In function `ep8248e_mdio_probe': > > arch/powerpc/platforms/82xx/ep8248e.c:129: undefined reference to > > `alloc_mdio_bitbang' > > arch/powerpc/platforms/82xx/ep8248e.c:143: undefined reference to > > `mdiobus_register' > > How is this possible? CONFIG_EP8248E selects CONFIG_MDIO_BITBANG. If CONFIG_PHYLIB=m however, that doesn't make any difference, because vmlinuz is trying to use a symbol which now lives in a module. Dave -- http://www.codemonkey.org.uk ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/ep8248e: Fix compile problem if !CONFIG_FS_ENET
On Wed, Jul 16, 2008 at 05:10:29PM -0500, Kumar Gala wrote: > > On Jul 16, 2008, at 4:57 PM, Dave Jones wrote: > > > On Wed, Jul 16, 2008 at 04:47:23PM -0500, Scott Wood wrote: > >> On Wed, Jul 16, 2008 at 08:39:12AM -0500, Kumar Gala wrote: > >>> If we don't enable FS_ENET we get build issues: > >>> > >>> arch/powerpc/platforms/built-in.o: In function `ep8248e_mdio_probe': > >>> arch/powerpc/platforms/82xx/ep8248e.c:129: undefined reference to > >>> `alloc_mdio_bitbang' > >>> arch/powerpc/platforms/82xx/ep8248e.c:143: undefined reference to > >>> `mdiobus_register' > >> > >> How is this possible? CONFIG_EP8248E selects CONFIG_MDIO_BITBANG. > > > > If CONFIG_PHYLIB=m however, that doesn't make any difference, because > > vmlinuz is trying to use a symbol which now lives in a module. > > The mdiobus_register make sense, I'm not sure get why > alloc_mdio_bitbang is undefined. Erm, same reason. it's built into phy.o, which ends up in the module, not the vmlinuz. (also, it doesn't look like it's exported even if it was built-in?) Dave -- http://www.codemonkey.org.uk ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] serial: fix struct uart_info change fallout
On Tue, Jul 22, 2008 at 10:25:20AM +1000, Stephen Rothwell wrote: > Hi Linus, Alan, > > Today's linux-next (actually just Linus' tree) build (powerpc > ppc64_defconfig) failed like this: > > drivers/serial/serial_txx9.c: In function 'receive_chars': > drivers/serial/serial_txx9.c:275: error: 'struct uart_info' has no member > named 'tty' > drivers/serial/icom.c: In function 'recv_interrupt': > drivers/serial/icom.c:733: error: 'struct uart_info' has no member named > 'tty' That's the same pair of patches I sent earlier, which apparently were "Already in the ttydev tree" which should be in linux-next ? Dave -- http://www.codemonkey.org.uk ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: fsl_upm compile failure.
On Thu, Oct 09, 2008 at 03:02:19AM +0400, Anton Vorontsov wrote: > Hi, > > On Wed, Oct 08, 2008 at 06:28:15PM -0400, Dave Jones wrote: > > Hi Anton, > > I tried reenabling CONFIG_MTD_NAND_FSL_UPM in the Fedora kernel > > today (currently on 2.6.27-rc9-git1), and got the error below. > > > > ERROR: "fsl_lbc_lock" [drivers/mtd/nand/fsl_upm.ko] undefined! > > Weird. It works for me with mpc836x_rdk_defconfig and > MTD_NAND_FSL_UPM=m... > > Hm.. > > CC drivers/mtd/nand/fsl_upm.mod.o > LD [M] drivers/mtd/nand/fsl_upm.ko > > Can you send me the .config file you use? http://davej.fedorapeople.org/ppc.config > But the patch looks obviously correct. Much thanks for catching this. > > Though better option would be to uninline the fsl_upm_run_pattern().. > it is quite big anyway... Something like this: I'll leave it to you to decide what to push to Linus Dave -- http://www.codemonkey.org.uk ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
