* Re: [PATCH] Fix compilation for non CONFIG_HOTPLUG case
From: Sergei Shtylyov @ 2007-07-29 16:45 UTC (permalink / raw)
To: niklaus.giger; +Cc: linux-kernel, kristen.c.accardi, linuxppc-embedded
In-Reply-To: <200707291807.52042.niklaus.giger@member.fsf.org>
Hello.
Niklaus Giger wrote:
> Fixes compilation issues for embedded boards which do not support HOTPLUG
> Signed-off-by: Niklaus Giger <niklaus.giger@member.fsf.org>
> diff --git a/drivers/base/core.c b/drivers/base/core.c
> index 3599ab2..a09bfc8 100644
> --- a/drivers/base/core.c
> +++ b/drivers/base/core.c
> @@ -24,7 +24,9 @@
> #include "base.h"
> #include "power/power.h"
>
> +#ifdef CONFIG_HOTPLUG
> extern const char *kobject_actions[];
> +#endif
No need for #ifdef around extern declarations.
> int (*platform_notify)(struct device * dev) = NULL;
> int (*platform_notify_remove)(struct device * dev) = NULL;
> @@ -306,11 +308,13 @@ static ssize_t store_uevent(struct device *dev, struct
> device_attribute *attr,
> const char *buf, size_t count)
> {
> size_t len = count;
> +#ifdef CONFIG_HOTPLUG
> enum kobject_action action;
> -
> +#endif
Please don't remove newline between the declaration block and the code.
> if (len && buf[len-1] == '\n')
> len--;
>
> +#ifdef CONFIG_HOTPLUG
> for (action = 0; action < KOBJ_MAX; action++) {
> if (strncmp(kobject_actions[action], buf, len) != 0)
> continue;
> @@ -319,11 +323,14 @@ static ssize_t store_uevent(struct device *dev, struct
> device_attribute *attr,
> kobject_uevent(&dev->kobj, action);
> goto out;
Grr... cleanup style abuse -- ISO a mere return they used goto. :-/
> }
> +#endif
>
> dev_err(dev, "uevent: unsupported action-string; this will "
> "be ignored in a future kernel version\n");
> kobject_uevent(&dev->kobj, KOBJ_ADD);
> +#ifdef CONFIG_HOTPLUG
> out:
> +#endif
Well, #ifdef'ing out label seems too much.
> return count;
> }
WBR, Sergei
^ permalink raw reply
* [PATCH] Fix compilation for non CONFIG_HOTPLUG case
From: Niklaus Giger @ 2007-07-29 16:07 UTC (permalink / raw)
To: linux-kernel; +Cc: linuxppc-embedded, kristen.c.accardi
Fixes compilation issues for embedded boards which do not support HOTPLUG
Signed-off-by: Niklaus Giger <niklaus.giger@member.fsf.org>
---
drivers/base/core.c | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 3599ab2..a09bfc8 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -24,7 +24,9 @@
#include "base.h"
#include "power/power.h"
+#ifdef CONFIG_HOTPLUG
extern const char *kobject_actions[];
+#endif
int (*platform_notify)(struct device * dev) = NULL;
int (*platform_notify_remove)(struct device * dev) = NULL;
@@ -306,11 +308,13 @@ static ssize_t store_uevent(struct device *dev, struct
device_attribute *attr,
const char *buf, size_t count)
{
size_t len = count;
+#ifdef CONFIG_HOTPLUG
enum kobject_action action;
-
+#endif
if (len && buf[len-1] == '\n')
len--;
+#ifdef CONFIG_HOTPLUG
for (action = 0; action < KOBJ_MAX; action++) {
if (strncmp(kobject_actions[action], buf, len) != 0)
continue;
@@ -319,11 +323,14 @@ static ssize_t store_uevent(struct device *dev, struct
device_attribute *attr,
kobject_uevent(&dev->kobj, action);
goto out;
}
+#endif
dev_err(dev, "uevent: unsupported action-string; this will "
"be ignored in a future kernel version\n");
kobject_uevent(&dev->kobj, KOBJ_ADD);
+#ifdef CONFIG_HOTPLUG
out:
+#endif
return count;
}
--
1.5.2.4
^ permalink raw reply related
* [POWERPC] 2.6.23-rc1-mm1 build failure
From: Mariusz Kozlowski @ 2007-07-29 14:04 UTC (permalink / raw)
To: paulus, Andrew Morton; +Cc: linuxppc-dev, linux-kernel
Hello,
iMac G3 series.
$ make mrproper && make allmodconfig && make
results in this:
CC arch/powerpc/kernel/lparmap.s
AS arch/powerpc/kernel/head_64.o
lparmap.c: Assembler messages:
lparmap.c:84: Error: file number 1 already allocated
make[1]: *** [arch/powerpc/kernel/head_64.o] Blad 1
make: *** [arch/powerpc/kernel] Blad 2
Regards,
Mariusz
$ cat /proc/cpuinfo
processor : 0
cpu : 740/750
temperature : 46-52 C (uncalibrated)
clock : 400MHz
revision : 2.2 (pvr 0008 0202)
bogomips : 796.67
machine : PowerMac2,1
motherboard : PowerMac2,1 MacRISC2 MacRISC Power Macintosh
detected as : 66 (iMac FireWire)
pmac flags : 00000005
L2 cache : 512K unified
memory : 256MB
pmac-generation : NewWorld
Linux iMac-tux 2.6.8-powerpc #1 Thu Nov 24 00:17:15 UTC 2005 ppc GNU/Linux
Gnu C 4.1.2
Gnu make 3.81
binutils 2.17
util-linux 2.12r
mount 2.12r
module-init-tools 3.3-pre2
e2fsprogs 1.40-WIP
Linux C Library 3.6
Dynamic linker (ldd) 2.3.6
Procps 3.2.7
Net-tools 1.60
Console-tools 0.2.3
Sh-utils 5.97
Modules Loaded ipv6 af_packet joydev tsdev evdev eth1394 tulip crc32 ohci1394 ieee1394 uninorth_agp agpgart dm_snapshot dm_mirror dm_mod snd_powermac snd_pcm_oss snd_pcm snd_page_alloc snd_mixer_oss snd_seq_oss snd_seq_device snd_seq_midi_event snd_seq snd_timer snd soundcore ide_cd cdrom ext3 jbd mbcache usbhid uhci_hcd ohci_hcd usbcore ide_disk unix
^ permalink raw reply
* Re: ml403 ac97 driver
From: aq @ 2007-07-29 12:50 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <1185698888.6397.37.camel@localhost>
Joachim:
Thanks for your information. I will try it sooner.
The test program is A Minimal Playback Program from website:=20
http://equalarea.com/paul/alsa-audio.html
PS:Besides that test program i also used aplay to test codec ,the result is
no different.=20
qin lin
Joachim F=C3=B6rster wrote:
>=20
> Hi qin lin,
>=20
> On Sat, 2007-07-28 at 17:04 +0800, qin lin wrote:
>> I have add the driver to kernel as a module in ml403.When i insmod=20
>> the module ,there are warnings followed here:
>> [ 250.795594] snd-ml403_ac97cr: write access to codec register 0x26
>> with bad value 0x800f / 32783!=20
>> [ 250.911545] snd-ml403_ac97cr: write access to codec register 0x26
>> with bad value 0xf / 15!
>> [ 251.015576] snd-ml403_ac97cr: write access to codec register 0x2a
>> with bad value 0x2801 / 10241!
>> [ 251.127524] snd-ml403_ac97cr: write access to codec register 0x2a
>> with bad value 0x3801 / 14337!=20
>>=20
>> And i check the warring find the warnings should be from function
>> snd_ml403_ac97cr_codec_write() =EF=BC=8Ci have check the lm4550 codec
>> datasheet to make sure the mask is what you have written.
>=20
> These warnings are ok. Codec register 0x26 is the "PowerDown
> Status/Control" register and the ALSA AC97 layer tries to write ones to
> the lower 4 bits (which are AFAIK read only bits). LM4550 register 0x2a
> has only one valid bit (lowest), but ALSA tries to write to a not
> existing bit. So my driver masks out these bits.
> The warnings show the invalid numbers ALSA wants to write to these
> registers.
>=20
>> What confused me is that where call the fuction
>> snd_ml403_ac97cr_codec_write in the module_init program, would you
>> mind if you point it for me?=20
>=20
> Well, the function alsa_card_ml403_ac97cr_init() is registered as the
> module_init function. It registers the driver and the device to the
> kernel via platform_driver/device_register(). As a consequence the
> kernel will call the registered probe() function called
> snd_ml403_ac97cr_probe(). Among other things, the function called
> snd_ml403_ac97cr_mixer() is invoked. Finally this function registers a
> mixer device and the codec_read() and codec_write() functions with the
> ALSA AC97 layer. While registering the ALSA AC97 layer calls the read
> and write functions several times - a kind of initialization sequence.
> That's the usual structure of an ALSA driver - not that simple - I
> know :-) .
>=20
>> There is another problem trouble me .I find a simple test program to
>> check the codec playback work .But all it said that it cannot find
>> the pcm file.Would you mind if you suggest something or paste what you
>> have do to mknod the device?=20
>=20
> Oh, I forgot to mention that in the README file. I used the "snddevices"
> script found in ALSA's alsa-driver package (form version 1.0.13, but
> version shouldn't matter).
>=20
>> # ./test_sound.out /dev/snd/pcmC0D0
>> ALSA lib pcm.c:2090:(snd_pcm_open_noupdate) Unknown
>> PCM /dev/snd/pcmC0D0=20
>> cannot open audio device /dev/snd/pcmC0D0 (No such file or directory)
>=20
> Hmmm, try to create the device files with the script from above and see
> if that happens again ...
> BTW: (After having created the device files) you can also use aplay
> (alsa-utils package) for testing. Where did you find "test_sound"?
>=20
> Joachim
>=20
>=20
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
--=20
View this message in context: http://www.nabble.com/Re%3A-ml403-ac97-driver=
-tf4164866.html#a11851202
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: ml403 ac97 driver
From: Joachim Förster @ 2007-07-29 8:48 UTC (permalink / raw)
To: qin lin; +Cc: linuxppc-embedded
In-Reply-To: <2ec96d6e0707280204k50efb707q99a824c37f539309@mail.gmail.com>
Hi qin lin,
On Sat, 2007-07-28 at 17:04 +0800, qin lin wrote:
> I have add the driver to kernel as a module in ml403.When i insmod
> the module ,there are warnings followed here:
> [ 250.795594] snd-ml403_ac97cr: write access to codec register 0x26
> with bad value 0x800f / 32783!
> [ 250.911545] snd-ml403_ac97cr: write access to codec register 0x26
> with bad value 0xf / 15!
> [ 251.015576] snd-ml403_ac97cr: write access to codec register 0x2a
> with bad value 0x2801 / 10241!
> [ 251.127524] snd-ml403_ac97cr: write access to codec register 0x2a
> with bad value 0x3801 / 14337!
>
> And i check the warring find the warnings should be from function
> snd_ml403_ac97cr_codec_write() ，i have check the lm4550 codec
> datasheet to make sure the mask is what you have written.
These warnings are ok. Codec register 0x26 is the "PowerDown
Status/Control" register and the ALSA AC97 layer tries to write ones to
the lower 4 bits (which are AFAIK read only bits). LM4550 register 0x2a
has only one valid bit (lowest), but ALSA tries to write to a not
existing bit. So my driver masks out these bits.
The warnings show the invalid numbers ALSA wants to write to these
registers.
> What confused me is that where call the fuction
> snd_ml403_ac97cr_codec_write in the module_init program, would you
> mind if you point it for me?
Well, the function alsa_card_ml403_ac97cr_init() is registered as the
module_init function. It registers the driver and the device to the
kernel via platform_driver/device_register(). As a consequence the
kernel will call the registered probe() function called
snd_ml403_ac97cr_probe(). Among other things, the function called
snd_ml403_ac97cr_mixer() is invoked. Finally this function registers a
mixer device and the codec_read() and codec_write() functions with the
ALSA AC97 layer. While registering the ALSA AC97 layer calls the read
and write functions several times - a kind of initialization sequence.
That's the usual structure of an ALSA driver - not that simple - I
know :-) .
> There is another problem trouble me .I find a simple test program to
> check the codec playback work .But all it said that it cannot find
> the pcm file.Would you mind if you suggest something or paste what you
> have do to mknod the device?
Oh, I forgot to mention that in the README file. I used the "snddevices"
script found in ALSA's alsa-driver package (form version 1.0.13, but
version shouldn't matter).
> # ./test_sound.out /dev/snd/pcmC0D0
> ALSA lib pcm.c:2090:(snd_pcm_open_noupdate) Unknown
> PCM /dev/snd/pcmC0D0
> cannot open audio device /dev/snd/pcmC0D0 (No such file or directory)
Hmmm, try to create the device files with the script from above and see
if that happens again ...
BTW: (After having created the device files) you can also use aplay
(alsa-utils package) for testing. Where did you find "test_sound"?
Joachim
^ permalink raw reply
* Re: [PATCH 2/2] ehca: correction include order according kernel coding style
From: Roland Dreier @ 2007-07-29 3:39 UTC (permalink / raw)
To: Hoang-Nam Nguyen
Cc: linuxppc-dev, raisch, stefan.roscher, linux-kernel, general
In-Reply-To: <200707271255.19456.hnguyen@linux.vnet.ibm.com>
thanks, I applied this by hand since it was so trivial.
^ permalink raw reply
* Re: [ofa-general] [PATCH 1/2] ehca: remove checkpatch.pl's warnings "externs should be avoided in .c files"
From: Roland Dreier @ 2007-07-29 3:39 UTC (permalink / raw)
To: Hoang-Nam Nguyen; +Cc: linuxppc-dev, stefan.roscher, linux-kernel, general
In-Reply-To: <200707271254.51055.hnguyen@linux.vnet.ibm.com>
the patch looks fine except your mailer seems to have mangled
it... can you resend so I can apply it?
thanks...
^ permalink raw reply
* Re: [2.6 patch] arch/powerpc/Kconfig: fix the EMBEDDED6xx dependencies
From: Adrian Bunk @ 2007-07-28 15:27 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Andrew Morton, linuxppc-dev, linux-kernel
In-Reply-To: <17779.37050.4039.942954@cargo.ozlabs.ibm.com>
On Mon, Dec 04, 2006 at 02:06:34PM +1100, Paul Mackerras wrote:
> Adrian Bunk writes:
>
> > This patch changes the EMBEDDED6xx dependencies to the equivalent
> > dependency that seems to have been intended.
>
> Nack - CONFIG_EMBEDDED6xx is going away entirely, soon.
Still there - and still with this strange dependency.
> Paul.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: EST's VisionClick debugger fixes for Elf files from GNU tools
From: Richard Danter @ 2007-07-28 11:20 UTC (permalink / raw)
To: Chong, Zhia Howe; +Cc: linuxppc-embedded
In-Reply-To: <ED3AB1534F018544848A18EE0E01E0AC117CCB@pgsmsx414.gar.corp.intel.com>
[-- Attachment #1: Type: text/plain, Size: 636 bytes --]
On 25/07/07, Chong, Zhia Howe <zhia.howe.chong@intel.com> wrote:
>
> Hi,
>
> I am currently learning to use VisionClick with the VisionICE
> II debugger. Are you aware of using it in Linux? I can only use in VxWorks
> OS. If you know how to use in Linux, mind show me some steps in doing it?
>
Yes, depending on what version of vClick and vICE firmware you have it is
possible to debug some things in Linux. What are you trying to do exactly?
Debug the kernel, modules, applications? What is the target? vClick is old
now, Wind River has newer and much better JTAG/BDM tools (Workbench OCD) for
working with Linux.
Rich
[-- Attachment #2: Type: text/html, Size: 1258 bytes --]
^ permalink raw reply
* Re: [patch 07/35] pasemi_mac: stop using the pci config space accessors for register read/writes
From: Olof Johansson @ 2007-07-28 8:35 UTC (permalink / raw)
To: Marian Balakowicz; +Cc: linuxppc-dev
In-Reply-To: <46A91130.8000907@semihalf.com>
Hi,
On Thu, Jul 26, 2007 at 11:25:04PM +0200, Marian Balakowicz wrote:
>
> Olof,
>
> Olof Johansson wrote:
> > Move away from using the pci config access functions for simple register
> > access. Our device has all of the registers in the config space (hey,
> > from the hardware point of view it looks reasonable :-), so we need to
> > somehow get to it. Newer firmwares have it in the device tree such that
> > we can just get it and ioremap it there (in case it ever moves in future
> > products). For now, provide a hardcoded fallback for older firmwares.
>
> I have recently tried to apply a group of your MAC patches that
> includes the one from this email. Strangely, I got a pretty random
> kernel panics (or kernel freezes) when this patch is included. Panics
> happen in a random, places and have random causes. What I observed is
> that replacing newly introduced mac->iob_regs with the corresponding
> offset from (already ioremapped) hose->cfg_data removed the problem. So,
> it seems that dereferencing pointers based on a second ioremap on a
> subset of 0xe000_0000 addresses is problematic.
The problem is that the IOB register range is 8K, not 4K. I have since
fixed that bug but I didn't repost the patch series. It does cause weird
and strange errors to happen since register writes into the second 4K
would really go to another mapping somewhere else.
So, the quick fix is to always map 0x2000 in map_one_reg, the slightly better
one is to check the PCI dev and only map 2K for the IOB.
> Here are the questions that come to my mind:
>
> - I am testing on a A2 hw, what what your testing setup, anything
> newer than this (something closer B0 maybe), did you have a chance to
> try that on a A2 board?
I'm doing all of my work on A2 hardware at the moment.
> - Is there any particular patch or set of patches/updates that this
> patch may depend on?
There's a fix, but with the description above you should be able to handle it on your
own as well. I'm currently travelling on vacation, but I'll try to post something within
a few days.
> Switching from pci accessors to direct in_* out_* calls drops the
> guard pci spinlock. Initially, I thought that this may be the reason,
> but it's not, adding the spinlock is not solving the problem. But anyway,
> shouldn't we be using it to coordinate access?
The very point of this patch is to avoid doing the spinlock. There's no need
for one in this case, it's pure overhead.
-Olof
^ permalink raw reply
* Re: [PATCH 12/68] 0 -> NULL, for arch/powerpc
From: Paul Mackerras @ 2007-07-27 23:48 UTC (permalink / raw)
To: Yoann Padioleau; +Cc: linuxppc-dev, akpm, kernel-janitors, linux-kernel
In-Reply-To: <200707270945.LAA17267@ifs.emn.fr>
Yoann Padioleau writes:
> When comparing a pointer, it's clearer to compare it to NULL than to 0.
As other people have said, if you're going to spend time on this,
testing (!buf) is more idiomatic in the kernel than (buf == NULL).
Paul.
^ permalink raw reply
* Re: [PATCH] Re: 2.6.22-git hangs during PCMCIA on PowerBook G3 in 0.0 seconds
From: Kim Phillips @ 2007-07-27 23:29 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1185575207.5495.257.camel@localhost.localdomain>
On Sat, 28 Jul 2007 08:26:47 +1000
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> On Sat, 2007-07-28 at 00:11 +0200, Rutger Nijlunsing wrote:
> > > Kim
> > >
> > > p.s. should the stable team be notified to fix 2.6.22 for
> > > Lombard-nvram-style machines?
> >
> > Logically, yes.
> >
> Two ! Paulus has one :-) Though I'm not sure he uses it often nowadays.
>
I sent the two revert requests to the stable team.
Kim
^ permalink raw reply
* Re: [PATCH 1/2] [POWERPC] Add support of platforms without PHY to gianfar driver
From: Vitaly Bordug @ 2007-07-27 23:10 UTC (permalink / raw)
To: Kim Phillips; +Cc: linuxppc-dev, Jeff Garzik
In-Reply-To: <20070726190417.de30bed6.kim.phillips@freescale.com>
On Thu, 26 Jul 2007 19:04:17 -0500
Kim Phillips wrote:
> On Wed, 25 Jul 2007 21:43:12 +0400
> Vitaly Bordug <vitb@kernel.crashing.org> wrote:
>
> >
> > Gianfar driver is now able to work without real phy subnode,
> > that is necessary to cope with fixed-link situation, when
> > SoC is connected to the Ethernet inteface or embedded switch
> > without any PHY. In this case, fixed-speed property will
> > describe such a situation for gianfar driver.
> >
> > The property is in form <duplexity speed>
> >
> > Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
> >
> > ---
> >
> > arch/powerpc/sysdev/fsl_soc.c | 39
> > +++++++++++++++++++++++----------------
> > drivers/net/gianfar.c | 17 ++++++++++++++---
>
> please run this through checkpatch.pl until it passes.
>
> <snip>
> > + bus_id = of_get_property(np,
> > "fixed_speed",NULL);
>
> hyphens are preferred for new properties. Plus, isn't fixed-link a
> better name? unless you instead want to put speed first and make
> duplexity an optional second, or possibly even a string.
>
> Also, can we get this new property documented in b-w-of in a separate
> patch?
>
yes, fixed-link is better name.
I'll redo the patch, thx
> Kim
--
Sincerely, Vitaly
^ permalink raw reply
* Re: [PATCH 4/5] 8xx: Remove unnecessary loops_per_jiffy initialization code.
From: Vitaly Bordug @ 2007-07-27 23:06 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1185560699.8055.177.camel@ld0161-tx32>
On Fri, 27 Jul 2007 13:24:59 -0500
Jon Loeliger wrote:
> Signed-off-by: Jon Loeliger <jdl@freescale.com>
Acked-by: Vitaly Bordug <vitb@kernel.crashing.org>
--
Sincerely, Vitaly
^ permalink raw reply
* Re: [PATCH] Re: 2.6.22-git hangs during PCMCIA on PowerBook G3 in 0.0 seconds
From: Benjamin Herrenschmidt @ 2007-07-27 22:26 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070727221131.GA18273@nospam.com>
On Sat, 2007-07-28 at 00:11 +0200, Rutger Nijlunsing wrote:
> > Kim
> >
> > p.s. should the stable team be notified to fix 2.6.22 for
> > Lombard-nvram-style machines?
>
> Logically, yes.
>
> Practically it does not matter that much it seems. I've got the
> feeling the Lombard-users-group-size is about one person which is
> going to drop to zero if he doesn't get any further in being able to
> use _any_ PCMCIA card in his machine ;-)
Two ! Paulus has one :-) Though I'm not sure he uses it often nowadays.
> For example, PCMCIA (non-cardbus) does not work on Lombard since
> ~2.6.12 (2 years old bug instantly crashing the kernel!) according to
> own experiences, Google and own git-bisecting down to 2.6.13,
> compiling and running different kernels. 2.6.12 appears to require the
> 'old-style' PCMCIA tools, which I do not have installed and is
> therefore impossible for me to test.
Hrm. If Paul brings his Lombard to work next week, I can have a look.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 5/5] embedded6xx: Remove unnecessary loops_per_jiffy initialization code.
From: Mark A. Greer @ 2007-07-27 22:28 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1185560709.8055.178.camel@ld0161-tx32>
On Fri, Jul 27, 2007 at 01:25:09PM -0500, Jon Loeliger wrote:
> Signed-off-by: Jon Loeliger <jdl@freescale.com>
FWIW for the prpmc2800 part...
Acked-by: Mark A. Greer <mgreer@mvista.com>
^ permalink raw reply
* Re: [PATCH] Re: 2.6.22-git hangs during PCMCIA on PowerBook G3 in 0.0 seconds
From: Rutger Nijlunsing @ 2007-07-27 22:11 UTC (permalink / raw)
To: Kim Phillips; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070726162921.a60c76ae.kim.phillips@freescale.com>
> Kim
>
> p.s. should the stable team be notified to fix 2.6.22 for
> Lombard-nvram-style machines?
Logically, yes.
Practically it does not matter that much it seems. I've got the
feeling the Lombard-users-group-size is about one person which is
going to drop to zero if he doesn't get any further in being able to
use _any_ PCMCIA card in his machine ;-)
For example, PCMCIA (non-cardbus) does not work on Lombard since
~2.6.12 (2 years old bug instantly crashing the kernel!) according to
own experiences, Google and own git-bisecting down to 2.6.13,
compiling and running different kernels. 2.6.12 appears to require the
'old-style' PCMCIA tools, which I do not have installed and is
therefore impossible for me to test.
Links:
2.6.12 works with PCMCIA on Lombard:
http://www.mascanc.net/~vieri/gnumela.html
2.6.13 dead
(checked with git)
2.6.15 dead (Lombard PCMCIA problems in FC5):
http://forums.fedoraforum.org/archive/index.php/t-110657.html
2.6.18 dead, 2.6.12 works:
http://lists.infradead.org/pipermail/linux-pcmcia/2006-October/004051.html
2.6.19 dead (own bug report):
http://ozlabs.org/pipermail/linuxppc-dev/2006-November/028617.html
2.6.20 dead:
http://lists.infradead.org/pipermail/linux-pcmcia/2007-April/004500.html
2.6.22 dead (own bug report #2):
http://ozlabs.org/pipermail/linuxppc-dev/2007-July/039863.html
The initial reason to bisect to the now-reverting patch was to get a
working Lombard. I'd like to get this working or to help out in any
way, but I don't know how to proceed...
--
Rutger Nijlunsing ---------------------------------- eludias ed dse.nl
never attribute to a conspiracy which can be explained by incompetence
----------------------------------------------------------------------
^ permalink raw reply
* Re: [RFC 0/1] lro: Generic Large Receive Offload for TCP traffic
From: Andrew Gallatin @ 2007-07-27 19:47 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: Thomas Klein, Jeff Garzik, Jan-Bernd Themann, netdev,
linux-kernel, linux-ppc, Christoph Raisch, Marcus Eder,
Stefan Roscher, David Miller
In-Reply-To: <200707271418.49781.ossthema@de.ibm.com>
Jan-Bernd Themann wrote:
> On Wednesday 25 July 2007 19:17, Andrew Gallatin wrote:
>> 3) Padded frames.
>>
>> I may be missing something, but I don't see where you
>> either strip padding from frames or reject padded frames.
>> (see the pskb_trim_rcsum() in net/ipv4/ip_input.c:ip_rcv()
>>
> I think I missed something :-) Will fix that.
> In lro_tcp_ip_check we check for the "SKB aggregation interface"
> the skb->len against ip->tot_len. This catches padded frames as
> eth_type_trans(skb, dev) reduces the length of the SKB.
> However, the possible VLAN header is not taken into account.
> And for the "receive in pages" interface a wrong length is passed
> as argument as well.
>
> I'd suggest to reject padded frames for aggregation as we do now
> (when bugs are fixed) and thus keep the code simple.
> I guess that padded frames don't occur too often in high load
> situations. If we detect a real performance issue we can still
> change that later.
The one case where performance may be at issue is in aggregating Acks
on connections w/o TCP timestamps where a frame size of 54 bytes is
padded out to 60. I did some very quick measurements using netperf
-tTCP_SENDFILE on the same athlons mentioned earlier using our 1.3.1
driver. I see a roughly 8% CPU increase (~17% -> ~25%) when I disable
LRO (and hence Ack aggregation) on the sender. This works out to an
increase in service demand from ~0.3 to ~0.44 according to netperf.
With LRO enabled, our counters show we're aggregating acks at a
roughly 3:1 ratio. This is probably an optimization that can be done
later, but it is helpful.
This reminds me.. what would you think about adding some sort of
counters, ideally per-interface, to expose how well LRO is working?
At the simplest level, you could add them to the lro mgr struct and
let drivers export them via ethtool. I think a central approach might
be more appropriate. At any rate, I'd prefer the final
version to at least have counters to indicate how many packets were
aggregated, how many packets were flushed, and how many times we
failed to aggregate something due to insufficient net_lro_desc
descriptors.
Thanks again for taking the lead on this,
Drew
^ permalink raw reply
* Re: help with ppc sections?
From: Chris Friesen @ 2007-07-27 18:55 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40707261255x23b06ff4y5fe1527f72c09c5b@mail.gmail.com>
Grant Likely wrote:
> Mild question; What the *@*#^$! are you doing trying to backport to a
> 2 year old kernel?!? :-)
That's what happens in the embedded space. It's the current version
from our distro vendor. It's also the version that all our different
board suppliers could agree to provide support for.
Of course, it's also a royal pain.
>> Unfortunately for me, ppc doesn't have a ".section" line in that macro,
>> so I'm at a bit of a loss.
> Just add the section. Should be trivial to do. You might have to add
> it to the linker script as well.
I've done the linker script part already. As for the processor.h bit,
does this seem reasonable? It seems to do the trick based on the
function addresses, but I may be missing something and I haven't
actually booted it yet.
The ppc64 version appends ',"a"' to the kprobes.text section line. Is
this needed here as well? Could someone elaborate on exactly what its
purpose is?
Thanks,
Chris
Index: linux-ias/include/asm-ppc/processor.h
===================================================================
--- linux-ias.orig/include/asm-ppc/processor.h
+++ linux-ias/include/asm-ppc/processor.h
@@ -38,6 +38,13 @@
#define _GLOBAL(n)\
.stabs __stringify(n:F-1),N_FUN,0,0,n;\
+ .section ".text"; \
+ .globl n;\
+n:
+
+#define _KPROBE(n)\
+ .stabs __stringify(n:F-1),N_FUN,0,0,n;\
+ .section ".kprobes.text","a"; \
.globl n;\
n:
^ permalink raw reply
* [PATCH 5/5] embedded6xx: Remove unnecessary loops_per_jiffy initialization code.
From: Jon Loeliger @ 2007-07-27 18:25 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
arch/powerpc/platforms/embedded6xx/holly.c | 12 ------------
arch/powerpc/platforms/embedded6xx/prpmc2800.c | 7 -------
2 files changed, 0 insertions(+), 19 deletions(-)
diff --git a/arch/powerpc/platforms/embedded6xx/holly.c b/arch/powerpc/platforms/embedded6xx/holly.c
index 6292e36..7662091 100644
--- a/arch/powerpc/platforms/embedded6xx/holly.c
+++ b/arch/powerpc/platforms/embedded6xx/holly.c
@@ -113,23 +113,11 @@ static void holly_remap_bridge(void)
static void __init holly_setup_arch(void)
{
- struct device_node *cpu;
struct device_node *np;
if (ppc_md.progress)
ppc_md.progress("holly_setup_arch():set_bridge", 0);
- cpu = of_find_node_by_type(NULL, "cpu");
- if (cpu) {
- const unsigned int *fp;
-
- fp = of_get_property(cpu, "clock-frequency", NULL);
- if (fp)
- loops_per_jiffy = *fp / HZ;
- else
- loops_per_jiffy = 50000000 / HZ;
- of_node_put(cpu);
- }
tsi108_csr_vir_base = get_vir_csrbase();
/* setup PCI host bridge */
diff --git a/arch/powerpc/platforms/embedded6xx/prpmc2800.c b/arch/powerpc/platforms/embedded6xx/prpmc2800.c
index 5342095..5467564 100644
--- a/arch/powerpc/platforms/embedded6xx/prpmc2800.c
+++ b/arch/powerpc/platforms/embedded6xx/prpmc2800.c
@@ -44,7 +44,6 @@ static void __init prpmc2800_setup_arch(void)
struct device_node *np;
phys_addr_t paddr;
const unsigned int *reg;
- const unsigned int *prop;
/*
* ioremap mpp and gpp registers in case they are later
@@ -62,12 +61,6 @@ static void __init prpmc2800_setup_arch(void)
of_node_put(np);
mv64x60_gpp_reg_base = ioremap(paddr, reg[1]);
- np = of_find_node_by_type(NULL, "cpu");
- prop = of_get_property(np, "clock-frequency", NULL);
- if (prop)
- loops_per_jiffy = *prop / HZ;
- of_node_put(np);
-
#ifdef CONFIG_PCI
mv64x60_pci_init();
#endif
--
1.5.0.3
^ permalink raw reply related
* [PATCH 4/5] 8xx: Remove unnecessary loops_per_jiffy initialization code.
From: Jon Loeliger @ 2007-07-27 18:24 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
arch/powerpc/platforms/8xx/mpc86xads_setup.c | 14 --------------
arch/powerpc/platforms/8xx/mpc885ads_setup.c | 14 --------------
2 files changed, 0 insertions(+), 28 deletions(-)
diff --git a/arch/powerpc/platforms/8xx/mpc86xads_setup.c b/arch/powerpc/platforms/8xx/mpc86xads_setup.c
index cf0e7bc..d881647 100644
--- a/arch/powerpc/platforms/8xx/mpc86xads_setup.c
+++ b/arch/powerpc/platforms/8xx/mpc86xads_setup.c
@@ -254,20 +254,6 @@ int platform_device_skip(const char *model, int id)
static void __init mpc86xads_setup_arch(void)
{
- struct device_node *cpu;
-
- cpu = of_find_node_by_type(NULL, "cpu");
- if (cpu != 0) {
- const unsigned int *fp;
-
- fp = of_get_property(cpu, "clock-frequency", NULL);
- if (fp != 0)
- loops_per_jiffy = *fp / HZ;
- else
- loops_per_jiffy = 50000000 / HZ;
- of_node_put(cpu);
- }
-
cpm_reset();
mpc86xads_board_setup();
diff --git a/arch/powerpc/platforms/8xx/mpc885ads_setup.c b/arch/powerpc/platforms/8xx/mpc885ads_setup.c
index 5a808d6..bd5ff7a 100644
--- a/arch/powerpc/platforms/8xx/mpc885ads_setup.c
+++ b/arch/powerpc/platforms/8xx/mpc885ads_setup.c
@@ -406,20 +406,6 @@ int platform_device_skip(const char *model, int id)
static void __init mpc885ads_setup_arch(void)
{
- struct device_node *cpu;
-
- cpu = of_find_node_by_type(NULL, "cpu");
- if (cpu != 0) {
- const unsigned int *fp;
-
- fp = of_get_property(cpu, "clock-frequency", NULL);
- if (fp != 0)
- loops_per_jiffy = *fp / HZ;
- else
- loops_per_jiffy = 50000000 / HZ;
- of_node_put(cpu);
- }
-
cpm_reset();
mpc885ads_board_setup();
--
1.5.0.3
^ permalink raw reply related
* [PATCH 3/5] 52xx: Remove unnecessary loops_per_jiffy initialization code.
From: Jon Loeliger @ 2007-07-27 18:24 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
arch/powerpc/platforms/52xx/lite5200.c | 13 ++-----------
1 files changed, 2 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/platforms/52xx/lite5200.c b/arch/powerpc/platforms/52xx/lite5200.c
index 5c46e89..84bd3da 100644
--- a/arch/powerpc/platforms/52xx/lite5200.c
+++ b/arch/powerpc/platforms/52xx/lite5200.c
@@ -109,22 +109,13 @@ static void lite5200_resume_finish(void __iomem *mbar)
static void __init lite5200_setup_arch(void)
{
+#ifdef CONFIG_PCI
struct device_node *np;
+#endif
if (ppc_md.progress)
ppc_md.progress("lite5200_setup_arch()", 0);
- np = of_find_node_by_type(NULL, "cpu");
- if (np) {
- const unsigned int *fp =
- of_get_property(np, "clock-frequency", NULL);
- if (fp != 0)
- loops_per_jiffy = *fp / HZ;
- else
- loops_per_jiffy = 50000000 / HZ;
- of_node_put(np);
- }
-
/* CPU & Port mux setup */
mpc52xx_setup_cpu(); /* Generic */
lite5200_setup_cpu(); /* Platorm specific */
--
1.5.0.3
^ permalink raw reply related
* [PATCH 2/5] 85xx: Remove unnecessary loops_per_jiffy initialization code.
From: Jon Loeliger @ 2007-07-27 18:24 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
arch/powerpc/platforms/85xx/mpc85xx_ads.c | 13 -------------
arch/powerpc/platforms/85xx/mpc85xx_cds.c | 13 -------------
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 11 -----------
3 files changed, 0 insertions(+), 37 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ads.c b/arch/powerpc/platforms/85xx/mpc85xx_ads.c
index 40a8286..c22bc1c 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_ads.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_ads.c
@@ -192,7 +192,6 @@ void init_fcc_ioports(struct fs_platform_info *fpi)
static void __init mpc85xx_ads_setup_arch(void)
{
- struct device_node *cpu;
#ifdef CONFIG_PCI
struct device_node *np;
#endif
@@ -200,18 +199,6 @@ static void __init mpc85xx_ads_setup_arch(void)
if (ppc_md.progress)
ppc_md.progress("mpc85xx_ads_setup_arch()", 0);
- cpu = of_find_node_by_type(NULL, "cpu");
- if (cpu != 0) {
- const unsigned int *fp;
-
- fp = of_get_property(cpu, "clock-frequency", NULL);
- if (fp != 0)
- loops_per_jiffy = *fp / HZ;
- else
- loops_per_jiffy = 50000000 / HZ;
- of_node_put(cpu);
- }
-
#ifdef CONFIG_CPM2
cpm2_reset();
#endif
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_cds.c b/arch/powerpc/platforms/85xx/mpc85xx_cds.c
index 6a171e9..44f9cdb 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_cds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_cds.c
@@ -266,7 +266,6 @@ device_initcall(mpc85xx_cds_8259_attach);
*/
static void __init mpc85xx_cds_setup_arch(void)
{
- struct device_node *cpu;
#ifdef CONFIG_PCI
struct device_node *np;
#endif
@@ -274,18 +273,6 @@ static void __init mpc85xx_cds_setup_arch(void)
if (ppc_md.progress)
ppc_md.progress("mpc85xx_cds_setup_arch()", 0);
- cpu = of_find_node_by_type(NULL, "cpu");
- if (cpu != 0) {
- const unsigned int *fp;
-
- fp = of_get_property(cpu, "clock-frequency", NULL);
- if (fp != 0)
- loops_per_jiffy = *fp / HZ;
- else
- loops_per_jiffy = 500000000 / HZ;
- of_node_put(cpu);
- }
-
cadmus = ioremap(CADMUS_BASE, CADMUS_SIZE);
cds_pci_slot = ((cadmus[CM_CSR] >> 6) & 0x3) + 1;
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_mds.c b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
index e8003bf..d0e3153 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
@@ -73,17 +73,6 @@ static void __init mpc85xx_mds_setup_arch(void)
if (ppc_md.progress)
ppc_md.progress("mpc85xx_mds_setup_arch()", 0);
- np = of_find_node_by_type(NULL, "cpu");
- if (np != NULL) {
- const unsigned int *fp =
- of_get_property(np, "clock-frequency", NULL);
- if (fp != NULL)
- loops_per_jiffy = *fp / HZ;
- else
- loops_per_jiffy = 50000000 / HZ;
- of_node_put(np);
- }
-
/* Map BCSR area */
np = of_find_node_by_name(NULL, "bcsr");
if (np != NULL) {
--
1.5.0.3
^ permalink raw reply related
* [PATCH 1/5] 86xx: Remove unnecessary loops_per_jiffy initialization code.
From: Jon Loeliger @ 2007-07-27 18:24 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
Note -- This is a rebased version of an earlier patch
from July 17. That one can be dropped.
arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 14 ++------------
1 files changed, 2 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c b/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
index e9eaa07..de90e6a 100644
--- a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
+++ b/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
@@ -327,23 +327,13 @@ DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_AL, 0x5249, early_uli5249);
static void __init
mpc86xx_hpcn_setup_arch(void)
{
+#ifdef CONFIG_PCI
struct device_node *np;
+#endif
if (ppc_md.progress)
ppc_md.progress("mpc86xx_hpcn_setup_arch()", 0);
- np = of_find_node_by_type(NULL, "cpu");
- if (np != 0) {
- const unsigned int *fp;
-
- fp = of_get_property(np, "clock-frequency", NULL);
- if (fp != 0)
- loops_per_jiffy = *fp / HZ;
- else
- loops_per_jiffy = 50000000 / HZ;
- of_node_put(np);
- }
-
#ifdef CONFIG_PCI
for (np = NULL; (np = of_find_node_by_type(np, "pci")) != NULL;) {
struct resource rsrc;
--
1.5.0.3
^ permalink raw reply related
* [PATCH 0/5] Remove unnecessary loops_per_jiffy initialization code
From: Jon Loeliger @ 2007-07-27 18:23 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
This patch series removes lingering jiffies initialization
code from several platforms. Note that the first patch in
this series for the 86xx has been rebased to current top of
Paul's repository and replaces an earlier version.
arch/powerpc/platforms/52xx/lite5200.c | 13 ++-----------
arch/powerpc/platforms/85xx/mpc85xx_ads.c | 13 -------------
arch/powerpc/platforms/85xx/mpc85xx_cds.c | 13 -------------
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 11 -----------
arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 14 ++------------
arch/powerpc/platforms/8xx/mpc86xads_setup.c | 14 --------------
arch/powerpc/platforms/8xx/mpc885ads_setup.c | 14 --------------
arch/powerpc/platforms/embedded6xx/holly.c | 12 ------------
arch/powerpc/platforms/embedded6xx/prpmc2800.c | 7 -------
9 files changed, 4 insertions(+), 107 deletions(-)
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox