> This adds two sysfs attributes to /sys/bus/ibmebus which can
> be used to notify the ebus driver of added / removed ebus
> devices in the OF device tree.
We are seeing several build errors when attempting to apply this to
2.6.21-rc2:
CC arch/powerpc/kernel/ibmebus.o
This adds two sysfs attributes to /sys/bus/ibmebus which can
be used to notify the ebus driver of added / removed ebus
devices in the OF device tree.
We are seeing several build errors when attempting to apply this to
2.6.21-rc2:
CC arch/powerpc/kernel/ibmebus.o
arch/powerpc/kernel/ibmebus.c:
Looks great!
Signed-off-by: Joachim Fenkes <[EMAIL PROTECTED]>
Acked-by: John Rose <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majo
Looks great!
Signed-off-by: Joachim Fenkes [EMAIL PROTECTED]
Acked-by: John Rose [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read
CTED]>
Acked-by: John Rose <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-by: John Rose [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
> If the probe operation succeeds, the respective device will show up
> beneath
> /sys/bus/ibmebus/devices.
This approach is not particularly synchronous. Take the case of an add
failure: how long would an application wait before deciding that the new
device is not going to appear?
It might be
If the probe operation succeeds, the respective device will show up
beneath
/sys/bus/ibmebus/devices.
This approach is not particularly synchronous. Take the case of an add
failure: how long would an application wait before deciding that the new
device is not going to appear?
It might be
Hi-
Sounds good. A couple of questions/comments:
> I think it is not necessary to have a special entry/kobject for each logical
> port. I suggest we use SET_NETDEV_DEV to create links to all ethernet devices
> that represent each a logical port. This should be in sync with all other
> ethernet
Hi-
Sounds good. A couple of questions/comments:
I think it is not necessary to have a special entry/kobject for each logical
port. I suggest we use SET_NETDEV_DEV to create links to all ethernet devices
that represent each a logical port. This should be in sync with all other
ethernet
Hi-
Looks good. Questions: how can the user space tools verify the success
of an add or remove?
Also, will /sys/bus/ibmebus exist even if the system booted with no LHEA
nodes?
One more comment below.
@@ -161,7 +161,9 @@ static void __devinit ibmebus_dev_releas
static ssize_t
> Second, the probe and remove functions do not communicate whether an add
> or remove was successful. Combine this with the lack of port
> information in the adapter sysfs directory, and the userspace tool has
> no way of verifying a dynamic add/remove.
One way to communicate a return code is
Second, the probe and remove functions do not communicate whether an add
or remove was successful. Combine this with the lack of port
information in the adapter sysfs directory, and the userspace tool has
no way of verifying a dynamic add/remove.
One way to communicate a return code is by
Hi-
Looks good. Questions: how can the user space tools verify the success
of an add or remove?
Also, will /sys/bus/ibmebus exist even if the system booted with no LHEA
nodes?
One more comment below.
@@ -161,7 +161,9 @@ static void __devinit ibmebus_dev_releas
static ssize_t
Hi-
A few high level comments, then some really insignificant ones.
First, is there a reason why we shouldn't have a sysfs entry/kobject for
each logical port? How is it possible to determine, from the adapter
sysfs directory, the current number of ports for that adapter? A port
sysfs
Hi-
A few high level comments, then some really insignificant ones.
First, is there a reason why we shouldn't have a sysfs entry/kobject for
each logical port? How is it possible to determine, from the adapter
sysfs directory, the current number of ports for that adapter? A port
sysfs
> I dropped this on the floor over Christmas. This has had a few smoke
> tests on ppc64 and i386 and is ready for -mm. Against 2.6.20-rc2-mm1.
Could this break ia64, given that it uses memmap_init_zone()?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
I dropped this on the floor over Christmas. This has had a few smoke
tests on ppc64 and i386 and is ready for -mm. Against 2.6.20-rc2-mm1.
Could this break ia64, given that it uses memmap_init_zone()?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
Hi Paul-
> I'm suggesting that the rpaphp code has a struct pci_driver whose
> id_table and probe function are such that it will claim the EADS
> bridges. (It would probably be best to match on vendor=IBM and
> class=PCI-PCI bridge and let the probe function figure out which of
> the bridges it
Hi Paul-
I'm suggesting that the rpaphp code has a struct pci_driver whose
id_table and probe function are such that it will claim the EADS
bridges. (It would probably be best to match on vendor=IBM and
class=PCI-PCI bridge and let the probe function figure out which of
the bridges it gets
> Not sure that I agree with this. Not all PCI hotplug slots have EADS
> devices as parents.
Ahem, "PCI hotplug" above should read "EEH-enabled".
Sorry :)
John
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
Hi Paul-
> > 2) As a result, the code to call hot-unplug is a bit messy. In
> >particular, there's a bit of hoop-jumping when hotplug is built as
> >as a module (and said hoops were wrecked recently when I moved the
> >code around, out of the rpaphp directory).
>
> One way to clean
Hi Paul-
2) As a result, the code to call hot-unplug is a bit messy. In
particular, there's a bit of hoop-jumping when hotplug is built as
as a module (and said hoops were wrecked recently when I moved the
code around, out of the rpaphp directory).
One way to clean this up
Not sure that I agree with this. Not all PCI hotplug slots have EADS
devices as parents.
Ahem, PCI hotplug above should read EEH-enabled.
Sorry :)
John
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info
Hi Linas-
I like the idea of splitting the recovery stuff into its own driver. A
few comments on the last reorg patch:
> Index: linux-2.6.13-rc6-git9/arch/ppc64/kernel/eeh.c
...
> +static int
> +eeh_slot_availability(struct device_node *dn)
...
> +void eeh_restore_bars(struct device_node *dn)
Hi Linas-
I like the idea of splitting the recovery stuff into its own driver. A
few comments on the last reorg patch:
Index: linux-2.6.13-rc6-git9/arch/ppc64/kernel/eeh.c
...
+static int
+eeh_slot_availability(struct device_node *dn)
...
+void eeh_restore_bars(struct device_node *dn)
I like it. I'm a little hung up on the fact that actual device probing
happens in config.c rather than probe.c (if I'm correct). Regardless,
this patch set cleans things up nicely.
John
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
> It was always effectual for IO where the mask is 0x.
Okay, point taken :) So for cases of base == maxbase, why would we ever
want to return a nonzero value? What is the intended purpose of the
second part of that conditional?
-
To unsubscribe from this list: send the line "unsubscribe
It was always effectual for IO where the mask is 0x.
Okay, point taken :) So for cases of base == maxbase, why would we ever
want to return a nonzero value? What is the intended purpose of the
second part of that conditional?
-
To unsubscribe from this list: send the line unsubscribe
Can anyone lend an explanation of the following?
/* base == maxbase can be valid only if the BAR has
already been programmed with all 1s. */
if (base == maxbase && ((base | size) & mask) != mask) {
printk("%s: 2 returning 0\n", __FUNCTION__);
Can anyone lend an explanation of the following?
/* base == maxbase can be valid only if the BAR has
already been programmed with all 1s. */
if (base == maxbase ((base | size) mask) != mask) {
printk(%s: 2 returning 0\n, __FUNCTION__);
low up with return code cleanups for the entire module, and for RTAS
code, since these are probably too big for 2.6.11.
Please apply, if appropriate.
Thanks-
John
Signed-off-by: John Rose <[EMAIL PROTECTED]>
diff -puN drivers/pci/hotplug/rpaphp_core.c~01_rpaphp_is_php_fix
drivers/pci/hotplug/r
Could we please get David's fix in for 2.6.11, since it's apparently
affecting boot in some situations?
Thanks-
John
On Mon, 2005-02-07 at 11:41, John Rose wrote:
> > Er, use the result of the get_children_props() call only if it _failed_?
> > I suspect that wasn't your intention. T
Could we please get David's fix in for 2.6.11, since it's apparently
affecting boot in some situations?
Thanks-
John
On Mon, 2005-02-07 at 11:41, John Rose wrote:
Er, use the result of the get_children_props() call only if it _failed_?
I suspect that wasn't your intention. This makes my G5
with return code cleanups for the entire module, and for RTAS
code, since these are probably too big for 2.6.11.
Please apply, if appropriate.
Thanks-
John
Signed-off-by: John Rose [EMAIL PROTECTED]
diff -puN drivers/pci/hotplug/rpaphp_core.c~01_rpaphp_is_php_fix
drivers/pci/hotplug/rpaphp_core.c
35 matches
Mail list logo
