[PATCH 0/4] Fedora kernel patch review

[PATCH 0/4] Fedora kernel patch review

[Josh Boyer]

Hi All,

Below are the set of ppc/ppc64 specific patches that Fedora has been
carrying for a very long time now.  It would be good to get some eyes
on them to see if they could just be incorporated upstream.

josh

[PATCH 1/4] Add ps3_storage module alias

[Josh Boyer]

This allows the upgrade path from older kernel releases to work
with the Fedora mkinitrd tool.

---

--- linux-2.6.22.ppc64/drivers/block/ps3disk.c~	2007-07-25 16:06:16.000000000 +0100
+++ linux-2.6.22.ppc64/drivers/block/ps3disk.c	2007-07-26 08:49:44.000000000 +0100
@@ -628,3 +628,4 @@ MODULE_LICENSE("GPL");
 MODULE_DESCRIPTION("PS3 Disk Storage Driver");
 MODULE_AUTHOR("Sony Corporation");
 MODULE_ALIAS(PS3_MODULE_ALIAS_STOR_DISK);
+MODULE_ALIAS("ps3_storage");

Re: [PATCH 1/4] Add ps3_storage module alias

[Geert Uytterhoeven]

On Fri, 5 Feb 2010, Josh Boyer wrote:
> This allows the upgrade path from older kernel releases to work
> with the Fedora mkinitrd tool.
>=20
> ---
>=20
> --- linux-2.6.22.ppc64/drivers/block/ps3disk.c~=092007-07-25 16:06:16.000=
000000 +0100
> +++ linux-2.6.22.ppc64/drivers/block/ps3disk.c=092007-07-26 08:49:44.0000=
00000 +0100
> @@ -628,3 +628,4 @@ MODULE_LICENSE("GPL");
>  MODULE_DESCRIPTION("PS3 Disk Storage Driver");
>  MODULE_AUTHOR("Sony Corporation");
>  MODULE_ALIAS(PS3_MODULE_ALIAS_STOR_DISK);
> +MODULE_ALIAS("ps3_storage");

NAKed-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>

ps3_storage was replaced by 3 drivers: ps3disk, ps3rom, and ps3flash. These=
 are
automatically loaded by udev.

How does mkinitrd determine the driver for the root file system on other
systems? Does it really contain a big list of e.g. all SCSI drivers?

With kind regards,

Geert Uytterhoeven
Software Architect
Techsoft Centre

Technology and Software Centre Europe
The Corporate Village =B7 Da Vincilaan 7-D1 =B7 B-1935 Zaventem =B7 Belgium

Phone:    +32 (0)2 700 8453
Fax:      +32 (0)2 700 8622
E-mail:   Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/

A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 =B7 RPR Brussels
Fortis =B7 BIC GEBABEBB =B7 IBAN BE41293037680010

Re: [PATCH 1/4] Add ps3_storage module alias

[Josh Boyer]

On Fri, Feb 05, 2010 at 02:49:14PM +0100, Geert Uytterhoeven wrote:
>On Fri, 5 Feb 2010, Josh Boyer wrote:
>> This allows the upgrade path from older kernel releases to work
>> with the Fedora mkinitrd tool.
>> 
>> ---
>> 
>> --- linux-2.6.22.ppc64/drivers/block/ps3disk.c~	2007-07-25 16:06:16.000000000 +0100
>> +++ linux-2.6.22.ppc64/drivers/block/ps3disk.c	2007-07-26 08:49:44.000000000 +0100
>> @@ -628,3 +628,4 @@ MODULE_LICENSE("GPL");
>>  MODULE_DESCRIPTION("PS3 Disk Storage Driver");
>>  MODULE_AUTHOR("Sony Corporation");
>>  MODULE_ALIAS(PS3_MODULE_ALIAS_STOR_DISK);
>> +MODULE_ALIAS("ps3_storage");
>
>NAKed-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
>
>ps3_storage was replaced by 3 drivers: ps3disk, ps3rom, and ps3flash. These are
>automatically loaded by udev.
>
>How does mkinitrd determine the driver for the root file system on other
>systems? Does it really contain a big list of e.g. all SCSI drivers?

