Re: [PATCH 3/4] arch: define CONFIG_PAGE_SIZE_*KB on all architectures

On Mon, 2024-02-26 at 17:14 +0100, Arnd Bergmann wrote: > > arch/um/Kconfig| 1 + > arch/um/include/asm/page.h | 2 +- LGTM, thanks. Acked-by: Johannes Berg johannes

Re: [PATCH 10/10] [RFC] wifi: remove ipw2100/ipw2200 drivers

On Thu, 2023-10-26 at 12:49 +0300, Kalle Valo wrote: > Philipp Hortmann writes: > > > On 10/26/23 00:27, Witold Baryluk wrote: > > > I might be interested in modernizing the driver, but I have no idea > > > how much effort it would be (in terms of changed fraction of code). > > > 20k LOC is

Re: [PATCH] [RFC] wireless: move obsolete drivers to staging

On Fri, 2023-10-13 at 17:44 +0200, Arnd Bergmann wrote: > On Thu, Oct 12, 2023, at 18:36, Geoff Levand wrote: > > On 10/12/23 17:41, Johannes Berg wrote: > > > But seriously - is it worth to try to keep a wireless driver for it if > > > we don't even kno

Re: [PATCH] [RFC] wireless: move obsolete drivers to staging

On Thu, 2023-10-12 at 16:36 +0200, Arnd Bergmann wrote: > > ps3-gelic-wireless Didn't Sony disable Linux on PS3 eventually? Though maybe someone still has some devices with old software. johannes

Re: [PATCH] [RFC] wireless: move obsolete drivers to staging

On Thu, 2023-10-12 at 17:39 +0200, Geert Uytterhoeven wrote: > Hi Johannes, > > On Thu, Oct 12, 2023 at 5:28 PM Johannes Berg > wrote: > > On Thu, 2023-10-12 at 16:36 +0200, Arnd Bergmann wrote: > > > > > > ps3-gelic-wireless > > > > Didn't So

Re: [PATCH v3 01/38] Kconfig: introduce HAS_IOPORT option and select it as necessary

does "select ISA" (only in some other architectures), so is there much point in this? I'm not even sure why this exists at all. But anyway, adding a dependency to a always-false symbol doesn't make it less always-false :-) Acked-by: Johannes Berg # for ARCH=um Certainly wil

Re: [PATCH 11/30] um: Improve panic notifiers consistency and ordering

On Wed, 2022-05-11 at 17:22 -0300, Guilherme G. Piccoli wrote: > On 10/05/2022 11:28, Petr Mladek wrote: > > [...] > > It is not clear to me why user mode linux should not care about > > the other notifiers. It might be because I do not know much > > about the user mode linux. > > > > Is the

