On Wed, Mar 15 2023, "Michael S. Tsirkin" <m...@redhat.com> wrote:
> On Wed, Mar 15, 2023 at 04:55:59PM +0100, Cornelia Huck wrote:
>> On Fri, Mar 10 2023, Igor Skalkin <igor.skal...@opensynergy.com> wrote:
>> > +\subsection{Feature bits}\label{sec:Device Types / BT Device / Feature
>> > bits}
>> > +
>> > +\begin{description}
>> > +\item[VIRTIO_BT_F_VND_HCI (0)] Indicates vendor command support.
>> > +\item[VIRTIO_BT_F_MSFT_EXT (1)] Indicates MSFT vendor support.
>> > +\item[VIRTIO_BT_F_AOSP_EXT (2)] Indicates AOSP vendor support.
>> > +\item[VIRTIO_BT_F_CONFIG_V2 (3)] The device uses the second version of the
>> > +configuration space structure.
>> > +\end{description}
>> > +
>> > +\devicenormative{\subsubsection}{Feature bits}{Device Types / BT Device /
>> > Feature bits}
>> > +
>> > +The device MUST require the driver to accept the VIRTIO_BT_F_CONFIG_V2
>> > feature
>> > +bit, i.e. not set FEATURES_OK without it, and use the second version
>> > +(struct virtio_bt_config_v2) of the configuration layout, because the
>> > +first one (struct virtio_bt_config) is unaligned, which violates the
>> > +specification.
>>
>> Did we have a device or driver that didn't use v2? I'm not sure we want
>> to add a feature for that, other than for backwards compatibility.
>
> Linux drivers use a different layout, yes.
Oh, indeed.
>
> I think it should be possible to implement device without
> VIRTIO_BT_F_CONFIG_V2 if someone wants to be compatible.
So, do we need to downgrade the requirements for this feature to SHOULD?
>
> And hmm we need to get back to addressing the negotiation mess ...
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