At one time I believe it did have a list of "odd" drivers to explicitly
include.  Anaconda didn't (doesn't?) use udev to determine which drivers
to include in the initrd since the install image is most likely not composed
on a machine that includes those drivers.  If the install initrd didn't have
the drivers loaded, it wouldn't install on PS3.

This is highlighted as a Fedora local change, probably for the reasons you
state.  We might have already moved past the point where this is needed,
so I'm fine with it being NAKed.  I'll probably just drop it from the Fedora
kernel builds.

josh

Re: [PATCH 1/4] Add ps3_storage module alias

[Geert Uytterhoeven]

On Fri, 5 Feb 2010, Josh Boyer wrote:
> On Fri, Feb 05, 2010 at 02:49:14PM +0100, Geert Uytterhoeven wrote:
> >On Fri, 5 Feb 2010, Josh Boyer wrote:
> >> This allows the upgrade path from older kernel releases to work
> >> with the Fedora mkinitrd tool.
> >>=20
> >> ---
> >>=20
> >> --- linux-2.6.22.ppc64/drivers/block/ps3disk.c~=092007-07-25 16:06:16.=
000000000 +0100
> >> +++ linux-2.6.22.ppc64/drivers/block/ps3disk.c=092007-07-26 08:49:44.0=
00000000 +0100
> >> @@ -628,3 +628,4 @@ MODULE_LICENSE("GPL");
> >>  MODULE_DESCRIPTION("PS3 Disk Storage Driver");
> >>  MODULE_AUTHOR("Sony Corporation");
> >>  MODULE_ALIAS(PS3_MODULE_ALIAS_STOR_DISK);
> >> +MODULE_ALIAS("ps3_storage");
> >
> >NAKed-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
> >
> >ps3_storage was replaced by 3 drivers: ps3disk, ps3rom, and ps3flash. Th=
ese are
> >automatically loaded by udev.
> >
> >How does mkinitrd determine the driver for the root file system on other
> >systems? Does it really contain a big list of e.g. all SCSI drivers?
>=20
> At one time I believe it did have a list of "odd" drivers to explicitly
> include.  Anaconda didn't (doesn't?) use udev to determine which drivers
> to include in the initrd since the install image is most likely not compo=
sed
> on a machine that includes those drivers.  If the install initrd didn't h=
ave
> the drivers loaded, it wouldn't install on PS3.
>=20
> This is highlighted as a Fedora local change, probably for the reasons yo=
u
> state.  We might have already moved past the point where this is needed,
> so I'm fine with it being NAKed.  I'll probably just drop it from the Fed=
ora
> kernel builds.

It's possible it's (still) needed on Fedora, though (Geoff, do you know?).
But it's definitely not something we want in mainline.

With kind regards,

Geert Uytterhoeven
Software Architect
Techsoft Centre

Technology and Software Centre Europe
The Corporate Village =B7 Da Vincilaan 7-D1 =B7 B-1935 Zaventem =B7 Belgium

Phone:    +32 (0)2 700 8453
Fax:      +32 (0)2 700 8622
E-mail:   Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/

A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 =B7 RPR Brussels
Fortis =B7 BIC GEBABEBB =B7 IBAN BE41293037680010

Re: [PATCH 1/4] Add ps3_storage module alias

[David Woodhouse]

On Fri, 2010-02-05 at 14:49 +0100, Geert Uytterhoeven wrote:
> On Fri, 5 Feb 2010, Josh Boyer wrote:
> > This allows the upgrade path from older kernel releases to work
> > with the Fedora mkinitrd tool.
> > 
> > ---
> > 
> > --- linux-2.6.22.ppc64/drivers/block/ps3disk.c~       2007-07-25 16:06:16.000000000 +0100
> > +++ linux-2.6.22.ppc64/drivers/block/ps3disk.c        2007-07-26 08:49:44.000000000 +0100
> > @@ -628,3 +628,4 @@ MODULE_LICENSE("GPL");
> >  MODULE_DESCRIPTION("PS3 Disk Storage Driver");
> >  MODULE_AUTHOR("Sony Corporation");
> >  MODULE_ALIAS(PS3_MODULE_ALIAS_STOR_DISK);
> > +MODULE_ALIAS("ps3_storage");
> 
> NAKed-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
> 
> ps3_storage was replaced by 3 drivers: ps3disk, ps3rom, and ps3flash. These are
> automatically loaded by udev.
> 
> How does mkinitrd determine the driver for the root file system on other
> systems? Does it really contain a big list of e.g. all SCSI drivers?

