* Re: crash in init_ipic_sysfs on efika
From: Sven Luther @ 2008-03-22 15:25 UTC (permalink / raw)
To: Grant Likely; +Cc: Olaf Hering, sven, Paul Mackerras, linuxppc-dev
In-Reply-To: <fa686aa40803211151w688a8d61sba9d0d0e6cdc7833@mail.gmail.com>
On Fri, Mar 21, 2008 at 12:51:46PM -0600, Grant Likely wrote:
> On Fri, Mar 21, 2008 at 7:14 AM, Matt Sealey <matt@genesi-usa.com> 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.
BTW, it was reported to me that the ethernet drivers don't get
autoloaded by udev. Is this a failure of udev missing the of_plateform
support, or a deficiency of the ethernet drivers ?
Friendly,
Sven Luther
^ permalink raw reply
* Re: [PATCH 2/3] [POWERPC] Xilinx: of_serial support for Xilinx uart 16550.
From: Sergei Shtylyov @ 2008-03-22 16:06 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Paul Mackerras, John Linn
In-Reply-To: <fa686aa40803220750h1d86589am9a26aeeb359178b7@mail.gmail.com>
Grant Likely 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 use those.
>> Why do we need a reg-offset property when we can just add the offset
>> to the appropriate word(s) in the reg property?
> Primarily because the device creates 32 byte registers starting at 0;
> but they are also big-endian byte accessible so a byte read at offset
> 8 also works. reg-offset seems to be a better description of the
> hardware to me.
Ugh... I was just going is it possible to access the chip registers as
32-bit entities, and employ UPIO_MEM32 mode of 8250.c -- just to avoid that
reg-offset wart. Now you're telling everybody that it's completely
superfluous... :-)
> Cheers,
> g.
WBR, Sergei
^ permalink raw reply
* Re: [PATCH 2/3] [POWERPC] Xilinx: of_serial support for Xilinx uart 16550.
From: Sergei Shtylyov @ 2008-03-22 16:40 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, John Linn
In-Reply-To: <fa686aa40803220806w3288ab8ew754404a5aee152cf@mail.gmail.com>
Grant Likely 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 use those.
>> That's making things only worse than the mere "reg-shift" idea. I think
>> that both are totally wrong. Everything about the programming interface should
>> be said in the "compatible" and possibly "model" properties. of_serial driver
>> should recognize them and pass the necessary details to 8250.c. As for me, I'm
>> strongly against plaguing the device tree with the *Linux driver
>> implementation specifics* (despite I was trying this with MTD -- there it
>> seemed somewhat more grounded :-).
> Not true. Compatible defines what the node is describing. It is
> perfectly valid for a compatible value definition to also defines some
> additional properties that can be queried for interface details.
> Xilinx is completely free to define a "xlnx,..." compatible value for
> their ns16550 compatible device. However, 'sparse' ns16550 devices
> are a common and well known variation so I think it is valid and
> reasonable to define a compatible binding for this case.
We have been mostly talking about the 16550-compatible devices which
external circuitry makes "sparse" so far. This is surely not a property of a
16550 device to be "sparse" or not, although some say that this doesn't
matter. :-)
> As for using a new binding like "sparse16550" instead of extending
That "sparse16550" again... what if it's a superset of 16550 (not an
uncommon case too), will you also define "sparce16650", "sparse16570", and so
on? :-)
> "ns16550"; it is because reg-shift and reg-offset would be required
> nodes and therefore is not compatible with drivers using the original
> ns16550 binding. Using a new namespace gives freedom to define the
> required properties.
You'll have to define several namespaces I'm afraid...
> Cheers,
> g.
WBR, Sergei
^ permalink raw reply
* [PATCH] POWERPC: Move a.out.h to header-y since it doesn't check __KERNEL__.
From: Robert P. J. Day @ 2008-03-22 19:05 UTC (permalink / raw)
To: Linux PPC Mailing List
Since a.out.h doesn't check the value of __KERNEL__, there's no point
in unifdef'ing it.
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
---
diff --git a/include/asm-powerpc/Kbuild b/include/asm-powerpc/Kbuild
index 5f640e5..7381916 100644
--- a/include/asm-powerpc/Kbuild
+++ b/include/asm-powerpc/Kbuild
@@ -1,5 +1,6 @@
include include/asm-generic/Kbuild.asm
+header-y += a.out.h
header-y += auxvec.h
header-y += ioctls.h
header-y += mman.h
@@ -23,7 +24,6 @@ header-y += sigcontext.h
header-y += statfs.h
header-y += ps3fb.h
-unifdef-y += a.out.h
unifdef-y += asm-compat.h
unifdef-y += bootx.h
unifdef-y += byteorder.h
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
Have classroom, will lecture.
http://crashcourse.ca Waterloo, Ontario, CANADA
========================================================================
^ permalink raw reply related
* Re: [PATCH] windfarm: add PowerMac 12,1 support
From: David Woodhouse @ 2008-03-22 19:35 UTC (permalink / raw)
To: Étienne Bersac; +Cc: linuxppc-dev
In-Reply-To: <1201348525.6859.1.camel@thilivren>
On Sat, 2008-01-26 at 12:55 +0100, Étienne Bersac wrote:
> From: Étienne Bersac <bersace@gmail.com>
>
> Implement a new driver named windfarm_pm121 which drive fans on PowerMac
> 12,1 machine : iMac G5 iSight (rev C) 17" and 20". It's based on
> windfarm_pm81 driver from Benjamin Herrenschmidt.
Is it just coincidence, or does it only seem to stop the fans when I
cat /sys/devices/platform/windfarm.0/cpu-temp ?
--
dwmw2
^ permalink raw reply
* Re: [PATCH] windfarm: add PowerMac 12,1 support
From: Benjamin Herrenschmidt @ 2008-03-22 22:13 UTC (permalink / raw)
To: David Woodhouse; +Cc: Étienne Bersac, linuxppc-dev
In-Reply-To: <1206214508.9540.89.camel@pmac.infradead.org>
On Sat, 2008-03-22 at 19:35 +0000, David Woodhouse wrote:
> On Sat, 2008-01-26 at 12:55 +0100, Étienne Bersac wrote:
> > From: Étienne Bersac <bersace@gmail.com>
> >
> > Implement a new driver named windfarm_pm121 which drive fans on PowerMac
> > 12,1 machine : iMac G5 iSight (rev C) 17" and 20". It's based on
> > windfarm_pm81 driver from Benjamin Herrenschmidt.
>
> Is it just coincidence, or does it only seem to stop the fans when I
> cat /sys/devices/platform/windfarm.0/cpu-temp ?
Is it actually working ?
If the SMU thinks there is no fan control done by the OS, it will ramp
them up ... but bring them back down when it gets ping.
So if for some reason the control loop isn't starting (because it can't
find something it wants on this machine), the fans will stay up, but
you'll cause such a "ping" when reading the CPU temp.
That may be bogus, just thinking what it could be...
Ben.
^ permalink raw reply
* Re: [PATCH] windfarm: add PowerMac 12,1 support
From: David Woodhouse @ 2008-03-22 23:02 UTC (permalink / raw)
To: benh; +Cc: Étienne Bersac, linuxppc-dev
In-Reply-To: <1206223998.7197.13.camel@pasglop>
On Sun, 2008-03-23 at 09:13 +1100, Benjamin Herrenschmidt wrote:
> On Sat, 2008-03-22 at 19:35 +0000, David Woodhouse wrote:
> > On Sat, 2008-01-26 at 12:55 +0100, Étienne Bersac wrote:
> > > From: Étienne Bersac <bersace@gmail.com>
> > >
> > > Implement a new driver named windfarm_pm121 which drive fans on PowerMac
> > > 12,1 machine : iMac G5 iSight (rev C) 17" and 20". It's based on
> > > windfarm_pm81 driver from Benjamin Herrenschmidt.
> >
> > Is it just coincidence, or does it only seem to stop the fans when I
> > cat /sys/devices/platform/windfarm.0/cpu-temp ?
>
> Is it actually working ?
>
> If the SMU thinks there is no fan control done by the OS, it will ramp
> them up ... but bring them back down when it gets ping.
>
> So if for some reason the control loop isn't starting (because it can't
> find something it wants on this machine), the fans will stay up, but
> you'll cause such a "ping" when reading the CPU temp.
Yeah, there's weird shit going on with the sensor/control registration.
I think GCC is be miscompiling it -- the sequence of
all = all && pm121_register_control(foo...);
all = all && pm121_register_control(bar...);
is bailing out as soon as 'all' gets set to zero. Despite the fact that
pm121_register_control() quite blatantly has side-effects.
--
dwmw2
^ permalink raw reply
* Re: [PATCH] windfarm: add PowerMac 12,1 support
From: David Woodhouse @ 2008-03-22 23:14 UTC (permalink / raw)
To: benh; +Cc: Étienne Bersac, linuxppc-dev
In-Reply-To: <1206226966.9540.104.camel@pmac.infradead.org>
On Sat, 2008-03-22 at 23:02 +0000, David Woodhouse wrote:
>
> Yeah, there's weird shit going on with the sensor/control
> registration.
> I think GCC is be miscompiling it -- the sequence of
> all = all && pm121_register_control(foo...);
> all = all && pm121_register_control(bar...);
> is bailing out as soon as 'all' gets set to zero. Despite the fact
> that pm121_register_control() quite blatantly has side-effects.
That's after I fix the names in pm121_new_control() and fix
pm121_register_control() to set controls[id] instead of always setting
controls[FAN_OD], btw. Without that I don't think it could ever have
worked.
But it's still broken. I'll try to cut it down and file a GCC bug...
.pm121_new_control:
.LFB929:
.loc 1 883 0
.LVL44:
mflr 0
.LCFI38:
std 0,16(1)
.LCFI39:
std 30,-16(1)
.LCFI40:
std 31,-8(1)
.LCFI41:
stdu 1,-128(1)
.LCFI42:
ld 30,.LCTOC0@toc(2)
mr 31,3
.loc 1 886 0
ld 9,.LC47-.LCTOC1(30)
lwz 0,48(9)
cmpwi 7,0,0
bne 7,.L31
.LVL45:
.loc 1 889 0
ld 4,.LC49-.LCTOC1(30)
li 5,2
bl .pm121_register_control
cmpdi 7,3,0
beq 7,.L31
.loc 1 890 0
mr 3,31
ld 4,.LC51-.LCTOC1(30)
li 5,1
bl .pm121_register_control
cmpdi 7,3,0
beq 7,.L31
.loc 1 891 0
mr 3,31
ld 4,.LC53-.LCTOC1(30)
li 5,0
bl .pm121_register_control
cmpdi 7,3,0
beq 7,.L31
.loc 1 892 0
mr 3,31
ld 4,.LC55-.LCTOC1(30)
li 5,3
bl .pm121_register_control
cmpdi 7,3,0
beq 7,.L31
.loc 1 895 0
ld 3,.LC57-.LCTOC1(30)
bl .printk
nop
.loc 1 896 0
ld 9,.LC47-.LCTOC1(30)
li 0,1
stw 0,48(9)
.LVL46:
.L31:
.loc 1 898 0
addi 1,1,128
ld 0,16(1)
mtlr 0
ld 30,-16(1)
ld 31,-8(1)
.LVL47:
blr
--
dwmw2
^ permalink raw reply
* Re: [PATCH] windfarm: add PowerMac 12,1 support
From: Benjamin Herrenschmidt @ 2008-03-22 23:25 UTC (permalink / raw)
To: David Woodhouse; +Cc: Étienne Bersac, linuxppc-dev
In-Reply-To: <1206227641.9540.108.camel@pmac.infradead.org>
On Sat, 2008-03-22 at 23:14 +0000, David Woodhouse wrote:
> On Sat, 2008-03-22 at 23:02 +0000, David Woodhouse wrote:
> >
> > Yeah, there's weird shit going on with the sensor/control
> > registration.
> > I think GCC is be miscompiling it -- the sequence of
> > all = all && pm121_register_control(foo...);
> > all = all && pm121_register_control(bar...);
> > is bailing out as soon as 'all' gets set to zero. Despite the fact
> > that pm121_register_control() quite blatantly has side-effects.
And it's just supposed to do that no ?
Ben.
> That's after I fix the names in pm121_new_control() and fix
> pm121_register_control() to set controls[id] instead of always setting
> controls[FAN_OD], btw. Without that I don't think it could ever have
> worked.
>
> But it's still broken. I'll try to cut it down and file a GCC bug...
>
> .pm121_new_control:
> .LFB929:
> .loc 1 883 0
> .LVL44:
> mflr 0
> .LCFI38:
> std 0,16(1)
> .LCFI39:
> std 30,-16(1)
> .LCFI40:
> std 31,-8(1)
> .LCFI41:
> stdu 1,-128(1)
> .LCFI42:
> ld 30,.LCTOC0@toc(2)
> mr 31,3
> .loc 1 886 0
> ld 9,.LC47-.LCTOC1(30)
> lwz 0,48(9)
> cmpwi 7,0,0
> bne 7,.L31
> .LVL45:
> .loc 1 889 0
> ld 4,.LC49-.LCTOC1(30)
> li 5,2
> bl .pm121_register_control
> cmpdi 7,3,0
> beq 7,.L31
> .loc 1 890 0
> mr 3,31
> ld 4,.LC51-.LCTOC1(30)
> li 5,1
> bl .pm121_register_control
> cmpdi 7,3,0
> beq 7,.L31
> .loc 1 891 0
> mr 3,31
> ld 4,.LC53-.LCTOC1(30)
> li 5,0
> bl .pm121_register_control
> cmpdi 7,3,0
> beq 7,.L31
> .loc 1 892 0
> mr 3,31
> ld 4,.LC55-.LCTOC1(30)
> li 5,3
> bl .pm121_register_control
> cmpdi 7,3,0
> beq 7,.L31
> .loc 1 895 0
> ld 3,.LC57-.LCTOC1(30)
> bl .printk
> nop
> .loc 1 896 0
> ld 9,.LC47-.LCTOC1(30)
> li 0,1
> stw 0,48(9)
> .LVL46:
> .L31:
> .loc 1 898 0
> addi 1,1,128
> ld 0,16(1)
> mtlr 0
> ld 30,-16(1)
> ld 31,-8(1)
> .LVL47:
> blr
>
>
>
^ permalink raw reply
* Re: [PATCH] windfarm: add PowerMac 12,1 support
From: Stephen Rothwell @ 2008-03-22 23:25 UTC (permalink / raw)
To: David Woodhouse; +Cc: Étienne Bersac, linuxppc-dev
In-Reply-To: <1206226966.9540.104.camel@pmac.infradead.org>
[-- Attachment #1: Type: text/plain, Size: 863 bytes --]
On Sat, 22 Mar 2008 23:02:46 +0000 David Woodhouse <dwmw2@infradead.org> wrote:
>
> Yeah, there's weird shit going on with the sensor/control registration.
> I think GCC is be miscompiling it -- the sequence of
> all = all && pm121_register_control(foo...);
> all = all && pm121_register_control(bar...);
> is bailing out as soon as 'all' gets set to zero. Despite the fact that
> pm121_register_control() quite blatantly has side-effects.
Why would you expect otherwise (from the C standard):
"Unlike the bitwise binary & operator, the && operator guarantees
left-to-right evaluation; there is a sequence point after the evaluation
of the first operand. If the first operand compares equal to 0, the
second operand is not evaluated."
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] windfarm: add PowerMac 12,1 support
From: David Woodhouse @ 2008-03-22 23:31 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Étienne Bersac, linuxppc-dev
In-Reply-To: <20080323102502.e0754062.sfr@canb.auug.org.au>
On Sun, 2008-03-23 at 10:25 +1100, Stephen Rothwell wrote:
> Why would you expect otherwise (from the C standard):
>
> "Unlike the bitwise binary & operator, the && operator guarantees
> left-to-right evaluation; there is a sequence point after the evaluation
> of the first operand. If the first operand compares equal to 0, the
> second operand is not evaluated."
Because it's Saturday night, I wasn't expecting that construct there
(because it seems to require that the sensors/controls are detected in
the precise order that they're checked for, otherwise it'll never match
the ones which are found out of order), and mostly because I'm stupid.
This seems to fix it (note the change of the control names too):
--- drivers/macintosh/windfarm_pm121.c~ 2008-03-22 19:13:22.000000000 +0000
+++ drivers/macintosh/windfarm_pm121.c 2008-03-22 23:23:44.000000000 +0000
@@ -867,7 +867,7 @@ static struct wf_control* pm121_register
{
if (controls[id] == NULL && !strcmp(ct->name, match)) {
if (wf_get_control(ct) == 0)
- controls[FAN_OD] = ct;
+ controls[id] = ct;
}
return controls[id];
}
@@ -879,10 +879,10 @@ static void pm121_new_control(struct wf_
if (pm121_all_controls_ok)
return;
- all = all && pm121_register_control(ct, "optical-driver-fan", FAN_OD);
- all = all && pm121_register_control(ct, "hard-driver-fan", FAN_HD);
- all = all && pm121_register_control(ct, "cpu-driver-fan", FAN_CPU);
- all = all && pm121_register_control(ct, "cpufreq-clamp", CPUFREQ);
+ all = pm121_register_control(ct, "optical-drive-fan", FAN_OD) && all;
+ all = pm121_register_control(ct, "hard-drive-fan", FAN_HD) && all;
+ all = pm121_register_control(ct, "cpu-fan", FAN_CPU) && all;
+ all = pm121_register_control(ct, "cpufreq-clamp", CPUFREQ) && all;
if (all)
pm121_all_controls_ok = 1;
@@ -909,24 +909,24 @@ static void pm121_new_sensor(struct wf_s
if (pm121_all_sensors_ok)
return;
- all = all && pm121_register_sensor(sr, "cpu-temp",
- &sensor_cpu_temp);
- all = all && pm121_register_sensor(sr, "cpu-current",
- &sensor_cpu_current);
- all = all && pm121_register_sensor(sr, "cpu-voltage",
- &sensor_cpu_voltage);
- all = all && pm121_register_sensor(sr, "cpu-power",
- &sensor_cpu_power);
- all = all && pm121_register_sensor(sr, "hard-drive-temp",
- &sensor_hard_drive_temp);
- all = all && pm121_register_sensor(sr, "optical-drive-temp",
- &sensor_optical_drive_temp);
- all = all && pm121_register_sensor(sr, "incoming-air-temp",
- &sensor_incoming_air_temp);
- all = all && pm121_register_sensor(sr, "north-bridge-temp",
- &sensor_north_bridge_temp);
- all = all && pm121_register_sensor(sr, "gpu-temp",
- &sensor_gpu_temp);
+ all = pm121_register_sensor(sr, "cpu-temp",
+ &sensor_cpu_temp) && all;
+ all = pm121_register_sensor(sr, "cpu-current",
+ &sensor_cpu_current) && all;
+ all = pm121_register_sensor(sr, "cpu-voltage",
+ &sensor_cpu_voltage) && all;
+ all = pm121_register_sensor(sr, "cpu-power",
+ &sensor_cpu_power) && all;
+ all = pm121_register_sensor(sr, "hard-drive-temp",
+ &sensor_hard_drive_temp) && all;
+ all = pm121_register_sensor(sr, "optical-drive-temp",
+ &sensor_optical_drive_temp) && all;
+ all = pm121_register_sensor(sr, "incoming-air-temp",
+ &sensor_incoming_air_temp) && all;
+ all = pm121_register_sensor(sr, "north-bridge-temp",
+ &sensor_north_bridge_temp) && all;
+ all = pm121_register_sensor(sr, "gpu-temp",
+ &sensor_gpu_temp) && all;
if (all)
pm121_all_sensors_ok = 1;
--
dwmw2
^ permalink raw reply
* Re: [PATCH] windfarm: add PowerMac 12,1 support
From: Andreas Schwab @ 2008-03-23 1:01 UTC (permalink / raw)
To: David Woodhouse; +Cc: Étienne Bersac, Stephen Rothwell, linuxppc-dev
In-Reply-To: <1206228673.9540.115.camel@pmac.infradead.org>
David Woodhouse <dwmw2@infradead.org> writes:
> - all = all && pm121_register_control(ct, "optical-driver-fan", FAN_OD);
> - all = all && pm121_register_control(ct, "hard-driver-fan", FAN_HD);
> - all = all && pm121_register_control(ct, "cpu-driver-fan", FAN_CPU);
> - all = all && pm121_register_control(ct, "cpufreq-clamp", CPUFREQ);
> + all = pm121_register_control(ct, "optical-drive-fan", FAN_OD) && all;
> + all = pm121_register_control(ct, "hard-drive-fan", FAN_HD) && all;
> + all = pm121_register_control(ct, "cpu-fan", FAN_CPU) && all;
> + all = pm121_register_control(ct, "cpufreq-clamp", CPUFREQ) && all;
You can also write all &= ... if pm121_register_control always return
0/1 (or make it 0/1 with !!).
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH] windfarm: add PowerMac 12,1 support
From: Stephen Rothwell @ 2008-03-23 5:38 UTC (permalink / raw)
To: David Woodhouse; +Cc: Étienne Bersac, linuxppc-dev
In-Reply-To: <1206228673.9540.115.camel@pmac.infradead.org>
[-- Attachment #1: Type: text/plain, Size: 681 bytes --]
Hi Dave,
On Sat, 22 Mar 2008 23:31:13 +0000 David Woodhouse <dwmw2@infradead.org> wrote:
>
> On Sun, 2008-03-23 at 10:25 +1100, Stephen Rothwell wrote:
> > Why would you expect otherwise (from the C standard):
> >
> > "Unlike the bitwise binary & operator, the && operator guarantees
> > left-to-right evaluation; there is a sequence point after the evaluation
> > of the first operand. If the first operand compares equal to 0, the
> > second operand is not evaluated."
>
> Because it's Saturday night
That seems like all the explanation necessary :-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: crash in init_ipic_sysfs on efika
From: David Woodhouse @ 2008-03-23 9:00 UTC (permalink / raw)
To: Sven Luther; +Cc: linuxppc-dev, Olaf Hering, Paul Mackerras
In-Reply-To: <20080322152528.GA6272@powerlinux.fr>
On Sat, 2008-03-22 at 16:25 +0100, Sven Luther wrote:
> BTW, it was reported to me that the ethernet drivers don't get
> autoloaded by udev. Is this a failure of udev missing the of_plateform
> support, or a deficiency of the ethernet drivers ?
As far as I know, they _are_ being loaded properly. Otherwise, the
Fedora installer wouldn't work.
--
dwmw2
^ permalink raw reply
* Re: crash in init_ipic_sysfs on efika
From: Sven Luther @ 2008-03-23 10:12 UTC (permalink / raw)
To: David Woodhouse; +Cc: Sven Luther, Olaf Hering, Paul Mackerras, linuxppc-dev
In-Reply-To: <1206262841.9540.119.camel@pmac.infradead.org>
On Sun, Mar 23, 2008 at 09:00:41AM +0000, David Woodhouse wrote:
> On Sat, 2008-03-22 at 16:25 +0100, Sven Luther wrote:
> > BTW, it was reported to me that the ethernet drivers don't get
> > autoloaded by udev. Is this a failure of udev missing the of_plateform
> > support, or a deficiency of the ethernet drivers ?
>
> As far as I know, they _are_ being loaded properly. Otherwise, the
> Fedora installer wouldn't work.
Yes, but you probably have the of_plateform udev patch, no ?
Friendly,
Sven Luther
^ permalink raw reply
* Re: crash in init_ipic_sysfs on efika
From: David Woodhouse @ 2008-03-23 10:13 UTC (permalink / raw)
To: Sven Luther; +Cc: linuxppc-dev, Olaf Hering, Paul Mackerras
In-Reply-To: <20080323101215.GA26361@powerlinux.fr>
On Sun, 2008-03-23 at 11:12 +0100, Sven Luther wrote:
> On Sun, Mar 23, 2008 at 09:00:41AM +0000, David Woodhouse wrote:
> > On Sat, 2008-03-22 at 16:25 +0100, Sven Luther wrote:
> > > BTW, it was reported to me that the ethernet drivers don't get
> > > autoloaded by udev. Is this a failure of udev missing the of_plateform
> > > support, or a deficiency of the ethernet drivers ?
> >
> > As far as I know, they _are_ being loaded properly. Otherwise, the
> > Fedora installer wouldn't work.
>
> Yes, but you probably have the of_plateform udev patch, no ?
Not any more. That was merged a while ago, wasn't it?
--
dwmw2
^ permalink raw reply
* Re: crash in init_ipic_sysfs on efika
From: Sven Luther @ 2008-03-23 10:24 UTC (permalink / raw)
To: David Woodhouse; +Cc: Sven Luther, Olaf Hering, Paul Mackerras, linuxppc-dev
In-Reply-To: <1206267193.9540.137.camel@pmac.infradead.org>
On Sun, Mar 23, 2008 at 10:13:12AM +0000, David Woodhouse wrote:
> On Sun, 2008-03-23 at 11:12 +0100, Sven Luther wrote:
> > On Sun, Mar 23, 2008 at 09:00:41AM +0000, David Woodhouse wrote:
> > > On Sat, 2008-03-22 at 16:25 +0100, Sven Luther wrote:
> > > > BTW, it was reported to me that the ethernet drivers don't get
> > > > autoloaded by udev. Is this a failure of udev missing the of_plateform
> > > > support, or a deficiency of the ethernet drivers ?
> > >
> > > As far as I know, they _are_ being loaded properly. Otherwise, the
> > > Fedora installer wouldn't work.
> >
> > Yes, but you probably have the of_plateform udev patch, no ?
>
> Not any more. That was merged a while ago, wasn't it?
So, the only explanation would be if debian had a very outdated udev
which does not include this patch.
Friendly,
Sven Luther
^ permalink raw reply
* DTC Patch Catch Up
From: Jon Loeliger @ 2008-03-23 13:08 UTC (permalink / raw)
To: linuxppc-dev
Folks,
I've applied the following patches from Gibson,
in this order, to the DTC and pushed it out
to git.jdl.com:
dtc: Fix error reporting in push_input_file()
dtc: Implement checks for the format of node and property names
dtc: Fix indentation of fixup_phandle_references
dtc: Strip redundant "name" properties
dtc: Test and fix conversion to/from old dtb versions
dtc: Use for_each_marker_of_type in asm_emit_data()
dtc: Make -I dtb mode use fill_fullpaths()
dtc: Make eval_literal() static
dtc: Assorted improvements to test harness
dtc: Testcases for input handling
dtc: Make dtc_open_file() die() if unable to open requested file
dtc: Remove ugly include stack abuse
dtc: Abolish asize field of struct data
dtc: Add some documentation for the dts formta
dtc: Cleanup \nnn and \xNN string escape handling
dtc: Change exit code for usage message
Thanks,
jdl
^ permalink raw reply
* [PATCH] scanlog_init cleanup, minor fixes
From: Nathan Lynch @ 2008-03-23 22:51 UTC (permalink / raw)
To: linuxppc-dev
scanlog_init() could use some love.
* properly return -ENODEV if this system doesn't support scan-log-dump
* don't printk if scan-log-dump not present; only older systems have it
* convert from create_proc_entry() to preferred proc_create()
* allocate zeroed data buffer
* fix potential memory leak of ent->data on failed create_proc_entry()
* simplify control flow
Signed-off-by: Nathan Lynch <ntl@pobox.com>
---
(not urgent, please consider for 2.6.26)
arch/powerpc/platforms/pseries/scanlog.c | 37 ++++++++++++++---------------
1 files changed, 18 insertions(+), 19 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/scanlog.c b/arch/powerpc/platforms/pseries/scanlog.c
index 8e1ef16..e5b0ea8 100644
--- a/arch/powerpc/platforms/pseries/scanlog.c
+++ b/arch/powerpc/platforms/pseries/scanlog.c
@@ -195,31 +195,30 @@ const struct file_operations scanlog_fops = {
static int __init scanlog_init(void)
{
struct proc_dir_entry *ent;
+ void *data;
+ int err = -ENOMEM;
ibm_scan_log_dump = rtas_token("ibm,scan-log-dump");
- if (ibm_scan_log_dump == RTAS_UNKNOWN_SERVICE) {
- printk(KERN_ERR "scan-log-dump not implemented on this system\n");
- return -EIO;
- }
+ if (ibm_scan_log_dump == RTAS_UNKNOWN_SERVICE)
+ return -ENODEV;
- ent = create_proc_entry("ppc64/rtas/scan-log-dump", S_IRUSR, NULL);
- if (ent) {
- ent->proc_fops = &scanlog_fops;
- /* Ideally we could allocate a buffer < 4G */
- ent->data = kmalloc(RTAS_DATA_BUF_SIZE, GFP_KERNEL);
- if (!ent->data) {
- printk(KERN_ERR "Failed to allocate a buffer\n");
- remove_proc_entry("scan-log-dump", ent->parent);
- return -ENOMEM;
- }
- ((unsigned int *)ent->data)[0] = 0;
- } else {
- printk(KERN_ERR "Failed to create ppc64/scan-log-dump proc entry\n");
- return -EIO;
- }
+ /* Ideally we could allocate a buffer < 4G */
+ data = kzalloc(RTAS_DATA_BUF_SIZE, GFP_KERNEL);
+ if (!data)
+ goto err;
+
+ ent = proc_create("ppc64/rtas/scan-log-dump", S_IRUSR, NULL,
+ &scanlog_fops);
+ if (!ent)
+ goto err;
+
+ ent->data = data;
proc_ppc64_scan_log_dump = ent;
return 0;
+err:
+ kfree(data);
+ return err;
}
static void __exit scanlog_cleanup(void)
--
1.5.4.rc5
^ permalink raw reply related
* Re: DTC Patch Catch Up
From: David Gibson @ 2008-03-24 0:43 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
In-Reply-To: <E1JdPvk-0005mf-2k@jdl.com>
On Sun, Mar 23, 2008 at 08:08:08AM -0500, Jon Loeliger wrote:
> Folks,
>
> I've applied the following patches from Gibson,
> in this order, to the DTC and pushed it out
> to git.jdl.com:
>
> dtc: Fix error reporting in push_input_file()
> dtc: Implement checks for the format of node and property names
> dtc: Fix indentation of fixup_phandle_references
> dtc: Strip redundant "name" properties
> dtc: Test and fix conversion to/from old dtb versions
> dtc: Use for_each_marker_of_type in asm_emit_data()
> dtc: Make -I dtb mode use fill_fullpaths()
> dtc: Make eval_literal() static
> dtc: Assorted improvements to test harness
> dtc: Testcases for input handling
> dtc: Make dtc_open_file() die() if unable to open requested file
> dtc: Remove ugly include stack abuse
> dtc: Abolish asize field of struct data
> dtc: Add some documentation for the dts formta
> dtc: Cleanup \nnn and \xNN string escape handling
> dtc: Change exit code for usage message
Hurrah :)
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* dtc: Clean up included Makefile fragments
From: David Gibson @ 2008-03-24 2:24 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
Currently the Makefile.dtc and Makefile.libfdt fragments include a
number of things that seemed like they might be useful for other
projects embedding the pieces, or for a make dist target.
Well, we have no make dist target, it's become fairly unclear that
these things would actually be useful to embedders (the kernel
certainly doesn't use them), and it's a bunch of stuff with no current
users.
This patch, therefore, removes a bunch of unused definitions from the
Makefile fragments. It also removes a dependency declared in
Makefile.libfdt (of libfdt.a on the constituent .o files) which was
incorrect (wrong path), and if corrected would be redundant with the
similar dependency in the top-level makefile.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
Makefile | 7 ++++---
Makefile.dtc | 18 +-----------------
libfdt/Makefile.libfdt | 7 -------
tests/Makefile.tests | 4 ++--
4 files changed, 7 insertions(+), 29 deletions(-)
Index: dtc/Makefile.dtc
===================================================================
--- dtc.orig/Makefile.dtc 2008-03-24 13:16:17.000000000 +1100
+++ dtc/Makefile.dtc 2008-03-24 13:24:06.000000000 +1100
@@ -5,21 +5,5 @@
#
DTC_SRCS = dtc.c flattree.c fstree.c data.c livetree.c treesource.c srcpos.c \
checks.c
-DTC_EXTRA = dtc.h srcpos.h
-DTC_LEXFILES = dtc-lexer.l
-DTC_BISONFILES = dtc-parser.y
-
-DTC_LEX_SRCS = $(DTC_LEXFILES:%.l=%.lex.c)
-DTC_BISON_SRCS = $(DTC_BISONFILES:%.y=%.tab.c)
-DTC_BISON_INCLUDES = $(DTC_BISONFILES:%.y=%.tab.h)
-
-DTC_GEN_SRCS = $(DTC_LEX_SRCS) $(DTC_BISON_SRCS)
-DTC_GEN_ALL = $(DTC_GEN_SRCS) $(DTC_BISON_INCLUDES)
+DTC_GEN_SRCS = dtc-lexer.lex.c dtc-parser.tab.c
DTC_OBJS = $(DTC_SRCS:%.c=%.o) $(DTC_GEN_SRCS:%.c=%.o)
-
-DTC_CLEANFILES = $(DTC_GEN_ALL)
-
-# We assume the containing Makefile system can do auto-dependencies for most
-# things, but we supply the dependencies on generated header files explicitly
-
-$(addprefix $(DTC_objdir)/,$(DTC_GEN_SRCS:%.c=%.o)): $(addprefix $(DTC_objdir)/,$(DTC_BISON_INCLUDES))
Index: dtc/Makefile
===================================================================
--- dtc.orig/Makefile 2008-03-24 13:16:17.000000000 +1100
+++ dtc/Makefile 2008-03-24 13:17:58.000000000 +1100
@@ -53,7 +53,7 @@
$(INSTALL) -d $(DESTDIR)$(BINDIR)
$(INSTALL) -m 755 dtc $(DESTDIR)$(BINDIR)
$(INSTALL) -d $(DESTDIR)$(LIBDIR)
- $(INSTALL) -m 644 $(LIBFDT_LIB) $(DESTDIR)$(LIBDIR)
+ $(INSTALL) -m 644 $(LIBFDT_lib) $(DESTDIR)$(LIBDIR)
$(INSTALL) -d $(DESTDIR)$(INCLUDEDIR)
$(INSTALL) -m 644 $(addprefix $(LIBFDT_srcdir)/,$(LIBFDT_INCLUDES)) $(DESTDIR)$(INCLUDEDIR)
@@ -135,12 +135,13 @@
#
LIBFDT_objdir = libfdt
LIBFDT_srcdir = libfdt
+LIBFDT_lib = $(LIBFDT_objdir)/libfdt.a
include $(LIBFDT_srcdir)/Makefile.libfdt
.PHONY: libfdt
-libfdt: $(LIBFDT_LIB)
+libfdt: $(LIBFDT_lib)
-$(LIBFDT_LIB): $(addprefix $(LIBFDT_objdir)/,$(LIBFDT_OBJS))
+$(LIBFDT_lib): $(addprefix $(LIBFDT_objdir)/,$(LIBFDT_OBJS))
libfdt_clean:
@$(VECHO) CLEAN "(libfdt)"
Index: dtc/libfdt/Makefile.libfdt
===================================================================
--- dtc.orig/libfdt/Makefile.libfdt 2008-03-24 13:16:17.000000000 +1100
+++ dtc/libfdt/Makefile.libfdt 2008-03-24 13:17:58.000000000 +1100
@@ -4,11 +4,4 @@
# be easily embeddable into other systems of Makefiles.
#
LIBFDT_SRCS = fdt.c fdt_ro.c fdt_wip.c fdt_sw.c fdt_rw.c fdt_strerror.c
-LIBFDT_INCLUDES = fdt.h libfdt.h
-LIBFDT_EXTRA = libfdt_internal.h
-LIBFDT_LIB = libfdt/libfdt.a
-
LIBFDT_OBJS = $(LIBFDT_SRCS:%.c=%.o)
-
-$(LIBFDT_objdir)/$(LIBFDT_LIB): $(addprefix $(LIBFDT_objdir)/,$(LIBFDT_OBJS))
-
Index: dtc/tests/Makefile.tests
===================================================================
--- dtc.orig/tests/Makefile.tests 2008-03-24 13:16:17.000000000 +1100
+++ dtc/tests/Makefile.tests 2008-03-24 13:17:58.000000000 +1100
@@ -35,9 +35,9 @@
.PHONY: tests
tests: $(TESTS) $(TESTS_TREES)
-$(LIB_TESTS): %: $(TESTS_PREFIX)testutils.o $(LIBFDT_LIB)
+$(LIB_TESTS): %: $(TESTS_PREFIX)testutils.o $(LIBFDT_lib)
-$(LIBTREE_TESTS): %: $(TESTS_PREFIX)testutils.o $(TESTS_PREFIX)trees.o $(LIBFDT_LIB)
+$(LIBTREE_TESTS): %: $(TESTS_PREFIX)testutils.o $(TESTS_PREFIX)trees.o $(LIBFDT_lib)
$(TESTS_PREFIX)dumptrees: $(TESTS_PREFIX)trees.o
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* dtc: Simplify error handling for unparseable input
From: David Gibson @ 2008-03-24 3:44 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
Currently, main() tests if it got a valid input tree from whichever
dt_from_*() function it invoked and if not, die()s. For one thing,
this test has, for no good reason, three different ways for those
functions to communicate a failure to provide input (bi NULL, bi->dt
NULL, or bi->error non-zero). For another, in every case save one, if
the dt_from_*() functions are unable to provide input they will
immediately die() (with a more specific error message) rather than
proceeding to the test in main().
Therefore, this patch removes this test, making the one case that
could have triggered it (in dt_from_source()) call die() directly
instead. With this change, the error field in struct boot_info is now
unused, so remove it.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
dtc.c | 3 ---
dtc.h | 1 -
livetree.c | 1 -
treesource.c | 6 ++++--
4 files changed, 4 insertions(+), 7 deletions(-)
Index: dtc/dtc.h
===================================================================
--- dtc.orig/dtc.h 2008-03-24 14:33:33.000000000 +1100
+++ dtc/dtc.h 2008-03-24 14:33:34.000000000 +1100
@@ -232,7 +232,6 @@
struct boot_info {
struct reserve_info *reservelist;
struct node *dt; /* the device tree */
- int error;
};
struct boot_info *build_boot_info(struct reserve_info *reservelist,
Index: dtc/livetree.c
===================================================================
--- dtc.orig/livetree.c 2008-03-24 14:18:44.000000000 +1100
+++ dtc/livetree.c 2008-03-24 14:33:34.000000000 +1100
@@ -172,7 +172,6 @@
bi = xmalloc(sizeof(*bi));
bi->reservelist = reservelist;
bi->dt = tree;
- bi->error = 0;
return bi;
}
Index: dtc/dtc.c
===================================================================
--- dtc.orig/dtc.c 2008-03-24 14:35:05.000000000 +1100
+++ dtc/dtc.c 2008-03-24 14:35:10.000000000 +1100
@@ -201,9 +201,6 @@
if (inf && inf->file != stdin)
fclose(inf->file);
- if (! bi || ! bi->dt || bi->error)
- die("Couldn't read input tree\n");
-
fill_fullpaths(bi->dt, "");
process_checks(force, bi);
Index: dtc/treesource.c
===================================================================
--- dtc.orig/treesource.c 2008-03-24 14:33:44.000000000 +1100
+++ dtc/treesource.c 2008-03-24 14:35:52.000000000 +1100
@@ -36,9 +36,11 @@
yyin = srcpos_file->file;
if (yyparse() != 0)
- return NULL;
+ die("Unable to parse input tree\n");
+
+ if (treesource_error)
+ die("Syntax error parsing input tree\n");
- the_boot_info->error = treesource_error;
return the_boot_info;
}
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* RE: dcr stuff.
From: Stephen Neuendorffer @ 2008-03-24 4:34 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, git-dev
In-Reply-To: <20080321201704.032999c3@zod.rchland.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1602 bytes --]
-----Original Message-----
From: Josh Boyer [mailto:jwboyer@linux.vnet.ibm.com]
Sent: Fri 3/21/2008 6:17 PM
To: Stephen Neuendorffer
Cc: linuxppc-dev@ozlabs.org; git-dev
Subject: Re: dcr stuff.
On Fri, 21 Mar 2008 12:05:40 -0700
"Stephen Neuendorffer" <stephen.neuendorffer@xilinx.com> wrote:
> > Is there a plan here? (In particular, in FPGA designs, its possible to
> > have crazy things like multiple independent dcr busses, some using
> > native access, some using mmio. Or even if there is one bus, many of
> > the existing non-linux drivers we have assume native or mmio access.
> > I'd like to clean this up, obviously.. :)
> Clean it up how? I'd hate to add bloat to boards with native DCR
> access just because a few require oddities.
>
> If it ain't broke, don't fix it.
>
> josh
Certainly, if it ain't broke don't fix it. What I'm really trying to do is figure out how to clean up alot of non-mainline drivers.
At the moment, several cores use DCR, but the drivers for those cores have internal code for DCR, their own ifdefs, etc. This *is* broken.
I'm looking at the available documentation to figure out the best way of approaching the problem.
It might be nice if there was an extra layer of indirection which was only enabled if DCR_NATIVE and DCR_MMIO, and which was no cost otherwise,
but the bigger problem I see in the short term is that we'll likely have to support ARCH ppc for at least some time into the future, and it would be
nice if we used the same driver code to do it: it doesn't seem obvious how to achieve this.
Steve
[-- Attachment #2: Type: text/html, Size: 2239 bytes --]
^ permalink raw reply
* Re: Oops with TQM5200 on TQM5200
From: Paul Mackerras @ 2008-03-24 6:47 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: linuxppc-dev, Anatolij Gustschin
In-Reply-To: <47E3561B.6040505@grandegger.com>
Wolfgang Grandegger writes:
> 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 similar fixes for cm5200.dts and motionpro.dts picked
> > up? I could provide the patches within a day -- will this be OK?
>
> At that occasion, could you please also add two CAN nodes to tqm5200.dts
> as shown:
Does this really need to go in for 2.6.25 -- i.e., does it fix a
regression or a serious bug (not just a missing feature)? If so,
please send it with a proper subject and patch description, with your
Signed-off-by.
Paul.
^ permalink raw reply
* Re: [PATCH] [POWERPC] mpc5200: fix incorrect compatible string for the mdio node
From: Paul Mackerras @ 2008-03-24 7:24 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1206156315-4734-1-git-send-email-grant.likely@secretlab.ca>
Grant Likely writes:
> The MDIO node in the lite5200b.dts file needs to also claim compatibility
> with the older mpc5200 chip.
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> ---
> Paul, this one should also go in for .26
OK, I'll put it in the powerpc-next branch. Or did you mean it should
go in .25?
Paul.
^ 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