Peter Crosthwaite writes:
> On Mon, Mar 23, 2015 at 7:05 PM, Markus Armbruster wrote:
>> Paolo Bonzini writes:
>>
>>> On 23/03/2015 10:10, Markus Armbruster wrote:
[...]
I believe the proper solution for your problem is qdevifying the SD
card.
>>>
>>> The question is whether there is
On 23/03/2015 16:01, Peter Crosthwaite wrote:
> Note that SD has a SPI mode, every SD card is in theory a valid SSI
> device. We could unify SD under SSI to achieve both QOMification and
> busification.
That wouldn't really be the way most SD cards work, anyway. The
protocol doesn't do simultan
On 23 March 2015 at 15:01, Peter Crosthwaite
wrote:
> On Mon, Mar 23, 2015 at 7:05 PM, Markus Armbruster wrote:
>> If sd.c is common code rather than a device model in its own right,
>> perhaps SDState should be unboxed in SDHCIState, just like the FDrive
>> are unboxed in FDCtrl. The "drive" pr
On Mon, Mar 23, 2015 at 7:05 PM, Markus Armbruster wrote:
> Paolo Bonzini writes:
>
>> On 23/03/2015 10:10, Markus Armbruster wrote:
>>> Ugh. sdhci-pci is incorrectly qdevified: it uses drive_get_next() in
>>> its realize() method. Is it the only device model with this issue?
>>
>> I think SD d
On 23/03/2015 14:35, Markus Armbruster wrote:
>>> From 30,000ft, this looks a bit like the floppy case: BB's dev points to
>>> the block device, and BB's dev_opaque points within the device.
>>>
>>> If you descend a bit, it looks a lot more like the usb-storage hack that
>>> has caused us nothing
Paolo Bonzini writes:
> On 23/03/2015 13:09, Peter Maydell wrote:
>> > The only alternative for 2.3 is reverting the patch for sdhci-pci. I
>> > certainly don't want "-drive if=sd -device sdhci-pci" to become ABI!
>>
>> What's wrong with that, incidentally? It's what I would have
>> expected for
Paolo Bonzini writes:
> On 23/03/2015 10:10, Markus Armbruster wrote:
>> Ugh. sdhci-pci is incorrectly qdevified: it uses drive_get_next() in
>> its realize() method. Is it the only device model with this issue?
>
> I think SD devices are the only ones, but all of them have the issue.
>
> Ironi
On 23/03/2015 13:09, Peter Maydell wrote:
> > The only alternative for 2.3 is reverting the patch for sdhci-pci. I
> > certainly don't want "-drive if=sd -device sdhci-pci" to become ABI!
>
> What's wrong with that, incidentally? It's what I would have
> expected for connecting an SD card to sdh
On 23 March 2015 at 12:05, Paolo Bonzini wrote:
>
> The only alternative for 2.3 is reverting the patch for sdhci-pci. I
> certainly don't want "-drive if=sd -device sdhci-pci" to become ABI!
What's wrong with that, incidentally? It's what I would have
expected for connecting an SD card to sdhci
On 23/03/2015 10:10, Markus Armbruster wrote:
> Ugh. sdhci-pci is incorrectly qdevified: it uses drive_get_next() in
> its realize() method. Is it the only device model with this issue?
I think SD devices are the only ones, but all of them have the issue.
Ironically, the qdevified ones call d
Paolo Bonzini writes:
> Add a drive property that can be used with sdhci-pci (instead of the odd
> "-drive if=sd,... -device sdhci-pci" that has no equivalent in the rest
> of QEMU).
Ugh. sdhci-pci is incorrectly qdevified: it uses drive_get_next() in
its realize() method. Is it the only devic
11 matches
Mail list logo
