John Rose <[EMAIL PROTECTED]> wrote on 20.02.2007 12:25:06:
> > 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
> 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
John Rose [EMAIL PROTECTED] wrote on 20.02.2007 12:25:06:
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
Sylvain Munaut <[EMAIL PROTECTED]> wrote on 15.02.2007 15:11:42:
> Mmmh, I posted a patch that added a common uevent interface for all
> of_device based bus. And that kinda clash with this one.
Oops, I was not aware of this. I had a look at your patch and yes, it's a
nice
and generic interface.
John Rose <[EMAIL PROTECTED]> wrote on 15.02.2007 14:57:37:
> Looks good. Questions: how can the user space tools verify the success
> of an add or remove?
If the probe operation succeeds, the respective device will show up
beneath
/sys/bus/ibmebus/devices.
> Also, will /sys/bus/ibmebus
John Rose [EMAIL PROTECTED] wrote on 15.02.2007 14:57:37:
Looks good. Questions: how can the user space tools verify the success
of an add or remove?
If the probe operation succeeds, the respective device will show up
beneath
/sys/bus/ibmebus/devices.
Also, will /sys/bus/ibmebus exist
Sylvain Munaut [EMAIL PROTECTED] wrote on 15.02.2007 15:11:42:
Mmmh, I posted a patch that added a common uevent interface for all
of_device based bus. And that kinda clash with this one.
Oops, I was not aware of this. I had a look at your patch and yes, it's a
nice
and generic interface. I
Hoang-Nam Nguyen wrote:
> Additionally, the uevent interface is now implemented in the driver.
>
Mmmh, I posted a patch that added a common uevent interface for all
of_device based
bus. And that kinda clash with this one.
I think it's a much cleaner approach to make it as common as possible.
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
This patch will add 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.
Echoing the device's location code (as found in the OFDT "ibm,loc-code"
property) into the "probe" attribute will notify ebus of addition
This patch will add 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.
Echoing the device's location code (as found in the OFDT ibm,loc-code
property) into the probe attribute will notify ebus of addition of
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
Hoang-Nam Nguyen wrote:
Additionally, the uevent interface is now implemented in the driver.
Mmmh, I posted a patch that added a common uevent interface for all
of_device based
bus. And that kinda clash with this one.
I think it's a much cleaner approach to make it as common as possible.
But
14 matches
Mail list logo
