> 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.
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
D]>
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/
> 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-
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 ibmebusdev_show
> 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-
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 directory
> 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
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 g
> 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 majordom
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 th
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
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 lin
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__);
x27;ll
follow 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
driver
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 yo
> 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 boot again:
Doh, good catch! This was an oversight while patching multiple trees
for this bug. Previous versions of that function use 1 for success.
Sigh. BTW, yo
19 matches
Mail list logo
