On Thu, Dec 14, 2017 at 03:40:17PM -0300, Philippe Mathieu-Daudé wrote: > >> /* Capabilities registers provide information on supported features of > >> this > >> * specific host controller implementation */ > >> -static Property sdhci_pci_properties[] = { > >> +static Property sdhci_properties[] = { > >> DEFINE_PROP_UINT32("capareg", SDHCIState, capareg, > >> SDHC_CAPAB_REG_DEFAULT), > >> DEFINE_PROP_UINT32("maxcurr", SDHCIState, maxcurr, 0), > >> + DEFINE_PROP_BOOL("pending-insert-quirk", SDHCIState, > >> pending_insert_quirk, > >> + false), > > > > I like the reduction of code in this patch, but aren't we now going to > > have device properties that aren't actually connected to anything? > > I'm not sure I understand, ar you worried about the PCI_SDHCI will now > have this property but not use it? > > I couldn't find any machine using SDHCI via PCI and was tempted to > just remove this code,
I'm not sure if you are suggesting the removal of PCI SDHCI support or removal of some of the properties. I do find qemu's PCI SDHCI support useful for testing. SeaBIOS can launch an OS from PCI SDHCI (qemu-system-x86_64 -device sdhci-pci -device sd-card,drive=drive0 -drive id=drive0,if=none,file=dos-drivec) and linux has drivers for it as well. A number of the Chromebooks ship with PCI SDHCI devices on them, so it's not an unheard of configuration. I've never manually set any of the PCI properites, however. -Kevin