On Thu, Jul 03, 2008 at 09:08:31PM -0700, Paul Goyette wrote:
[...]
>> Interestingly enough, you explicitely define an interface attribute
>> (sdmmcbus) when you don't necessarily have to (because only sdmmc-like
>> devices will attach to sdhc), and you don't when you really mean to.
>
> However it's quite conceivable that sdmmc devices might well be able to
> attach via other hardware than sdhc. Indeed, that other hardware might not
> even be PCI-based. In this case, the specific card sdhc provides an
> abstracted interface to the sdmmc device. Using an sdmmcbus for this
> interface seemed reasonable. But you're right, it really doesn't add any
> functionality and could easily be removed.
But leave it in, please :) That argument works both ways, if soething
else ever expose an sdhc-like interface, things will just work, as you
understodd.
> (As a side note, this driver was originally developed for OpenBSD, and was
> ported to NetBSD by Nonaka Kimihiro. There was some objection back in
> March about using a scsipi abstraction for the memory cards, and a
> suggestion to move it to using the ld(4) interface.)
Yes, I remember that. I was wondering is you were using the same code.
>>> Since I need to have _two_ children, I can run config_match*() twice, but I
>>> need to have the ld driver get selected the first time, and the other
>>> driver selected on the second call.
>>
>> If you have 2 devices, you need to call config_found_ia() twice (and
>> make sure you have the APIs). In this case you want two different IAs
>> because they are very different devices to which you won't pass the same
>> information. It should never be the responsibility of the child device
>> to decide whether its match function was called rightfully or not.
>
> So in this case I would have (possibly)
>
> device sdmmc { } : sdmmc_io sdmmc_mem
> ...
> attach ld at sdmmc_mem with ld_sdmmc
> ...
> device othercard at sdmmc_io
That's broken config(5) syntax, but I get the idea. You want to drop
the {} in the device line if you use interface attributes, to avoid
further confusion.
> This way there's two separate interfaces offered by sdmmc, and one of those
> (sdmmc_mem) is another option for ld to use.
>
> Does this look more sane?
Yes.
>> Reading your questions though, and considering I know nothing of the
>> SDHC spec, I wonder if the ld device belongs where you put it in your
>> scheme. Do the cards always provide a mass-storage interface? Or is it
>> just another interface among other possible ones? In the latter case,
>> you'd need another device to be the parent of the ld, so that all
>> functions of the card are equals and enumerated without specific cases
>> by the sdmmc device.
>
> In the case of "Combo" cards, the card offers multiple functions, but the
> "memory" function can show up anywhere, or everywhere. It can be "piggy
> back" on an othercard or it could have its own function.
So a function attaching at sdmmc_io could itself expose a sdmmc_mem
interface?
--
Quentin Garnier - cube%cubidou.net@localhost - cube%NetBSD.org@localhost
"See the look on my face from staying too long in one place
[...] every time the morning breaks I know I'm closer to falling"
KT Tunstall, Saving My Face, Drastic Fantastic, 2007.
Attachment:
pgpIWPcBCOmNd.pgp
Description: PGP signature