It pokes about in sysfs and works out the driver which is used for the
current root devices.

This hack was only needed for the upgrade -- when you were running a
kernel with the ps3_storage kernel and you first installed a kernel with
the new ps3disk driver, you needed it to find the right module.

I think we can drop it now.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation

[PATCH 2/4] Fix G5 thermal shutdown

[Josh Boyer]

This changes the thresholds for the liquid cooled G5 thermal
shutdown mechanism to prevent an errant shutdown.

This has been carried since about Fedora Core 5.  I have no idea
if it's really needed or not.

---

--- linux-2.6.15/drivers/macintosh/therm_pm72.c.orig	2006-04-02 21:34:48.000000000 +0100
+++ linux-2.6.15/drivers/macintosh/therm_pm72.c	2006-04-02 22:33:27.000000000 +0100
@@ -924,10 +925,16 @@ static void do_monitor_cpu_combined(void
 		printk(KERN_WARNING "Warning ! Temperature way above maximum (%d) !\n",
 		       temp_combi >> 16);
 		state0->overtemp += CPU_MAX_OVERTEMP / 4;
-	} else if (temp_combi > (state0->mpu.tmax << 16))
+	} else if (temp_combi > (state0->mpu.tmax << 16)) {
 		state0->overtemp++;
-	else
+		printk(KERN_WARNING "Temperature %d above max %d. overtemp %d\n",
+		       temp_combi >> 16, state0->mpu.tmax, state0->overtemp);
+	} else {
+		if (state0->overtemp)
+			printk(KERN_WARNING "Temperature back down to %d\n",
+			       temp_combi >> 16);
 		state0->overtemp = 0;
+	}
 	if (state0->overtemp >= CPU_MAX_OVERTEMP)
 		critical_state = 1;
 	if (state0->overtemp > 0) {
@@ -999,10 +1015,16 @@ static void do_monitor_cpu_split(struct 
 		       " (%d) !\n",
 		       state->index, temp >> 16);
 		state->overtemp += CPU_MAX_OVERTEMP / 4;
-	} else if (temp > (state->mpu.tmax << 16))
+	} else if (temp > (state->mpu.tmax << 16)) {
 		state->overtemp++;
-	else
+		printk(KERN_WARNING "CPU %d temperature %d above max %d. overtemp %d\n",
+		       state->index, temp >> 16, state->mpu.tmax, state->overtemp);
+	} else {
+		if (state->overtemp)
+			printk(KERN_WARNING "CPU %d temperature back down to %d\n",
+			       state->index, temp >> 16);
 		state->overtemp = 0;
+	}
 	if (state->overtemp >= CPU_MAX_OVERTEMP)
 		critical_state = 1;
 	if (state->overtemp > 0) {
@@ -1061,10 +1097,16 @@ static void do_monitor_cpu_rack(struct c
 		       " (%d) !\n",
 		       state->index, temp >> 16);
 		state->overtemp = CPU_MAX_OVERTEMP / 4;
-	} else if (temp > (state->mpu.tmax << 16))
+	} else if (temp > (state->mpu.tmax << 16)) {
 		state->overtemp++;
-	else
+		printk(KERN_WARNING "CPU %d temperature %d above max %d. overtemp %d\n",
+		       state->index, temp >> 16, state->mpu.tmax, state->overtemp);
+	} else {
+		if (state->overtemp)
+			printk(KERN_WARNING "CPU %d temperature back down to %d\n",
+			       state->index, temp >> 16);
 		state->overtemp = 0;
+	}
 	if (state->overtemp >= CPU_MAX_OVERTEMP)
 		critical_state = 1;
 	if (state->overtemp > 0) {
--- linux-2.6.15/drivers/macintosh/therm_pm72.h~	2006-01-03 03:21:10.000000000 +0000
+++ linux-2.6.15/drivers/macintosh/therm_pm72.h	2006-04-02 22:25:58.000000000 +0100
@@ -243,7 +243,7 @@ struct dimm_pid_state
 #define CPU_TEMP_HISTORY_SIZE		2
 #define CPU_POWER_HISTORY_SIZE		10
 #define CPU_PID_INTERVAL		1
-#define CPU_MAX_OVERTEMP		30
+#define CPU_MAX_OVERTEMP		90
 
 #define CPUA_PUMP_RPM_INDEX		7
 #define CPUB_PUMP_RPM_INDEX		8

Re: [PATCH 2/4] Fix G5 thermal shutdown

[Benjamin Herrenschmidt]

On Fri, 2010-02-05 at 08:52 -0500, Josh Boyer wrote:
> This changes the thresholds for the liquid cooled G5 thermal
> shutdown mechanism to prevent an errant shutdown.
> 
> This has been carried since about Fedora Core 5.  I have no idea
> if it's really needed or not.

Can we have a SoB ?

Cheers,
Ben.

> ---
> 
> --- linux-2.6.15/drivers/macintosh/therm_pm72.c.orig	2006-04-02 21:34:48.000000000 +0100
> +++ linux-2.6.15/drivers/macintosh/therm_pm72.c	2006-04-02 22:33:27.000000000 +0100
> @@ -924,10 +925,16 @@ static void do_monitor_cpu_combined(void
>  		printk(KERN_WARNING "Warning ! Temperature way above maximum (%d) !\n",
>  		       temp_combi >> 16);
>  		state0->overtemp += CPU_MAX_OVERTEMP / 4;
> -	} else if (temp_combi > (state0->mpu.tmax << 16))
> +	} else if (temp_combi > (state0->mpu.tmax << 16)) {
>  		state0->overtemp++;
> -	else
> +		printk(KERN_WARNING "Temperature %d above max %d. overtemp %d\n",
> +		       temp_combi >> 16, state0->mpu.tmax, state0->overtemp);
> +	} else {
> +		if (state0->overtemp)
> +			printk(KERN_WARNING "Temperature back down to %d\n",
> +			       temp_combi >> 16);
>  		state0->overtemp = 0;
> +	}
>  	if (state0->overtemp >= CPU_MAX_OVERTEMP)
>  		critical_state = 1;
>  	if (state0->overtemp > 0) {
> @@ -999,10 +1015,16 @@ static void do_monitor_cpu_split(struct 
>  		       " (%d) !\n",
>  		       state->index, temp >> 16);
>  		state->overtemp += CPU_MAX_OVERTEMP / 4;
> -	} else if (temp > (state->mpu.tmax << 16))
> +	} else if (temp > (state->mpu.tmax << 16)) {
>  		state->overtemp++;
> -	else
> +		printk(KERN_WARNING "CPU %d temperature %d above max %d. overtemp %d\n",
> +		       state->index, temp >> 16, state->mpu.tmax, state->overtemp);
> +	} else {
> +		if (state->overtemp)
> +			printk(KERN_WARNING "CPU %d temperature back down to %d\n",
> +			       state->index, temp >> 16);
>  		state->overtemp = 0;
> +	}
>  	if (state->overtemp >= CPU_MAX_OVERTEMP)
>  		critical_state = 1;
>  	if (state->overtemp > 0) {
> @@ -1061,10 +1097,16 @@ static void do_monitor_cpu_rack(struct c
>  		       " (%d) !\n",
>  		       state->index, temp >> 16);
>  		state->overtemp = CPU_MAX_OVERTEMP / 4;
> -	} else if (temp > (state->mpu.tmax << 16))
> +	} else if (temp > (state->mpu.tmax << 16)) {
>  		state->overtemp++;
> -	else
> +		printk(KERN_WARNING "CPU %d temperature %d above max %d. overtemp %d\n",
> +		       state->index, temp >> 16, state->mpu.tmax, state->overtemp);
> +	} else {
> +		if (state->overtemp)
> +			printk(KERN_WARNING "CPU %d temperature back down to %d\n",
> +			       state->index, temp >> 16);
>  		state->overtemp = 0;
> +	}
>  	if (state->overtemp >= CPU_MAX_OVERTEMP)
>  		critical_state = 1;
>  	if (state->overtemp > 0) {
> --- linux-2.6.15/drivers/macintosh/therm_pm72.h~	2006-01-03 03:21:10.000000000 +0000
> +++ linux-2.6.15/drivers/macintosh/therm_pm72.h	2006-04-02 22:25:58.000000000 +0100
> @@ -243,7 +243,7 @@ struct dimm_pid_state
>  #define CPU_TEMP_HISTORY_SIZE		2
>  #define CPU_POWER_HISTORY_SIZE		10
>  #define CPU_PID_INTERVAL		1
> -#define CPU_MAX_OVERTEMP		30
> +#define CPU_MAX_OVERTEMP		90
>  
>  #define CPUA_PUMP_RPM_INDEX		7
>  #define CPUB_PUMP_RPM_INDEX		8
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 2/4] Fix G5 thermal shutdown