Re: [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

On Mon, 2022-02-28 at 20:16 +, Matthew Wilcox wrote: > On Mon, Feb 28, 2022 at 12:10:24PM -0800, Linus Torvalds wrote: > > We can do > > > > typeof(pos) pos > > > > in the 'for ()' loop, and never use __iter at all. > > > > That means that inside the for-loop, we use a _different_

Re: [net] Revert "net: core: maybe return -EEXIST in __dev_alloc_name"

. > > I've just queued up the following revert, thanks! > > > From 5047543928139184f060c8f3bccb788b3df4c1ea Mon Sep 17 00:00:00 2001 > From: "David S. Miller" <da...@davemloft.net> > Date: Tue, 2 Jan 2018 11:45:07 -0500 > Subject: [PATCH

Re: [net] Revert "net: core: maybe return -EEXIST in __dev_alloc_name"

Hi, > This revert seems to have broken networking on one of my powerpc > machines, according to git bisect. Fun! TBH, I only looked at the immediate problem we ran into, and reverted what was causing it. I don't think we saw the follow-up problem you're seeing. > The symptom is DHCP fails and

Re: [RFC] fs: add userspace critical mounts event support

On Tue, 2016-11-29 at 22:37 +0100, Luis R. Rodriguez wrote: > On Tue, Nov 29, 2016 at 10:10:56PM +0100, Tom Gundersen wrote: > > > > On Tue, Nov 15, 2016 at 10:28 AM, Johannes Berg > > <johan...@sipsolutions.net> wrote: > > > > > > My argument basica

Re: [RFC] fs: add userspace critical mounts event support

On Tue, 2016-11-08 at 23:47 +0100, Luis R. Rodriguez wrote: > This issue still stands. At Plumbers Johannes Berg did indicate to me > he had a simple elegant solution in mind. He suggested that since the > usermode helper was available, he had added support to be able to > differe

Re: [PATCH 11/13] ALSA: Deletion of checks before the function call "iounmap"

On Wed, 2016-10-26 at 15:26 +0300, Dan Carpenter wrote: > Someone was just mentioning in another thread that removing the check > from iounmap() is not portable to other arches and then I remembered > that Markus removed a bunch of these. > > We should consider reverting this, perhaps? Can't we

Re: [PATCH] ALSA: snd-aoa: enable sound on PowerBook G4 12"

On Wed, 2016-08-24 at 20:57 +0300, Aaro Koskinen wrote: > Enable sound on PowerBook G4 12". Looks good to me, I assume you tested it and it works :) johannes > Signed-off-by: Aaro Koskinen > --- >  sound/aoa/fabrics/layout.c   | 8 >  

Re: [PATCH 4/4] sound/core/seq: make prioq_match return bool

On Tue, 2015-09-22 at 21:22 +0800, Yaowei Bai wrote: > On Mon, Sep 21, 2015 at 04:11:00PM +0200, Johannes Berg wrote: > > > > > -static inline int prioq_match(struct snd_seq_event_cell *cell, > > > +static inline bool prioq_match(struct snd_seq_event_cell *cell, > &

Re: [PATCH 4/4] sound/core/seq: make prioq_match return bool

> -static inline int prioq_match(struct snd_seq_event_cell *cell, > +static inline bool prioq_match(struct snd_seq_event_cell *cell, > int client, int timestamp) I think you should fix up the indentation now. johannes ___

Re: [PATCH] sound: aoa: printk replacement

On Wed, 2014-09-10 at 19:21 +0530, Sudip Mukherjee wrote: as pr_* macros are more preffered over printk, so printk replaced with corresponding pr_* macros. Are you simply running checkpatch on every file and decided to do something about it? :) I'll let Takashi decide whether to take this or

Re: [patch] ALSA: snd-aoa: two copy and paste bugs

On Wed, 2013-11-13 at 09:29 +0100, Takashi Iwai wrote: At Wed, 13 Nov 2013 10:45:20 +0300, Dan Carpenter wrote: These functions were cut and paste and the tests for NULL weren't updated properly. Signed-off-by: Dan Carpenter dan.carpen...@oracle.com Thanks, applied. FWIW, looks

Re: [PATCH] powerpc: add Book E support to 64-bit hibernation

On Tue, 2013-03-19 at 17:16 -0500, Scott Wood wrote: I wonder about kernel modules, though flushing 32 MiB wouldn't be adequate there. Good question, but would they be running? You have to have everything built in that you need to load the image? Or maybe not, with the userspace

Re: [PATCH] powerpc: add Book E support to 64-bit hibernation

On Mon, 2013-03-18 at 17:12 -0500, Scott Wood wrote: Could you elaborate on why book3s flushes the way it does? What's special about the first 32 MiB? If it's to cover kernel code, why would that be changing from what's already there? I was going to say I have no idea, but looking at it

Re: [PATCH] powerpc: add Book E support to 64-bit hibernation

On Tue, 2013-03-19 at 16:10 -0500, Scott Wood wrote: I was going to say I have no idea, but looking at it again ... this is in the *resume* code, not the suspend code as I'd assumed, and on resume I guess I felt it was safer to not assume it didn't change, since it could be a slightly

Re: [PATCH] powerpc: add Book E support to 64-bit hibernation

On Thu, 2013-03-14 at 11:52 -0500, Scott Wood wrote: +#ifdef CONFIG_PPC_BOOK3S_64 /* can't use RESTORE_SPECIAL(MSR) */ ld r0, SL_MSR(r11) mtmsrd r0, 0 Unfortunately, I forgot the reason for this comment, and didn't put a better one (almost 6 years ago!!) If it's

Re: [PATCH] powerpc: add Book E support to 64-bit hibernation

On Thu, 2013-03-14 at 11:36 +0800, Wang Dongsheng wrote: +#ifdef CONFIG_PPC_BOOK3S_64 /* can't use RESTORE_SPECIAL(MSR) */ ld r0, SL_MSR(r11) mtmsrd r0, 0 Unfortunately, I forgot the reason for this comment, and didn't put a better one (almost 6 years ago!!) +

Re: [RFC][PATCH] powerpc: add Book E support to 64-bit hibernation

Hi, Subject: [RFC][PATCH] powerpc: add Book E support to 64-bit hibernation Any thoughts about this patch? Heh, honestly, no. I know nothing about Book E, and it's too long ago that I wrote (some of) the 64-bit hibernation code. johannes ___

Re: PowerMac G4 (Digital Audio)

On Tue, 2010-12-07 at 10:51 +0200, Risto Suominen wrote: 2010/12/5, Johannes Berg johan...@sipsolutions.net: http://ristosu.wippiespace.com/pub/alsa-tumbler-1.0.22.1-p15.diff http://ristosu.wippiespace.com/pub/alsa-tumbler-1.0.22.1-p16.diff These patches are odd -- the first one adds

Re: PowerMac G4 (Digital Audio)

On Tue, 2010-12-07 at 13:27 +0200, Risto Suominen wrote: Can you hack the file I previously pointed out and see if that helps? Well, I could try. Actually, I don't own a machine to test with. Oh, ok... I thought you did. So, as far as I can see, you don't have any special handling for

Re: PowerMac G4 (Digital Audio)

On Tue, 2010-12-07 at 13:41 +0200, Risto Suominen wrote: 2010/12/7, Johannes Berg johan...@sipsolutions.net: Right, normally we don't need any special handling since the DT has the right names ... this machine just needs an override for the GPIO names (gpio15/16 rather than the proper

Re: PowerMac G4 (Digital Audio)

Your snd-aoa seems to support PowerMac3,4. Is it really tested? I used to add only IDs that some people tested, until most things worked and I wholesale added all of the ones found in Darwin. The reason I'm asking: people are having problems with sound on that machine. Even snd-powermac

[PATCH 2.6.35 v3] powerpc: fix logic error in fixup_irqs

+] Signed-off-by: Johannes Berg johan...@sipsolutions.net --- v2: cc Alastair, sorry v3: indicate stable versions arch/powerpc/kernel/irq.c |5 - 1 file changed, 4 insertions(+), 1 deletion(-) --- wireless-testing.orig/arch/powerpc/kernel/irq.c 2010-06-11 22:51:08.0 +0200

[PATCH 2.6.35 stable (v2)] powerpc: fix logic error in fixup_irqs

-by: Johannes Berg johan...@sipsolutions.net --- v2: cc Alastair, sorry arch/powerpc/kernel/irq.c |5 - 1 file changed, 4 insertions(+), 1 deletion(-) --- wireless-testing.orig/arch/powerpc/kernel/irq.c 2010-06-11 22:51:08.0 +0200 +++ wireless-testing/arch/powerpc/kernel/irq.c

Re: [PATCH 2.6.35 stable (v2)] powerpc: fix logic error in fixup_irqs

On Fri, 2010-06-11 at 22:55 +0200, Johannes Berg wrote: When SPARSE_IRQ is set, irq_to_desc() can return NULL. While the code here has a check for NULL, it's not really correct. Fix it by separating the check for it. Incidentally, there's another quirk in fixup_irqs

Re: [PATCH v2 0/7] wireless: Use macros from wireless.h

On Wed, 2010-03-17 at 23:21 -0700, Joe Perches wrote: Move the STD_IW_HANDLER macro from orinoco to wireless.h Use the wireless.h macros in various wireless files Remove local #defines of IW_IOCTL I really don't want to debug any breakage here, but otherwise I don't care and this is fine with

Re: [PATCH v2] ps3_gelic_wireless: Fix build failure due to missing WEXT_PRIV

On Fri, 2009-12-18 at 10:24 -0800, Geoff Levand wrote: From: Benjamin Herrenschmidt b...@kernel.crashing.org The option to support the old style PSK interface in the PS3 GELIC wireless drivers requires CONFIG_WEXT_PRIV to be set Signed-off-by: Benjamin Herrenschmidt

Re: [PATCH 5/5] sound/aoa: Add kmalloc NULL tests

On Thu, 2009-07-30 at 16:11 +0200, Julia Lawall wrote: From: Julia Lawall ju...@diku.dk Check that the result of kzalloc is not NULL before a dereference. irq_client = kzalloc(sizeof(struct pmf_irq_client), GFP_KERNEL); + if

Re: [PATCH] AOA: Convert onyx and tas codecs to new-style i2c drivers

Hi, Have you taken care of snd-powermac similarly? Yes I did, see my patch keywest: Convert to new-style i2c driver to the alsa-devel and linuxppc-dev mailing lists: http://ozlabs.org/pipermail/linuxppc-dev/2009-April/070884.html Would you be able to test this patch? This would be very

Re: [PATCH] AOA: Convert onyx and tas codecs to new-style i2c drivers

On Mon, 2009-04-20 at 22:54 +0200, Jean Delvare wrote: The legacy i2c binding model is going away soon, so convert the AOA codec drivers to the new model or they'll break. Signed-off-by: Jean Delvare kh...@linux-fr.org Tested-by: Johannes Berg johan...@sipsolutions.net Tested-by: Andreas

Re: [PATCH] AOA: Convert onyx and tas codecs to new-style i2c drivers

Hi, Because the device-tree is broken -- there are two nodes for the same device, and only one of them can be used. Then the fabric rejects the first instantiation from the broken node. Here's how it looks normally: ... [ 10.398296] snd-aoa-codec-onyx: found pcm3052 [

Re: [PATCH] AOA: Convert onyx and tas codecs to new-style i2c drivers (v3)

On Wed, 2009-04-15 at 14:22 +0200, Jean Delvare wrote: The legacy i2c binding model is going away soon, so convert the AOA codec drivers to the new model or they'll break. Signed-off-by: Jean Delvare kh...@linux-fr.org Cc: Johannes Berg johan...@sipsolutions.net Cc: Benjamin Herrenschmidt b

Re: [PATCH] AOA: Convert onyx and tas codecs to new-style i2c drivers

On Wed, 2009-04-15 at 15:06 +0200, Jean Delvare wrote: That would be weird -- the error path _has_ to be taken always in onyx. Unless you're talking about something in the i2c core or whatever? Yes, i2c core or even driver core. I'll see if I can reproduce it. Alright. (...) Well,

Re: [PATCH] AOA: Convert onyx and tas codecs to new-style i2c drivers

On Thu, 2009-04-09 at 14:19 +0200, Jean Delvare wrote: From: Jean Delvare kh...@linux-fr.org Subject: AOA: Convert onyx and tas codecs to new-style i2c drivers The legacy i2c binding model is going away soon, so convert the AOA codec drivers to the new model or they'll break. So I went to

Re: [PATCH] AOA: Convert onyx and tas codecs to new-style i2c drivers

On Tue, 2009-04-14 at 17:40 +0200, Johannes Berg wrote: So I went to test this, but for some reason aoa doesn't work for me at all, neither with nor without this patch. The reason seems to be that aoa_fabric_layout_probe() is never called, but my driver model fu is weak so I can't tell why

Re: [PATCH] AOA: Convert onyx and tas codecs to new-style i2c drivers

On Tue, 2009-04-14 at 18:48 +0200, Andreas Schwab wrote: Johannes Berg johan...@sipsolutions.net writes: So I went to test this, but for some reason aoa doesn't work for me at all, neither with nor without this patch. That is already fixed by http://www.kernel.org/pub/linux/kernel

Re: [PATCH] AOA: Convert onyx and tas codecs to new-style i2c drivers

On Tue, 2009-04-14 at 17:51 +0200, Johannes Berg wrote: On Tue, 2009-04-14 at 17:40 +0200, Johannes Berg wrote: So I went to test this, but for some reason aoa doesn't work for me at all, neither with nor without this patch. The reason seems to be that aoa_fabric_layout_probe

Re: [PATCH] AOA: Convert onyx and tas codecs to new-style i2c drivers

Hi Jean, Thanks for the quick test and sorry that it didn't work. I'll take a look at the trace below and try to figure out what went wrong. No worries, seems some error path is going wrong but I can't see what it is right now. Did you remove the 2 MODULE_DEVICE_TABLE from my patch? If you

Re: [PATCH] AOA: Convert onyx and tas codecs to new-style i2c drivers

Hi Jean! Yes, probing would be duplicated if we had to support more than one bus. But as far as I can see, the onyx and tas devices can only be found on i2c-powermac buses, so this shouldn't be an issue. And there isn't really any probing going on, it's really only a matter of walking a

Re: [PATCH] AOA: Convert onyx and tas codecs to new-style i2c drivers

Hi Jean, OK, I understand how it works now, thanks for pointing me to the relevant piece of code. It's easier to modify the code when you understand the current logic ;) :) The idea is to assign fixed i2c bus numbers to the relevant i2c buses, and declare the i2c devices connected to each

Re: [PATCH] AOA: Convert onyx and tas codecs to new-style i2c drivers

Hi! Basically the idea is to move the I2C device instantiation from the codec drivers (onyx, tas) to the I2C adapter driver (i2c-powermac.) This follows the Linux device driver model, requires slightly less code, runs faster and and lets the required chip drivers be loaded by udev or similar

[PATCH] snd-aoa: handle older machines

regressions because this driver will otherwise load automatically and not let snd-powermac load. People who are unhappy with snd-powermac and have a device-id property in the device tree are encouraged to read this patch and make a patch to amend this as appropriate. Signed-off-by: Johannes Berg

[PATCH] snd-aoa: handle master-amp if present

which also doesn't use the master amp GPIO. Signed-off-by: Johannes Berg johan...@sipsolutions.net --- sound/aoa/aoa-gpio.h |2 ++ sound/aoa/core/gpio-feature.c | 17 - sound/aoa/fabrics/layout.c|7 +++ 3 files changed, 25 insertions(+), 1 deletion

powerbook VT garbled between rc7 and rc8

Hi, After upgrading to -rc8 yesterday my powerbook started up today with the screen totally garbled, only occasionally was a word readable. I also tried adding radeonfb=accel_cexp to the command line but that changed nothing. Also, once I was in X, it seemingly worked fine, but then I opened up a

Re: powerbook VT garbled between rc7 and rc8

On Fri, 2008-12-12 at 13:05 +0100, Andreas Schwab wrote: Johannes Berg johan...@sipsolutions.net writes: After upgrading to -rc8 yesterday my powerbook started up today with the screen totally garbled, only occasionally was a word readable. Try 6c34bc2976b30dc8b56392c020e25bae1f363cab

Re: powerbook VT garbled between rc7 and rc8

On Fri, 2008-12-12 at 13:05 +0100, Andreas Schwab wrote: Johannes Berg johan...@sipsolutions.net writes: After upgrading to -rc8 yesterday my powerbook started up today with the screen totally garbled, only occasionally was a word readable. Try 6c34bc2976b30dc8b56392c020e25bae1f363cab

Re: [PATCH v2] powerpc: allow configuring max stack dump depth

On Thu, 2008-11-20 at 09:10 +1100, Paul Mackerras wrote: Johannes Berg writes: On my screen, when something crashes, I only have space for maybe 16 functions of the stack trace before the information above it scrolls off the screen. It's easy to hack the kernel to print out only

[PATCH v3] powerpc: allow configuring max stack dump depth

that I can keep the setting in my config. Signed-off-by: Johannes Berg [EMAIL PROTECTED] --- v3 corrects the stupid Kconfig dependency mistake arch/powerpc/Kconfig.debug|9 + arch/powerpc/kernel/process.c |2 +- 2 files changed, 10 insertions(+), 1 deletion

[PATCH v2] powerpc: allow configuring max stack dump depth

that I can keep the setting in my config. Signed-off-by: Johannes Berg [EMAIL PROTECTED] --- Sure, here's an updated version. I used DEBUG_KERNEL since the ADVANCED_CONFIGURATION help text implies it's for MM and can cause the kernel to not boot, not something this config is related to. Thanks

[PATCH] powerpc: don't export pci dma inlines

These are inlines provided by the pci-dma-compat API. Signed-off-by: Johannes Berg [EMAIL PROTECTED] --- arch/powerpc/kernel/ppc_ksyms.c |2 -- 1 file changed, 2 deletions(-) --- everything.orig/arch/powerpc/kernel/ppc_ksyms.c 2008-11-17 23:58:35.0 +0100 +++ everything/arch

[PATCH] powerpc: allow configuring max stack dump depth

that I can keep the setting in my config. Signed-off-by: Johannes Berg [EMAIL PROTECTED] --- arch/powerpc/Kconfig.debug|7 +++ arch/powerpc/kernel/process.c |2 +- 2 files changed, 8 insertions(+), 1 deletion(-) --- everything.orig/arch/powerpc/Kconfig.debug 2008-11-01 11:03

Re: [PATCH] uninorth agp: don't mark module parameter __devinit

Michel Dänzer wrote: Can uninorth_fetch_size be marked __devinit then? I'm not sure, and none of the other AGP backend drivers seems to do so... Well, either it can, or marking aperture is wrong, no? johannes ___ Linuxppc-dev mailing list

relocatable kernel vs. yaboot

Hi, Sorry if this has been discussed before, but I just found that yaboot rejects relocatable kernels claiming they are an invalid ELF file. In the patch adding relocatable kernel support, I found +# The iseries hypervisor won't take an ET_DYN executable, so this +# changes the type (byte 17)

Re: relocatable kernel vs. yaboot

On Fri, 2008-10-31 at 08:33 +1100, Paul Mackerras wrote: Yes, yaboot needs to be fixed. Yeah, my bad, I was offline when writing this and only checked later to find you'd already discussed that. Sorry. Modifying the vmlinux in the same way as above makes yaboot take it, and I can easily

Re: [PATCH] uninorth agp: don't mark module parameter __devinit

On Wed, 2008-10-29 at 13:09 +0100, Michel Dänzer wrote: On Wed, 2008-10-29 at 03:11 +0100, Johannes Berg wrote: A module parameter can possibly be shown via sysfs, which isn't a good idea if the section has been removed, so remove the __devinit annotation. Under what circumstances could

[PATCH] uninorth agp: don't mark module parameter __devinit

A module parameter can possibly be shown via sysfs, which isn't a good idea if the section has been removed, so remove the __devinit annotation. Signed-off-by: Johannes Berg [EMAIL PROTECTED] --- Also fixes a section mismatch warning. --- everything.orig/drivers/char/agp/uninorth-agp.c 2008

Re: adding more machines to snd-aoa

:08.0 +0200 @@ -1,16 +1,14 @@ /* - * Apple Onboard Audio driver -- layout fabric + * Apple Onboard Audio driver -- layout/machine id fabric * - * Copyright 2006 Johannes Berg [EMAIL PROTECTED] + * Copyright 2006, 2008 Johannes Berg [EMAIL PROTECTED] * * GPL v2, can be found in COPYING

Re: adding more machines to snd-aoa

On Fri, 2008-10-24 at 14:26 +0200, Gabriel Paubert wrote: Right. I'll assume it has a microphone too, built-in. I doubt it: - no mention found in the doc - it seems to be output-only (#-inputs in the device tree is 0, #-outputs is 3). Yeah, I've disabled it in the patch I sent you. I

Re: adding more machines to snd-aoa

2006 Johannes Berg [EMAIL PROTECTED] + * Copyright 2006, 2008 Johannes Berg [EMAIL PROTECTED] * * GPL v2, can be found in COPYING. * * - * This fabric module looks for sound codecs - * based on the layout-id property in the device tree. - * + * This fabric module looks for sound codecs based

adding more machines to snd-aoa

Hi, Andreas (Cc'ed) asked whether it was possible to use snd-aoa on his machine, a PowerMac3,6. It appears that it is fairly easy since the machine seems to use a regular i2sbus. To identify it, after looking through my device-tree collections I think that the device-id property of the sound

Re: adding more machines to snd-aoa

On Thu, 2008-10-23 at 17:35 +0200, Gabriel Paubert wrote: On my almost 8 years old PowerMac (PowerMac3,4 accorfing to OF): $ find /proc/device-tree/ -wholename '*sound/device-id' | xargs hd 00 00 00 0e || 0004 or 14 in decimal.

Re: powerpc allmodconfig

On Thu, 2008-10-16 at 13:02 -0700, Arjan van de Ven wrote: On Thu, 16 Oct 2008 12:49:23 -0700 (PDT) David Miller [EMAIL PROTECTED] wrote: #endif #define __WARN() warn_on_slowpath(__FILE__, __LINE__) #define __WARN_printf(arg...) warn_slowpath(__FILE__, __LINE__, arg) #else #define

Re: powerpc allmodconfig

On Wed, 2008-10-15 at 22:02 -0700, David Miller wrote: net/sched/sch_generic.c: In function 'dev_watchdog': net/sched/sch_generic.c:224: warning: unused variable 'drivername' Sucky, if WARN_ONCE() evaluates to nothing the sprintf() string buffer on the stack looks unused. I've

Re: [Bugme-new] [Bug 11629] New: quad G5 fails to shut down

I wrote: And here's the fix. Well, that should of course remove that comment there too. New version below. From: Johannes Berg [EMAIL PROTECTED] Subject: powerpc: fix shutdown I tracked down the shutdown regression to CPUs not dying when being shut down during power-off. This turns out

Re: [Bugme-new] [Bug 11629] New: quad G5 fails to shut down

(); And here's the fix. From: Johannes Berg [EMAIL PROTECTED] Subject: powerpc: fix shutdown I tracked down the shutdown regression to CPUs not dying when being shut down during power-off. This turns out to be due to the system_state being SYSTEM_POWER_OFF, which this code doesn't take as a valid state

[PATCH] powerpc: enforce sane MAX_ORDER

for 4K pages. This patch makes the Kconfig enforce at least the defaults, I used 999 as the upper bound for no particular reason other than that it's plenty. Signed-off-by: Johannes Berg [EMAIL PROTECTED] --- --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -415,8 +415,11 @@ config

[PATCH] powerpc: make 64-bit hibernation depend on !64K_PAGES

on !PPC_64K_PAGES. Signed-off-by: Johannes Berg [EMAIL PROTECTED] --- --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -194,7 +194,7 @@ config HIBERNATE_32 config HIBERNATE_64 bool - depends on BROKEN || (PPC_PMAC64 EXPERIMENTAL) + depends on BROKEN || (PPC_PMAC64

[PATCH] powerpc: fix 64-bit hibernation with 64k pages

Brown paper bag patch, the fact that it didn't work is entirely my fault for hardcoding 512 in the original patch. Signed-off-by: Johannes Berg [EMAIL PROTECTED] --- Contains the revert for the earlier patch just in case; probably better to not apply the earlier patch and only the first hunk

Re: [PATCH] powerpc: enforce sane MAX_ORDER

On Wed, 2008-09-24 at 09:05 -0500, Kumar Gala wrote: --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -415,8 +415,11 @@ config PPC_64K_PAGES config FORCE_MAX_ZONEORDER int Maximum zone order + range 9 999 if PPC_64K_PAGES default 9 if PPC_64K_PAGES + range 13

[PATCH v2] powerpc: enforce sane MAX_ORDER

for 4K pages. This patch makes the Kconfig enforce at least the defaults. Signed-off-by: Johannes Berg [EMAIL PROTECTED] --- We'll I'm ok with that, but I dont think we should be values that make no sense. 64 would seem the max even in a 64-bit system. Indeed, it makes little sense to allow

G5 doesn't shut down with current kernel

Instead, I get an oops right after trying to disable the non-boot CPUs. This was on 2.6.27-rc6-wl-01382-g0bea1f7-dirty. http://johannes.sipsolutions.net/files/dsc_2274.jpg johannes signature.asc Description: This is a digitally signed message part

Re: [Bugme-new] [Bug 11629] New: quad G5 fails to shut down

On Tue, 2008-09-23 at 14:30 -0700, Andrew Morton wrote: http://johannes.sipsolutions.net/files/dsc_2274.jpg That went splat in the clockevents code. I saw a pull request with several fixes float past this morning: From: Ingo Molnar [EMAIL PROTECTED] To: Linus Torvalds [EMAIL

Re: [Bugme-new] [Bug 11629] New: quad G5 fails to shut down

On Wed, 2008-09-24 at 00:45 +0200, Johannes Berg wrote: Well, that does seem to fix the regression. That is, it no longer crashes. Spoke too early, it seems that the crash isn't exactly reproducible all the time nor happens at the same spot all the time. I'd suspect that the timer code isn't

Re: [PATCH] duplicate SNDRV_PCM_FMTBIT_S{16,24}_BE

roel kluin wrote: untested, is it correct? not a clue, do you know how long ago that was? :) does the driver check endianness anywhere? duplicate SNDRV_PCM_FMTBIT_S{16,24}_BE Signed-off-by: Roel Kluin [EMAIL PROTECTED] --- diff --git a/sound/aoa/codecs/snd-aoa-codec-tas.c

64-bit build failure without hugetlbfs

LD vmlinux.o mm/built-in.o: In function `.arch_get_unmapped_area_topdown': (.text+0x1d084): multiple definition of `.arch_get_unmapped_area_topdown' arch/powerpc/mm/built-in.o:(.text+0x7240): first defined here mm/built-in.o: In function `arch_get_unmapped_area_topdown': (.opd+0x2730):

Re: PReP residual to device-tree converter

I would like people that have PReP machines to take a copy of /proc/residual, run this program on it, and check that the output is sane. If it isn't, or if it is missing bits, send me the residual blob with a description of what's wrong in the generated dts. Here's the output from qemu:

Re: PReP residual to device-tree converter

On Wed, 2008-07-09 at 12:48 +0200, Johannes Berg wrote: I would like people that have PReP machines to take a copy of /proc/residual, run this program on it, and check that the output is sane. If it isn't, or if it is missing bits, send me the residual blob with a description of what's

Re: PReP residual to device-tree converter

On Wed, 2008-07-09 at 13:29 +0200, Johannes Berg wrote: On Wed, 2008-07-09 at 12:48 +0200, Johannes Berg wrote: I would like people that have PReP machines to take a copy of /proc/residual, run this program on it, and check that the output is sane. If it isn't, or if it is missing bits

Re: PReP residual to device-tree converter

On Wed, 2008-07-09 at 13:29 +0200, Johannes Berg wrote: On Wed, 2008-07-09 at 12:48 +0200, Johannes Berg wrote: I would like people that have PReP machines to take a copy of /proc/residual, run this program on it, and check that the output is sane. If it isn't, or if it is missing bits

Re: cpu_clock confusion (was: printk time confusion?)

[2.764009 (3/3)] [4.272241 (2/2)] [4.272322 (2/2)] [4.272375 (2/2)] [2.948002 (3/3)] As you can see, I added printk_cpu and smp_processor_id() to the printk timestamp output and thus it is obvious that the different times come from different CPUs. the

Re: cpu_clock confusion

On Thu, 2008-04-24 at 02:24 -0700, David Miller wrote: From: Johannes Berg [EMAIL PROTECTED] Date: Thu, 24 Apr 2008 11:21:52 +0200 Hmm. Why is that whole cpu_clock stuff in place anyway? powerpc has perfectly synchronised time across processors with dirt cheap access to it as well, so

Re: [PATCH v3] powerpc: Add irqtrace support for 32-bit powerpc

On Wed, 2008-04-23 at 14:40 +1000, Benjamin Herrenschmidt wrote: Hmm. Bad news. I got a crash in console_callback() again where apparently r28 had a bogus value. That, however, doesn't make sense, so maybe that register value was calculated from another register. Possibly. How hard was

Re: [PATCH v3] powerpc: Add irqtrace support for 32-bit powerpc

This version fixes the clobbering of r12 by the call to trace_hardirqs_off() that was pointed out by BenH. Johannes, I'd appreciate your trying this version if/when you get the chance. Thanks Dale, this version seems to work. I'll stress it a bit more later, but so far it has

Re: [PATCH v3] powerpc: Add irqtrace support for 32-bit powerpc

On Mon, 2008-04-07 at 10:14 -0700, Dale Farnsworth wrote: Add the low level irq tracing hooks for 32-bit powerpc needed to enable full lockdep functionality. Dale Farnsworth [EMAIL PROTECTED] --- This version fixes the clobbering of r12 by the call to trace_hardirqs_off() that was pointed

Re: [PATCH v2] powerpc: Add irqtrace support for 32-bit powerpc

Note that I've been wondering wether we should attempt to trace all those IRQ state change internally to the exception code. I've looked at not doing it, which simplifies things a bit. Unfortunately, that will make us occasionally trace redundant enable/disable (which isn't a big problem

[PATCH/RFC] via-pmu: remove mdelays from suspend/resume code

I don't see a reason for either of those mdelay()s, is there any? Works fine for me without them... johannes --- drivers/macintosh/via-pmu.c | 20 +++- 1 file changed, 3 insertions(+), 17 deletions(-) --- everything.orig/drivers/macintosh/via-pmu.c 2008-04-03

cpu_clock confusion (was: printk time confusion?)

Hi, Not sure whether the lockdep patches or something else is causing this as I haven't checked w/o the patches yet, but I seem to be having some confusion of printk timestamps: Tried reverting the patches ? That didn't help, so it's not the lockdep patches causing it. I'm still seeing

Re: [PATCH/RFC] via-pmu: remove mdelays from suspend/resume code

On Fri, 2008-04-04 at 10:20 -0700, Brad Boyer wrote: On Thu, Apr 03, 2008 at 05:44:44PM +0200, Johannes Berg wrote: I don't see a reason for either of those mdelay()s, is there any? Works fine for me without them... Which hardware revisions did you test? I suspect the mdelay calls were

Re: [RFC/PATCH] powerpc: Add irqtrace support to 32-bit powerpc

On Wed, 2008-04-02 at 16:15 +0200, Johannes Berg wrote: On Fri, 2008-02-01 at 12:50 -0700, Dale Farnsworth wrote: This adds the low level irq tracing hooks for 32-bit powerpc. This patch applies on top of Benjamin Herrenschmidt's patch that provides similar support for 64-bit powerpc. See

Re: [PATCH v2] powerpc: Add irqtrace support for 32-bit powerpc

This version takes care to save and restore *all* the volatile registers around the call to trace_hardirqs_off in transfer_to_handler, and should fix the anomalies seen by Johannes Berg. I've tested on 7447- and 8548- based boards. Still has problems on my machine. Maybe to do with non

Re: [RFC/PATCH] powerpc: Add irqtrace support to 32-bit powerpc

On Fri, 2008-02-01 at 12:50 -0700, Dale Farnsworth wrote: This adds the low level irq tracing hooks for 32-bit powerpc. This patch applies on top of Benjamin Herrenschmidt's patch that provides similar support for 64-bit powerpc. See

printk time confusion?

Hi, Not sure whether the lockdep patches or something else is causing this as I haven't checked w/o the patches yet, but I seem to be having some confusion of printk timestamps: [...] [ 176.440255] iwl4965: No space for Tx [...] [ 147.983705] ioctl32(gnome-terminal:6361): Unknown cmd fd(25)

Re: [PATCH 0/4] [POWERPC] lockdep support for ppc64

Haven't tested this version on G5 yet btw :-) (though I had a previous one working internally). I tested on POWER6 pSeries and old iSeries (spent a while fixing the later). I'll run more tests tomorrow hopefully and add a few patch fixing some of the issues that lockdep already starting

Re: printk time confusion?

Not sure whether the lockdep patches or something else is causing this as I haven't checked w/o the patches yet, but I seem to be having some confusion of printk timestamps: Tried reverting the patches ? No, not yet, I'll do that later today. [ 155.982345]

  1   2   >