From gd78059@sac.sfbay.sun.com Thu Oct 22 13:41:13 2009
Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n9MKfC9C022196
	for <psarc-ext@sac.sfbay.sun.com>; Thu, 22 Oct 2009 13:41:12 -0700 (PDT)
Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6])
	by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n9MKf3MO029924;
	Thu, 22 Oct 2009 21:41:11 +0100 (BST)
Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by
 nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0KRX0040TO4KAA00@nwk-avmta-2.sfbay.sun.com>; Thu,
 22 Oct 2009 13:41:08 -0700 (PDT)
Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118])
 by nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0KRX00MNNO4I8I50@nwk-avmta-2.sfbay.sun.com>; Thu,
 22 Oct 2009 13:41:06 -0700 (PDT)
Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132])
	by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4)
 with ESMTP id n9MKf6mi017200; Thu, 22 Oct 2009 13:41:06 -0700 (PDT)
Received: from sac.sfbay.sun.com (localhost [127.0.0.1])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n9MKf4Xc022184; Thu,
 22 Oct 2009 13:41:04 -0700 (PDT)
Received: (from gd78059@localhost)
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n9MKf4Sg022176; Thu,
 22 Oct 2009 13:41:04 -0700 (PDT)
Date: Thu, 22 Oct 2009 13:41:04 -0700 (PDT)
From: "Garrett D'Amore - sun microsystems" <gd78059@sac.sfbay.sun.com>
Subject: Remove SDcard support on SPARC [PSARC/2009/578 Self Review]
To: PSARC-ext@sun.com
Cc: Garrett.Damore@sun.com
Message-id: <200910222041.n9MKf4Sg022176@sac.sfbay.sun.com>
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.4.1.325704
Status: RO
Content-Length: 2505


I'm filing the following case to clean up some software which _probably_
should have been removed along with the SPARCLE support (PSARC 2008/538).
In theory, the software could be useful to other SPARC platforms, but
no such platforms exist today, and none are anticipated, which is why
I'm filing this as a self-review.  If anyone believes it deserves more
discussion, please speak up and I will happily promote the case to a
fast track.

	- Garrett

Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI
This information is Copyright 2009 Sun Microsystems
1. Introduction
    1.1. Project/Component Working Name:
	 Remove SDcard support on SPARC
    1.2. Name of Document Author/Supplier:
	 Author:  Garrett D'Amore
    1.3  Date of This Document:
	22 October, 2009
4. Technical Description

Problem
-------

With the removal of the "wbsd" driver (as part of PSARC 2009/538 -- the Tadpole
SPARCLE EOF), it turns out that there is probably no other implementation of
SDcard in use on SPARC.  (Exception: USB media adapters, but they don't use
the SDcard stack discussed here.)

Today we deliver the architecture neutral "sdhost" driver, which supports
a PCI based controller.  While in theory this could mean that someone could
install a PCI card (or build a motherboard) with one of these devices on
it, we have never seen such a PCI card.  (Presumably some kind of evaluation
boards must exist, but we don't believe they've ever been generally available
on the market.  We've certainly never seen one before.)

There are no other SDcard host adapter drivers (now that "wbsd" has been
removed.)  As a result its impossible to sustain the existing code on SPARC,
since we can't even test it.

We therefore propose to remove the entire SDcard stack from the SPARC
delivery.  If a need were to arise, we could easily restore this
functionality, although we believe it is unlikely that there will ever
be a need for either add-in card with SDcard support, or for SPARC
motherboards with onboard SDcard media slots.

Note that this does NOT affect the USB based adapters, which only support
the SDcard storage devices (not SDIO), and which do not use the SDcard
stack.  (They instead emulate USB mass storage devices.)

As this will not affect any current SPARC customers, we do not believe any
notification is necessary.


6. Resources and Schedule
    6.4. Steering Committee requested information
   	6.4.1. Consolidation C-team Name:
		ON
    6.5. ARC review type: Automatic
    6.6. ARC Exposure: open


From Garrett.Damore@Sun.com Thu Oct 22 13:43:52 2009
Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n9MKhp1D022283
	for <psarc-ext@sac.sfbay.sun.com>; Thu, 22 Oct 2009 13:43:52 -0700 (PDT)
Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74])
	by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n9MKhhhl018747
	for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 23 Oct 2009 04:43:50 +0800 (SGT)
Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by
 nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0KRX00H3DO92K700@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com
 (ORCPT PSARC-ext@sun.com); Thu, 22 Oct 2009 13:43:50 -0700 (PDT)
Received: from sca-es-mail-1.sun.com ([192.18.43.132])
 by nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0KRX00B01O89CI60@nwk-avmta-1.sfbay.Sun.COM> for
 PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu,
 22 Oct 2009 13:43:21 -0700 (PDT)