[Josh Boyer]

On Tue, Feb 09, 2010 at 11:55:05AM +1100, Benjamin Herrenschmidt wrote:
>On Fri, 2010-02-05 at 08:52 -0500, Josh Boyer wrote:
>> This changes the thresholds for the liquid cooled G5 thermal
>> shutdown mechanism to prevent an errant shutdown.
>> 
>> This has been carried since about Fedora Core 5.  I have no idea
>> if it's really needed or not.
>
>Can we have a SoB ?

David?

josh

>
>Cheers,
>Ben.
>
>> ---
>> 
>> --- linux-2.6.15/drivers/macintosh/therm_pm72.c.orig	2006-04-02 21:34:48.000000000 +0100
>> +++ linux-2.6.15/drivers/macintosh/therm_pm72.c	2006-04-02 22:33:27.000000000 +0100
>> @@ -924,10 +925,16 @@ static void do_monitor_cpu_combined(void
>>  		printk(KERN_WARNING "Warning ! Temperature way above maximum (%d) !\n",
>>  		       temp_combi >> 16);
>>  		state0->overtemp += CPU_MAX_OVERTEMP / 4;
>> -	} else if (temp_combi > (state0->mpu.tmax << 16))
>> +	} else if (temp_combi > (state0->mpu.tmax << 16)) {
>>  		state0->overtemp++;
>> -	else
>> +		printk(KERN_WARNING "Temperature %d above max %d. overtemp %d\n",
>> +		       temp_combi >> 16, state0->mpu.tmax, state0->overtemp);
>> +	} else {
>> +		if (state0->overtemp)
>> +			printk(KERN_WARNING "Temperature back down to %d\n",
>> +			       temp_combi >> 16);
>>  		state0->overtemp = 0;
>> +	}
>>  	if (state0->overtemp >= CPU_MAX_OVERTEMP)
>>  		critical_state = 1;
>>  	if (state0->overtemp > 0) {
>> @@ -999,10 +1015,16 @@ static void do_monitor_cpu_split(struct 
>>  		       " (%d) !\n",
>>  		       state->index, temp >> 16);
>>  		state->overtemp += CPU_MAX_OVERTEMP / 4;
>> -	} else if (temp > (state->mpu.tmax << 16))
>> +	} else if (temp > (state->mpu.tmax << 16)) {
>>  		state->overtemp++;
>> -	else
>> +		printk(KERN_WARNING "CPU %d temperature %d above max %d. overtemp %d\n",
>> +		       state->index, temp >> 16, state->mpu.tmax, state->overtemp);
>> +	} else {
>> +		if (state->overtemp)
>> +			printk(KERN_WARNING "CPU %d temperature back down to %d\n",
>> +			       state->index, temp >> 16);
>>  		state->overtemp = 0;
>> +	}
>>  	if (state->overtemp >= CPU_MAX_OVERTEMP)
>>  		critical_state = 1;
>>  	if (state->overtemp > 0) {
>> @@ -1061,10 +1097,16 @@ static void do_monitor_cpu_rack(struct c
>>  		       " (%d) !\n",
>>  		       state->index, temp >> 16);
>>  		state->overtemp = CPU_MAX_OVERTEMP / 4;
>> -	} else if (temp > (state->mpu.tmax << 16))
>> +	} else if (temp > (state->mpu.tmax << 16)) {
>>  		state->overtemp++;
>> -	else
>> +		printk(KERN_WARNING "CPU %d temperature %d above max %d. overtemp %d\n",
>> +		       state->index, temp >> 16, state->mpu.tmax, state->overtemp);
>> +	} else {
>> +		if (state->overtemp)
>> +			printk(KERN_WARNING "CPU %d temperature back down to %d\n",
>> +			       state->index, temp >> 16);
>>  		state->overtemp = 0;
>> +	}
>>  	if (state->overtemp >= CPU_MAX_OVERTEMP)
>>  		critical_state = 1;
>>  	if (state->overtemp > 0) {
>> --- linux-2.6.15/drivers/macintosh/therm_pm72.h~	2006-01-03 03:21:10.000000000 +0000
>> +++ linux-2.6.15/drivers/macintosh/therm_pm72.h	2006-04-02 22:25:58.000000000 +0100
>> @@ -243,7 +243,7 @@ struct dimm_pid_state
>>  #define CPU_TEMP_HISTORY_SIZE		2
>>  #define CPU_POWER_HISTORY_SIZE		10
>>  #define CPU_PID_INTERVAL		1
>> -#define CPU_MAX_OVERTEMP		30
>> +#define CPU_MAX_OVERTEMP		90
>>  
>>  #define CPUA_PUMP_RPM_INDEX		7
>>  #define CPUB_PUMP_RPM_INDEX		8
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@lists.ozlabs.org
>> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
>

Re: [PATCH 2/4] Fix G5 thermal shutdown

[David Woodhouse]

On Tue, 2010-02-09 at 11:55 +1100, Benjamin Herrenschmidt wrote:
> On Fri, 2010-02-05 at 08:52 -0500, Josh Boyer wrote:
> > This changes the thresholds for the liquid cooled G5 thermal
> > shutdown mechanism to prevent an errant shutdown.
> > 
> > This has been carried since about Fedora Core 5.  I have no idea
> > if it's really needed or not.

It's kind of a dirty hack, but it was sufficient to stop my machine
constantly powering itself off.

> Can we have a SoB ?

Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation

Re: [PATCH 2/4] Fix G5 thermal shutdown

[Benjamin Herrenschmidt]

On Tue, 2010-02-23 at 12:48 +0000, David Woodhouse wrote:
> On Tue, 2010-02-09 at 11:55 +1100, Benjamin Herrenschmidt wrote:
> > On Fri, 2010-02-05 at 08:52 -0500, Josh Boyer wrote:
> > > This changes the thresholds for the liquid cooled G5 thermal
> > > shutdown mechanism to prevent an errant shutdown.
> > > 
> > > This has been carried since about Fedora Core 5.  I have no idea
> > > if it's really needed or not.
> 
> It's kind of a dirty hack, but it was sufficient to stop my machine
> constantly powering itself off.
> 
> > Can we have a SoB ?
> 
> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>

Well, I think you've been testing it long enough now :-)

Cheers,
Ben.

Re: [PATCH 0/4] Fedora kernel patch review

[Josh Boyer]

Provide a modalias entry for VIO devices in sysfs.  I believe
this was another initrd generation bugfix for anaconda.

---
 
diff --git a/arch/powerpc/kernel/vio.c b/arch/powerpc/kernel/vio.c
index f988672..12a0851 100644
--- a/arch/powerpc/kernel/vio.c
+++ b/arch/powerpc/kernel/vio.c
@@ -294,9 +294,27 @@ static ssize_t devspec_show(struct device *dev,
 	return sprintf(buf, "%s\n", of_node ? of_node->full_name : "none");
 }
 
+static ssize_t modalias_show(struct device *dev, struct device_attribute *attr,
+			     char *buf)
+{
+	const struct vio_dev *vio_dev = to_vio_dev(dev);
+	struct device_node *dn;
+	const char *cp;
+
+	dn = dev->archdata.of_node;
+	if (!dn)
+		return -ENODEV;
+	cp = of_get_property(dn, "compatible", NULL);
+	if (!cp)
+		return -ENODEV;
+
+	return sprintf(buf, "vio:T%sS%s\n", vio_dev->type, cp);
+}
+
 static struct device_attribute vio_dev_attrs[] = {
 	__ATTR_RO(name),
 	__ATTR_RO(devspec),
+	__ATTR_RO(modalias),
 	__ATTR_NULL
 };

Re: [PATCH 0/4] Fedora kernel patch review

[Josh Boyer]

On Fri, Feb 05, 2010 at 08:53:54AM -0500, Josh Boyer wrote:
>Provide a modalias entry for VIO devices in sysfs.  I believe
>this was another initrd generation bugfix for anaconda.

Bah, subject on this should have been [PATCH 3/4] Provide VIO modalias

Re: [PATCH 3/4] Provide VIO modalias

[David Woodhouse]

On Fri, 2010-02-05 at 08:53 -0500, Josh Boyer wrote:
> Provide a modalias entry for VIO devices in sysfs.  I believe
> this was another initrd generation bugfix for anaconda.
> 
> ---

Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>

Not entirely sure why this didn't get upstream when I first did it;
maybe I just posted it once and then forgot about it?

> diff --git a/arch/powerpc/kernel/vio.c b/arch/powerpc/kernel/vio.c
> index f988672..12a0851 100644
> --- a/arch/powerpc/kernel/vio.c
> +++ b/arch/powerpc/kernel/vio.c
> @@ -294,9 +294,27 @@ static ssize_t devspec_show(struct device *dev,
>  	return sprintf(buf, "%s\n", of_node ? of_node->full_name : "none");
>  }
>  
> +static ssize_t modalias_show(struct device *dev, struct device_attribute *attr,
> +			     char *buf)
> +{
> +	const struct vio_dev *vio_dev = to_vio_dev(dev);
> +	struct device_node *dn;
> +	const char *cp;
> +
> +	dn = dev->archdata.of_node;
> +	if (!dn)
> +		return -ENODEV;
> +	cp = of_get_property(dn, "compatible", NULL);
> +	if (!cp)
> +		return -ENODEV;
> +
> +	return sprintf(buf, "vio:T%sS%s\n", vio_dev->type, cp);
> +}
> +
>  static struct device_attribute vio_dev_attrs[] = {
>  	__ATTR_RO(name),
>  	__ATTR_RO(devspec),
> +	__ATTR_RO(modalias),
>  	__ATTR_NULL
>  };
> 
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev


-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation

Re: [PATCH 3/4] Provide VIO modalias

[Brian King]

On 02/23/2010 06:50 AM, David Woodhouse wrote:
>> +static ssize_t modalias_show(struct device *dev, struct device_attribute *attr,
>> +			     char *buf)
>> +{
>> +	const struct vio_dev *vio_dev = to_vio_dev(dev);
>> +	struct device_node *dn;
>> +	const char *cp;
>> +
>> +	dn = dev->archdata.of_node;
>> +	if (!dn)
>> +		return -ENODEV;
>> +	cp = of_get_property(dn, "compatible", NULL);
>> +	if (!cp)
>> +		return -ENODEV;
>> +
>> +	return sprintf(buf, "vio:T%sS%s\n", vio_dev->type, cp);
>> +}
>> +
>>  static struct device_attribute vio_dev_attrs[] = {
>>  	__ATTR_RO(name),
>>  	__ATTR_RO(devspec),
>> +	__ATTR_RO(modalias),
>>  	__ATTR_NULL
>>  };

You'll want to add this to vio_cmo_dev_attrs as well, as that is the
device attribute array that gets used when active memory sharing is enabled.

Thanks,

Brian

-- 
Brian King
Linux on Power Virtualization
IBM Linux Technology Center

[PATCH 4/4] Fix iMac iSight PCI bridge setup

[Josh Boyer]

This works around the PCIe bridge setup on the iMac iSight boxen.

---

--- linux/arch/powerpc/platforms/powermac/pci.c~	2008-03-22 19:08:07.000000000 +0000
+++ linux/arch/powerpc/platforms/powermac/pci.c	2008-03-23 09:10:46.000000000 +0000
@@ -1271,6 +1271,12 @@ void pmac_pci_fixup_pciata(struct pci_de
 	}
 }
 DECLARE_PCI_FIXUP_EARLY(PCI_ANY_ID, PCI_ANY_ID, pmac_pci_fixup_pciata);
