Hi, Scott,
After reading your CPCI Hot Swap support codes, I have a suggestion
to enhance it:
How about to make it be full hot swap compliant?
I mean we could also do some works like "disable_slot" when we receive
the #ENUM & EXT signal. Hence the user could yank the hot swap board
without issuing command on the console.
How do you think about it?
Cheers,
-Stan
--
Opinions expressed are those of the author and do not represent Intel
Corporation
On Tue, 2003-01-28 at 23:50, Stanley Wang wrote:
> Hi, Scott,
> After reading your CPCI Hot Swap support codes, I have a suggestion
> to enhance it:
> How about to make it be full hot swap compliant?
> I mean we could also do some works like "disable_slot" when we receive
> the #ENUM & EXT signal. Hence the user could yank the hot swap board
> without issuing command on the console.
> How do you think about it?
>
How does this behavior translate to "full hot swap compliant"? I assume
you are talking about wording from PICMG 2.16, which in my opinion
describes the full software stack, not just the driver. Any kind of
full CPCI solution would have all the user space components to
coordinate disabling a slot before the operator physically yanks the
board (and therefore behave as PICMG specifies). I'm not so sure the
driver knows enough to make a policy decision on what to do when an
operator bypasses the world and just yanks a board out with no warning.
--rustyl
On Wed, 29 Jan 2003, Stanley Wang wrote:
> Hi, Scott,
> After reading your CPCI Hot Swap support codes, I have a suggestion
> to enhance it:
> How about to make it be full hot swap compliant?
> I mean we could also do some works like "disable_slot" when we receive
> the #ENUM & EXT signal. Hence the user could yank the hot swap board
> without issuing command on the console.
> How do you think about it?
Since most hardware devices need some form of userspace cleanup before
they can be removed, the separation of notification and extraction is
on purpose in the current cPCI hotplug driver. Full Hot Swap compliance
per the PICMG 2.1 R2.0 specification can be achieved through the use of
a daemon in userspace that:
1) detects extract requests, either through the directory notifications
sent by pci_hp_update_slot_info, or by simple polling of the latch and
adapter files.
2) does the desired userspace cleanup.
3) completes the extraction by writing 0 to the slot's power file.
For reference, I'm putting the GPL'd userspace daemon I wrote for use in
our product here at SOMA on our download site at:
ftp://oss.somanetworks.com/pub/linux/cpci/pcihotplugd/pcihotplugd-20030129.tar.gz
Note that it requires the directory notifications provided by calling
pci_hp_change_slot_info, so your sysfs patch will keep it from working
correctly.
Scott
--
Scott Murray
SOMA Networks, Inc.
Toronto, Ontario
e-mail: [email protected]
On 28 Jan 2003, Rusty Lynch wrote:
> On Tue, 2003-01-28 at 23:50, Stanley Wang wrote:
> > Hi, Scott,
> > After reading your CPCI Hot Swap support codes, I have a suggestion
> > to enhance it:
> > How about to make it be full hot swap compliant?
> > I mean we could also do some works like "disable_slot" when we receive
> > the #ENUM & EXT signal. Hence the user could yank the hot swap board
> > without issuing command on the console.
> > How do you think about it?
> >
>
> How does this behavior translate to "full hot swap compliant"? I assume
> you are talking about wording from PICMG 2.16, which in my opinion
Slight nitpick, I'm pretty sure you mean PICMG 2.12 here, it's the
(somewhat lame IMO :) hotswap software spec, 2.16 is the packet switched
backplane stuff.
> describes the full software stack, not just the driver. Any kind of
> full CPCI solution would have all the user space components to
> coordinate disabling a slot before the operator physically yanks the
> board (and therefore behave as PICMG specifies). I'm not so sure the
> driver knows enough to make a policy decision on what to do when an
> operator bypasses the world and just yanks a board out with no warning.
Exactly.
Scott
--
Scott Murray
SOMA Networks, Inc.
Toronto, Ontario
e-mail: [email protected]
On Wed, 29 Jan 2003, Scott Murray wrote:
> On 28 Jan 2003, Rusty Lynch wrote:
>
> > On Tue, 2003-01-28 at 23:50, Stanley Wang wrote:
> > > Hi, Scott,
> > > After reading your CPCI Hot Swap support codes, I have a suggestion
> > > to enhance it:
> > > How about to make it be full hot swap compliant?
> > > I mean we could also do some works like "disable_slot" when we receive
> > > the #ENUM & EXT signal. Hence the user could yank the hot swap board
> > > without issuing command on the console.
> > > How do you think about it?
> > >
> >
> > How does this behavior translate to "full hot swap compliant"? I assume
> > you are talking about wording from PICMG 2.16, which in my opinion
>
> Slight nitpick, I'm pretty sure you mean PICMG 2.12 here, it's the
> (somewhat lame IMO :) hotswap software spec, 2.16 is the packet switched
> backplane stuff.
Yeah, I mean PCIMG 2.12 here.
Regards,
-Stan
--
Opinions expressed are those of the author and do not represent Intel
Corporation
On Wed, 29 Jan 2003, Scott Murray wrote:
> On Wed, 29 Jan 2003, Stanley Wang wrote:
>
> > Hi, Scott,
> > After reading your CPCI Hot Swap support codes, I have a suggestion
> > to enhance it:
> > How about to make it be full hot swap compliant?
> > I mean we could also do some works like "disable_slot" when we receive
> > the #ENUM & EXT signal. Hence the user could yank the hot swap board
> > without issuing command on the console.
> > How do you think about it?
>
> Since most hardware devices need some form of userspace cleanup before
> they can be removed, the separation of notification and extraction is
> on purpose in the current cPCI hotplug driver. Full Hot Swap compliance
> per the PICMG 2.1 R2.0 specification can be achieved through the use of
> a daemon in userspace that:
>
> 1) detects extract requests, either through the directory notifications
> sent by pci_hp_update_slot_info, or by simple polling of the latch and
> adapter files.
> 2) does the desired userspace cleanup.
> 3) completes the extraction by writing 0 to the slot's power file.
>
> For reference, I'm putting the GPL'd userspace daemon I wrote for use in
> our product here at SOMA on our download site at:
>
> ftp://oss.somanetworks.com/pub/linux/cpci/pcihotplugd/pcihotplugd-20030129.tar.gz
>
> Note that it requires the directory notifications provided by calling
> pci_hp_change_slot_info, so your sysfs patch will keep it from working
> correctly.
Yes, I think this is the proper way to be compliant to PICMG 2.1.
Many thanks to you all.
Best Regards,
-Stan
--
Opinions expressed are those of the author and do not represent Intel
Corporation