Received: from fe-sfbay-09.sun.com ([192.18.43.129])
	by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n9MKhL0L016467	for
 <PSARC-ext@sun.com>; Thu, 22 Oct 2009 13:43:21 -0700 (PDT)
Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com
 (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul  2 2009))
 id <0KRX00K00O6LP300@fe-sfbay-09.sun.com> for PSARC-ext@sun.com
 (ORCPT PSARC-ext@sun.com); Thu, 22 Oct 2009 13:43:21 -0700 (PDT)
Received: from [192.168.251.11] ([unknown] [76.93.15.33])
 by fe-sfbay-09.sun.com
 (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul  2 2009))
 with ESMTPSA id <0KRX006RYO870Q40@fe-sfbay-09.sun.com>; Thu,
 22 Oct 2009 13:43:20 -0700 (PDT)
Date: Thu, 22 Oct 2009 13:43:19 -0700
From: "Garrett D'Amore" <Garrett.Damore@Sun.com>
Subject: Re: Remove SDcard support on SPARC [PSARC/2009/578 Self Review]
In-reply-to: <200910222041.n9MKf4Sg022176@sac.sfbay.sun.com>
Sender: Garrett.Damore@Sun.com
To: "Garrett D'Amore - sun microsystems" <gd78059@sac.sfbay.sun.com>
Cc: PSARC-ext@Sun.com
Reply-to: Garrett.Damore@Sun.com
Message-id: <4AE0C3E7.2000701@sun.com>
MIME-version: 1.0
Content-type: text/plain; CHARSET=US-ASCII; format=flowed
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.4.1.325704
References: <200910222041.n9MKf4Sg022176@sac.sfbay.sun.com>
User-Agent: Thunderbird 2.0.0.22 (X11/20090909)
Status: RO
Content-Length: 2933

I forgot to mention: this is patch binding.  The actual objects I'd 
remove would be:

/kernel/drv/sparcv9/sdcard
/kernel/drv/sparcv9/sdhost
/kernel/misc/sparcv9/sda

These are contained in the SUNWsdcard package, which would also be 
removed from SPARC.

    - Garrett

Garrett D'Amore - sun microsystems wrote:
> I'm filing the following case to clean up some software which _probably_
> should have been removed along with the SPARCLE support (PSARC 2008/538).
> In theory, the software could be useful to other SPARC platforms, but
> no such platforms exist today, and none are anticipated, which is why
> I'm filing this as a self-review.  If anyone believes it deserves more
> discussion, please speak up and I will happily promote the case to a
> fast track.
>
> 	- Garrett
>
> Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI
> This information is Copyright 2009 Sun Microsystems
> 1. Introduction
>     1.1. Project/Component Working Name:
> 	 Remove SDcard support on SPARC
>     1.2. Name of Document Author/Supplier:
> 	 Author:  Garrett D'Amore
>     1.3  Date of This Document:
> 	22 October, 2009
> 4. Technical Description
>
> Problem
> -------
>
> With the removal of the "wbsd" driver (as part of PSARC 2009/538 -- the Tadpole
> SPARCLE EOF), it turns out that there is probably no other implementation of
> SDcard in use on SPARC.  (Exception: USB media adapters, but they don't use
> the SDcard stack discussed here.)
>
> Today we deliver the architecture neutral "sdhost" driver, which supports
> a PCI based controller.  While in theory this could mean that someone could
> install a PCI card (or build a motherboard) with one of these devices on
> it, we have never seen such a PCI card.  (Presumably some kind of evaluation
> boards must exist, but we don't believe they've ever been generally available
> on the market.  We've certainly never seen one before.)
>
> There are no other SDcard host adapter drivers (now that "wbsd" has been
> removed.)  As a result its impossible to sustain the existing code on SPARC,
> since we can't even test it.
>
> We therefore propose to remove the entire SDcard stack from the SPARC
> delivery.  If a need were to arise, we could easily restore this
> functionality, although we believe it is unlikely that there will ever
> be a need for either add-in card with SDcard support, or for SPARC
> motherboards with onboard SDcard media slots.
>
> Note that this does NOT affect the USB based adapters, which only support
> the SDcard storage devices (not SDIO), and which do not use the SDcard
> stack.  (They instead emulate USB mass storage devices.)
>
> As this will not affect any current SPARC customers, we do not believe any
> notification is necessary.
>
>
> 6. Resources and Schedule
>     6.4. Steering Committee requested information
>    	6.4.1. Consolidation C-team Name:
> 		ON
>     6.5. ARC review type: Automatic
>     6.6. ARC Exposure: open
>
>   