+#else /* CONFIG_PPC64 */
+static void __devinit imac_transparent_bridge(struct pci_dev *dev)
+{
+	dev->transparent = 1;
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_APPLE, 0x005b, imac_transparent_bridge);
 #endif /* CONFIG_PPC32 */
 
 /*

Re: [PATCH 4/4] Fix iMac iSight PCI bridge setup

[Benjamin Herrenschmidt]

On Fri, 2010-02-05 at 08:55 -0500, Josh Boyer wrote:
> This works around the PCIe bridge setup on the iMac iSight boxen.

Is this still needed ? I though I had fixed the root cause (incorrect
setup of the bridge) a while back...

Cheers,
Ben.

> ---
> 
> --- linux/arch/powerpc/platforms/powermac/pci.c~	2008-03-22 19:08:07.000000000 +0000
> +++ linux/arch/powerpc/platforms/powermac/pci.c	2008-03-23 09:10:46.000000000 +0000
> @@ -1271,6 +1271,12 @@ void pmac_pci_fixup_pciata(struct pci_de
>  	}
>  }
>  DECLARE_PCI_FIXUP_EARLY(PCI_ANY_ID, PCI_ANY_ID, pmac_pci_fixup_pciata);
> +#else /* CONFIG_PPC64 */
> +static void __devinit imac_transparent_bridge(struct pci_dev *dev)
> +{
> +	dev->transparent = 1;
> +}
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_APPLE, 0x005b, imac_transparent_bridge);
>  #endif /* CONFIG_PPC32 */
>  
>  /*
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 4/4] Fix iMac iSight PCI bridge setup

[Josh Boyer]

On Sat, Feb 06, 2010 at 07:57:46AM +1100, Benjamin Herrenschmidt wrote:
>On Fri, 2010-02-05 at 08:55 -0500, Josh Boyer wrote:
>> This works around the PCIe bridge setup on the iMac iSight boxen.
>
>Is this still needed ? I though I had fixed the root cause (incorrect
>setup of the bridge) a while back...

I honestly have no clue, and I have no means of actually testing this.  I have
an iMac running Fedora, but not the iSight version.  If you think it's fixed
then I can just drop the patch from the Fedora kernel and we can wait for
either silence or bug reports :)

josh

Re: [PATCH 4/4] Fix iMac iSight PCI bridge setup

[Benjamin Herrenschmidt]

On Fri, 2010-02-05 at 20:03 -0500, Josh Boyer wrote:
> On Sat, Feb 06, 2010 at 07:57:46AM +1100, Benjamin Herrenschmidt wrote:
> >On Fri, 2010-02-05 at 08:55 -0500, Josh Boyer wrote:
> >> This works around the PCIe bridge setup on the iMac iSight boxen.
> >
> >Is this still needed ? I though I had fixed the root cause (incorrect
> >setup of the bridge) a while back...
> 
> I honestly have no clue, and I have no means of actually testing this.  I have
> an iMac running Fedora, but not the iSight version.  If you think it's fixed
> then I can just drop the patch from the Fedora kernel and we can wait for
> either silence or bug reports :)

I -think- it is but users of those machines are hard to find :-)

Cheers,
Ben.

Re: [PATCH 4/4] Fix iMac iSight PCI bridge setup

[David Woodhouse]

On Fri, 2010-02-05 at 20:03 -0500, Josh Boyer wrote:
> On Sat, Feb 06, 2010 at 07:57:46AM +1100, Benjamin Herrenschmidt wrote:
> >On Fri, 2010-02-05 at 08:55 -0500, Josh Boyer wrote:
> >> This works around the PCIe bridge setup on the iMac iSight boxen.
> >
> >Is this still needed ? I though I had fixed the root cause (incorrect
> >setup of the bridge) a while back...
> 
> I honestly have no clue, and I have no means of actually testing this.  I have
> an iMac running Fedora, but not the iSight version.  If you think it's fixed
> then I can just drop the patch from the Fedora kernel and we can wait for
> either silence or bug reports :)

I'll dig out the machine and test. Some time next month would be the
current estimate.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation

Re: [PATCH 0/4] Fedora kernel patch review

[Josh Boyer]

On Fri, Feb 05, 2010 at 08:35:52AM -0500, Josh Boyer wrote:
>Hi All,
>
>Below are the set of ppc/ppc64 specific patches that Fedora has been
>carrying for a very long time now.  It would be good to get some eyes
>on them to see if they could just be incorporated upstream.

David, I think you are the actual author on all 4 of these patches.
If you could look them over and reply with your Signed-off-by that
would be appreciated.

josh