linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Garrett D'Amore" <garrett@damore.org>
To: Maxim Levitsky <maximlevitsky@gmail.com>
Cc: Robert Hancock <hancockrwd@gmail.com>,
	pierre@ossman.eu, sdhci-devel@lists.ossman.eu,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [Sdhci-devel] SDHCI driver runnining in aspire one, allows to write to R/O SD cards
Date: Mon, 27 Apr 2009 15:13:08 -0700	[thread overview]
Message-ID: <49F62DF4.5070709@damore.org> (raw)
In-Reply-To: <1240859254.11237.8.camel@maxim-laptop>

Maxim Levitsky wrote:
> On Mon, 2009-04-27 at 11:12 -0700, Garrett D'Amore wrote:
>   
>> As an extra data point, my sdhost driver in OpenSolaris works fine on 
>> the AA1.. it does see that the cards are locked, and refuses to allow 
>> them to be mounted read/write.
>>
>> This leads me to believe that the original linux problem is one of two 
>> things:
>>
>> * either a bug in the linux code, or
>> * busted circuit/hardware on a specific unit (i.e. a damaged unit)
>>
>> I believe that if the Linux code was buggy here, the problem would be 
>> reproducible on all platforms, not just the AA1.  So my inclination, 
>> barring independent confirmation, is that most likely there are one ore 
>> more defective units out there.
>>
>> Note that the AA1 also has buggy BIOS -- OpenSolaris can't "see" the 
>> cards (registers aren't properly initialized) unless they are present 
>> when the unit first powers up.
>>     
>
> But, why it works in windows?
>   

The Microsoft PCI code base probably is more willing to "work around" 
BIOSes that don't properly configure PCI configuration registers... this 
is an outstanding RFE for Solaris.

The Windows code base also has some other unrelated quirks in it -- it 
uses DAT3 for card presence detection instead of the card detect bit in 
the sdhci controller, for example.   (It also doesn't support MMC, which 
is to blame for some of the bastardized controller hacks that mfgrs like 
Ricoh have done to separate their MMC and SDcard handling into separate 
PCI functions.  Yes, that's a hardware workaround for a software bug!  
Go figure -- its what happens when one software company has a virtual 
monopoly...)

    -- Garrett
> Regards,
> 	Maxim Levitsky
>
>   


  reply	other threads:[~2009-04-27 22:19 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-20  9:29 SDHCI driver runnining in aspire one, allows to write to R/O SD cards Maxim Levitsky
2009-04-20 23:42 ` Robert Hancock
2009-04-23 22:10   ` Maxim Levitsky
2009-04-26 15:21     ` Maxim Levitsky
2009-04-27 18:12       ` [Sdhci-devel] " Garrett D'Amore
2009-04-27 19:07         ` Maxim Levitsky
2009-04-27 22:13           ` Garrett D'Amore [this message]
2009-05-03 19:29         ` Pierre Ossman
2009-05-03 20:42           ` Garrett D'Amore

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=49F62DF4.5070709@damore.org \
    --to=garrett@damore.org \
    --cc=hancockrwd@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maximlevitsky@gmail.com \
    --cc=pierre@ossman.eu \
    --cc=sdhci-devel@lists.ossman.eu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).