On Fri, Mar 21, 2008 at 01:09:41AM -0400, Sean MacLennan wrote:
> On Thu, 20 Mar 2008 22:34:21 -0600
> "Grant Likely" <[EMAIL PROTECTED]> wrote:
>
> > Convention is to use the stock ticker symbol. If the company is
> > private and has no stock ticker symbol, then the company name should
> > be us
On Wed, 2008-03-19 at 17:15 +0100, Stefan Roese wrote:
> + [EMAIL PROTECTED] {
> + device_type = "cpu";
> + model = "PowerPC,460GT";
> + reg = <0>;
>
I wonder if we should do something here to differenciate the SoC c
Grant Likely writes:
> Confirmed, this patch fixes the problem. Paulus or Kumar, can you
> please pick it up for .25?
Sure, will do. I thought about putting it in the last batch but I
wanted an ack from you.
Anyone else got any last-minute things for 2.6.25?
Paul.
Grant Likely writes:
> Personally, I'm not fond of this approach. There is already some
> traction to using the reg-shift property to specify spacing, and I
> think it would be appropriate to also define a reg-offset property to
> handle the +3 offset and then let the xilinx 16550 nodes use those
On Fri, 21 Mar 2008, Paul Mackerras wrote:
> Grant Likely writes:
>
> > Confirmed, this patch fixes the problem. Paulus or Kumar, can you
> > please pick it up for .25?
>
> Sure, will do. I thought about putting it in the last batch but I
> wanted an ack from you.
>
> Anyone else got any last-mi
Is there any reason not use use _stext?
- k
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index cd870a8..b0989ca 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -277,7 +277,7 @@ void __init setup_arch(char **cmdline_p)
if
Sudhir Kumar writes:
> > I suggest you turn off CONFIG_SENSORS_F71805F.
> It was a new feature so I turned it on while compiling.
> I have tried by turning off CONFIG_SENSORS_F71805F but the bug
> is still present.
Do you mean that you still saw a crash in f71805f_find? If so, then
you have some
There does not appear to be any reason that we shouldn't just have
-Iarch/$(ARCH) on both ppc32 and ppc64 builds.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
arch/powerpc/Makefile | 10 --
1 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/Makefile b/arch/
On Friday 21 March 2008, Benjamin Herrenschmidt wrote:
> On Wed, 2008-03-19 at 17:15 +0100, Stefan Roese wrote:
> > + [EMAIL PROTECTED] {
> > + device_type = "cpu";
> > + model = "PowerPC,460GT";
> > + reg = <0>;
>
> I
On Thu, 2008-03-20 at 11:32 +, Matt Sealey wrote:
> subsys_initcall(init_ipic_sysfs); <-- this, in my eyes, is the culprit. If
> init_ipic() runs, init_ipic_sysfs should be called from that, not left for
> some further subsystem to blindly try and register sysfs nodes for devices
> which may n
I wondered about this. Since the AD from Analog Devices is built into
the part number, I didn't know if it was needed. And analog-devices
is
pretty long ;)
But I am willing to put it in if it is necessary.
Convention is to use the stock ticker symbol. If the company is
private and has no
Convention is to use the stock ticker symbol. If the company is
private and has no stock ticker symbol, then the company name should
be used.
I didn't know that. ADI it is then.
Well.. stock ticker is the new convention. IEEE1275 used IEEE
assigned OUI strings (Organization Unique Identifier
Personally, I'm not fond of this approach. There is already some
traction to using the reg-shift property to specify spacing, and I
think it would be appropriate to also define a reg-offset property to
handle the +3 offset and then let the xilinx 16550 nodes use those.
Why do we need a reg-offs
As for the DTS, maybe a "compatible" property in the CPU might make
some
sense with a content along the lines of "ppc440x6" or whatever rev of
the 440 core it is.
Good idea, but please _also_ put the exact name in there, first; so
something like
compatible = "AMCC,PowerPC,460GT", "AMCC
On Fri, 2008-03-21 at 12:46 +0100, Segher Boessenkool wrote:
> > As for the DTS, maybe a "compatible" property in the CPU might make
> > some
> > sense with a content along the lines of "ppc440x6" or whatever rev of
> > the 440 core it is.
>
> Good idea, but please _also_ put the exact name in t
BTW, Should we sort compatible from the most specific to the most
specific or the other way around ?
Most specific first.
Segher
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
On Fri, 21 Mar 2008 11:54:33 +0100
Stefan Roese <[EMAIL PROTECTED]> wrote:
> On Friday 21 March 2008, Benjamin Herrenschmidt wrote:
> > On Wed, 2008-03-19 at 17:15 +0100, Stefan Roese wrote:
> > > + [EMAIL PROTECTED] {
> > > + device_type = "cpu";
> > > +
Hello.
Grant Likely wrote:
On Thu, Mar 20, 2008 at 8:43 AM, John Linn <[EMAIL PROTECTED]> wrote:
The Xilinx 16550 uart core is not a standard 16550, because it uses
word-based addressing rather than byte-based addressing. As a result,
it is not compatible with the open firmware 'ns16550' co
Is the MPC5200B PSC-AC97 driver in there?
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
Paul Mackerras wrote:
Grant Likely writes:
Confirmed, this patch fixes the problem. Paulus or Kumar, can you
please pick it up for .25?
Sure, will do. I thought about putting
On Fri, Mar 21, 2008 at 02:50:01PM +0100, Thomas Gleixner wrote:
> What about adding a CONFIG_ARCH_HAS_PTRACE2, which is set by the archs
> which are converted. For those which are not you add a fallback
> implementation:
Bah. Folks, we're talking about adding a single new argument to a
single fu
On Fri, Mar 21, 2008 at 02:50:01PM +0100, Thomas Gleixner wrote:
> On Thu, 20 Mar 2008, Roland McGrath wrote:
> > > Wouldn't it be nicer to just let "arch_ptrace()" return a flag saying
> > > whether it handled things or not?
> >
> > It would certainly be nicer. I would prefer:
> >
> > extern i
On Thu, 20 Mar 2008, Roland McGrath wrote:
> > Wouldn't it be nicer to just let "arch_ptrace()" return a flag saying
> > whether it handled things or not?
>
> It would certainly be nicer. I would prefer:
>
> extern int arch_ptrace(struct task_struct *child, long request,
>
On Thu, 20 Mar 2008, Roland McGrath wrote:
>
> The motivation is to get the arch function out of the code path for the
> machine-independent request handling. I want to be able to change the
> implementation later without touching the arch code again.
If there is no stronger motivation than
Badari-san.
> Index: linux-2.6.25-rc2/mm/memory_hotplug.c
> ===
> --- linux-2.6.25-rc2.orig/mm/memory_hotplug.c 2008-02-27 12:58:17.0
> -0800
> +++ linux-2.6.25-rc2/mm/memory_hotplug.c 2008-02-27 16:06:50.0
> -
Personally, I'm not fond of this approach. There is already some
traction to using the reg-shift property to specify spacing, and I
think it would be appropriate to also define a reg-offset property to
handle the +3 offset and then let the xilinx 16550 nodes use those.
That's making things o
Hello.
Segher Boessenkool wrote:
Personally, I'm not fond of this approach. There is already some
traction to using the reg-shift property to specify spacing, and I
think it would be appropriate to also define a reg-offset property to
handle the +3 offset and then let the xilinx 16550 nodes us
On Sat, 2008-03-22 at 00:25 +0900, Yasunori Goto wrote:
> Badari-san.
>
> > Index: linux-2.6.25-rc2/mm/memory_hotplug.c
> > ===
> > --- linux-2.6.25-rc2.orig/mm/memory_hotplug.c 2008-02-27
> > 12:58:17.0 -0800
> > +++ l
I thought about this, and reconsidered it again after I finally figured
out how to get the Power.org website to relenquish the ePAPR spec, which
(FWIW) has reg-shift as an optional property of the ns16550 binding.
However, I'm not enamoured of it, since I doubt it's really good to be
doing iorema
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > The reason I took the approach I did instead is incrementalism. I
> > can't change that signature without breaking about 22 arch builds.
>
> Don't worry about the arch builds. If that's your main worry and
> reason for this, it's not worth it. Ye
Andrew Morton wrote:
>> +static struct diu_hw dr = {
>> +.mode = MFB_MODE1,
>> +.reg_lock = __SPIN_LOCK_UNLOCKED(old_style_spin_init),
>> +};
>
> I'm not clear on what's supposed to happen with __SPIN_LOCK_UNLOCKED(). I
> do know that its documentation is crap.
Yes, "__SPIN_LOCK_UNLOCKE
> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:linuxppc-dev-
> [EMAIL PROTECTED] On Behalf Of Grant
Likely
> Sent: Thursday, March 20, 2008 5:19 PM
> To: John Linn
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH 2/3] [POWERPC] Xilinx: of_serial support for
Xilinx uart16550.
>
On Thu, Mar 20, 2008 at 07:59:41PM -0400, Jerry Van Baren wrote:
> Per Andy (and my limited reading of the UMs), some 83xx have the PMR
> registers and some don't. The compiler either supports the PMR register
> or it doesn't. If you make it runtime configurable, people running CPUs
> that
The proposed use clearly would treat them as generic, since in the
context of the Xilinx UART they're just not needed -- it's known
beforehand and most probably fixed how/where the registers are mapped.
There's just no need for such info in the device tree -- unless you're
going to teach the
I thought about this, and reconsidered it again after I finally figured
out how to get the Power.org website to relenquish the ePAPR spec,
which
(FWIW) has reg-shift as an optional property of the ns16550 binding.
However, I'm not enamoured of it, since I doubt it's really good to be
doing iore
> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:linuxppc-dev-
> [EMAIL PROTECTED] On Behalf Of
Segher Boessenkool
> Sent: Friday, March 21, 2008 9:46 AM
> To: Sergei Shtylyov
> Cc: linuxppc-dev@ozlabs.org; John Linn
> Subject: Re: [PATCH 2/3] [POWERPC] Xilinx: of_serial support for
Segher Boessenkool wrote:
The proposed use clearly would treat them as generic, since in the
context of the Xilinx UART they're just not needed -- it's known
beforehand and most probably fixed how/where the registers are mapped.
There's just no need for such info in the device tree -- unles
As for the DTS, maybe a "compatible" property in the CPU might make
some
sense with a content along the lines of "ppc440x6" or whatever rev of
the 440 core it is.
What do you think ?
Good idea. I'll try to come up with a list for all existing 4xx SoC's
and it's
core versions.
I don't reall
On Fri, 21 Mar 2008 11:12:30 -0500 Timur Tabi <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
>
> >> +static struct diu_hw dr = {
> >> + .mode = MFB_MODE1,
> >> + .reg_lock = __SPIN_LOCK_UNLOCKED(old_style_spin_init),
> >> +};
> >
> > I'm not clear on what's supposed to happen with __SPIN_LO
On Fri, Mar 21, 2008 at 7:14 AM, Matt Sealey <[EMAIL PROTECTED]> wrote:
> Is the MPC5200B PSC-AC97 driver in there?
Audio drivers need to go in via one of the ALSA developers and I
haven't been paying close enough attention to know if it has not in
yet.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret
On Fri, Mar 21, 2008 at 12:30 AM, Wolfgang Grandegger <[EMAIL PROTECTED]> wrote:
> Bartlomiej Sieka wrote:
> > Grant Likely wrote:
> >> Paul, my git server is down at the moment. Can you please pick this
> >> one up for .25? It is needed to boot the tqm5200 board.
> >
> > Could we also have
Is anybody working on the dcr infrastructure?
In particular, there seems to be inconsistency between what the kernel
does and what ePAPR thinks it should. The code in the kernel selects
mmio or native access based on a Kconfig parameter and uses some device
tree parameters to correctly configure
On Fri, 2008-03-21 at 12:05 -0700, Stephen Neuendorffer wrote:
> Is anybody working on the dcr infrastructure?
>
> In particular, there seems to be inconsistency between what the kernel
> does and what ePAPR thinks it should. The code in the kernel selects
> mmio or native access based on a Kcon
The following series of patches implement a basic framework
for hypervisor-assisted dump. The very first patch provides
documentation explaining what this is.
A list of open issues / todo list is included in the documentation.
It also appears that the not-yet-released firmware versions this was
Basic documentation for hypervisor-assisted dump.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
Signed-off-by: Manish Ahuja <[EMAIL PROTECTED]>
---
Documentation/powerpc/phyp-assisted-dump.txt | 127 +++
1 file changed, 127 insertions(+)
Index: 2.6.25-rc1/Documentat
Initial patch for reserving memory in early boot, and freeing it later.
If the previous boot had ended with a crash, the reserved memory would contain
a copy of the crashed kernel data.
Signed-off-by: Manish Ahuja <[EMAIL PROTECTED]>
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
---
arch/pow
Check to see if there actually is data from a previously
crashed kernel waiting. If so, Allow user-sapce tools to
grab the data (by reading /proc/kcore). When user-space
finishes dumping a section, it must release that memory
by writing to sysfs. For example,
echo "0x4000 0x1000" > /sy
Set up the actual dump header, register it with the hypervisor.
Signed-off-by: Manish Ahuja <[EMAIL PROTECTED]>
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/pseries/phyp_dump.c | 137 +++--
1 file changed, 131 insertions(+), 6 deletions(-
Provide some basic debugging support.
Signed-off-by: Manish Ahuja <[EMAIL PROTECTED]>
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/pseries/phyp_dump.c | 61 -
1 file changed, 59 insertions(+), 2 deletions(-)
Index: 2.6.25-rc1/arch/p
The bulk of this patch is taken from
http://patchwork.ozlabs.org/linuxppc/patch?q=Balakowicz&id=16197, with few
other updates, in particluar one posted by Anatolij Gustschin, which fixes
an Oops during boot.
Signed-off-by: Marian Balakowicz <[EMAIL PROTECTED]>
---
Anatolij, would you like to a
Routines to
a. invalidate dump
b. Calculate region that is reserved and needs to be freed. This is
exported through sysfs interface.
Unregister has been removed for now as it wasn't being used.
Signed-off-by: Manish Ahuja <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/pseries/phyp_dump
This patch tracks the size freed. For now it does a simple
rudimentary calculation of the ranges freed. The idea is
to keep it simple at the external shell script level and
send in large chunks for now.
Signed-off-by: Manish Ahuja <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/pseries/phyp_d
Add hypervisor-assisted dump to kernel config
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
Signed-off-by: Manish Ahuja <[EMAIL PROTECTED]>
---
arch/powerpc/Kconfig | 10 ++
1 file changed, 10 insertions(+)
Index: 2.6.25-rc1/arch/powerpc/Kconfig
The goal of these 2 patches is to ensure that there is only one dumping
mechanism enabled at any given time. These patches depend upon phyp-dump
patches posted earlier.
Patch 1:
Addition of boot-variable "phyp_dump", which takes values [0/1] for disabling/
enabling phyp_dump at boot time. Kdump
Patch 2:
Addition of /sys/kernel/phyp_dump_active so that kdump init scripts may
look for it and take appropriate action if this file is found. This
file is only loaded when phyp_dump has been registered.
Signed-off-by: Manish Ahuja <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/pseries/phyp_
Bartlomiej Sieka wrote:
The bulk of this patch is taken from
http://patchwork.ozlabs.org/linuxppc/patch?q=Balakowicz&id=16197, with few
other updates, in particluar one posted by Anatolij Gustschin, which fixes
an Oops during boot.
Signed-off-by: Marian Balakowicz <[EMAIL PROTECTED]>
---
An
On Fri, 21 Mar 2008 18:28:38 +0100
Segher Boessenkool <[EMAIL PROTECTED]> wrote:
> >>> As for the DTS, maybe a "compatible" property in the CPU might make
> >>> some
> >>> sense with a content along the lines of "ppc440x6" or whatever rev of
> >>> the 440 core it is.
> >>>
> >>> What do you think
On Fri, 21 Mar 2008 12:05:40 -0700
"Stephen Neuendorffer" <[EMAIL PROTECTED]> wrote:
>
> Is anybody working on the dcr infrastructure?
>
> In particular, there seems to be inconsistency between what the kernel
> does and what ePAPR thinks it should. The code in the kernel selects
> mmio or nati
On Fri, Mar 21, 2008 at 5:56 PM, Bartlomiej Sieka <[EMAIL PROTECTED]> wrote:
> The bulk of this patch is taken from
> http://patchwork.ozlabs.org/linuxppc/patch?q=Balakowicz&id=16197, with few
> other updates, in particluar one posted by Anatolij Gustschin, which fixes
> an Oops during boot.
>
>
If the reg property is missing from the phy node (unlikely, but possible),
then the kernel will oops with a NULL pointer dereference.
Signed-off-by: Grant Likely <[EMAIL PROTECTED]>
---
This one is a bugfix that should go in for 2.6.25. Paul, can you please
pick it up?
Thanks,
g.
drivers/net/f
The MDIO node in the lite5200b.dts file needs to also claim compatibility
with the older mpc5200 chip.
Signed-off-by: Grant Likely <[EMAIL PROTECTED]>
---
Paul, this one should also go in for .26
arch/powerpc/boot/dts/lite5200b.dts |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
dif
If the bestcomm initialization fails, calls to the task allocate
function should fail gracefully instead of oopsing with a NULL deref.
Signed-off-by: Grant Likely <[EMAIL PROTECTED]>
---
Paul, here's another bug fix that I'd like picked up for .25
arch/powerpc/sysdev/bestcomm/bestcomm.c |4
On Sat, Mar 22, 2008 at 12:56:35AM +0100, Bartlomiej Sieka wrote:
> The bulk of this patch is taken from
> http://patchwork.ozlabs.org/linuxppc/patch?q=Balakowicz&id=16197, with few
> other updates, in particluar one posted by Anatolij Gustschin, which fixes
> an Oops during boot.
>
> Signed-o
On Fri, Mar 21, 2008 at 6:12 PM, David Gibson
<[EMAIL PROTECTED]> wrote:
> On Sat, Mar 22, 2008 at 12:56:35AM +0100, Bartlomiej Sieka wrote:
> > diff --git a/arch/powerpc/boot/dts/cm5200.dts
> b/arch/powerpc/boot/dts/cm5200.dts
> > index 30737ea..8b2e8e4 100644
> > --- a/arch/powerpc/boot/dts/c
63 matches
Mail list logo
