On Wed, Mar 15, 2023 at 05:20:09PM +0100, Cornelia Huck wrote: > On Wed, Mar 15 2023, "Michael S. Tsirkin" <[email protected]> wrote: > > > On Wed, Mar 15, 2023 at 04:55:59PM +0100, Cornelia Huck wrote: > >> On Fri, Mar 10 2023, Igor Skalkin <[email protected]> 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 ...
For devices I would downgrade it to MAY even. -- MST --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
