[RFC] Enhance CPCI Hot Swap driver

[RFC] Enhance CPCI Hot Swap driver

[Stanley Wang]

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

Re: [Pcihpd-discuss] [RFC] Enhance CPCI Hot Swap driver

[Rusty Lynch]

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

Re: [Pcihpd-discuss] [RFC] Enhance CPCI Hot Swap driver

[Scott Murray]

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: scottm@somanetworks.com

Re: [Pcihpd-discuss] [RFC] Enhance CPCI Hot Swap driver

[Stanley Wang]

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

Re: [RFC] Enhance CPCI Hot Swap driver

[Scott Murray]

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: scottm@somanetworks.com

Re: [RFC] Enhance CPCI Hot Swap driver

[Stanley Wang]

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

RE: [Pcihpd-discuss] [RFC] Enhance CPCI Hot Swap driver

[Ed Vance]

On Tue, January 28, 2003 at 12:40 AM, 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
> 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.

How is this functionally different from ejecting a PCMCIA card in use? Is
the driver obligated to do more than prevent a system crash and present
errors to user level until the last close? 

Ed

RE: [Pcihpd-discuss] [RFC] Enhance CPCI Hot Swap driver

[Scott Murray]

On Wed, 29 Jan 2003, Ed Vance wrote:

> On Tue, January 28, 2003 at 12:40 AM, 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
> > 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.
> 
> How is this functionally different from ejecting a PCMCIA card in use? Is
> the driver obligated to do more than prevent a system crash and present
> errors to user level until the last close? 

cPCI hotswap as defined in the PICMG 2.1 specification is a different 
beast from PCMCIA because it was purposely defined to give software a 
chance to do something before the device disappears.  The specification
even goes so far as to say that the system is in an undefined state if
a device is yanked without waiting for the system software indicating it
is safe to do so.  In reality, handling someone yanking a board is indeed 
desireable, although it seems unlikely that the vast array of PCI device
drivers will ever get updated to handle it.

Scott


-- 
Scott Murray
SOMA Networks, Inc.
Toronto, Ontario
e-mail: scottm@somanetworks.com