search for: _modern_

...st_features refer to. > > IMHO that's just too messy. > > Let's add get_legacy_features and host_legacy_features instead? > > I wanted to avoid touching anything that does not support version 1. > And this interface might still work for later revisions, no? We can add _modern_ then, or rename host_features to host_legacy_features everywhere as preparation. -- MST

...st_features refer to. > > IMHO that's just too messy. > > Let's add get_legacy_features and host_legacy_features instead? > > I wanted to avoid touching anything that does not support version 1. > And this interface might still work for later revisions, no? We can add _modern_ then, or rename host_features to host_legacy_features everywhere as preparation. -- MST

...sy. > > > > Let's add get_legacy_features and host_legacy_features instead? > > > > > > I wanted to avoid touching anything that does not support version 1. > > > And this interface might still work for later revisions, no? > > > > We can add _modern_ then, or rename host_features to host_legacy_features > > everywhere as preparation. > > > > OK, I've ditched the "don't modify old stuff" goal and introduced > ->get_features_legacy(). For now, devices will add VERSION_1 in their > ->get_features()...

...sy. > > > > Let's add get_legacy_features and host_legacy_features instead? > > > > > > I wanted to avoid touching anything that does not support version 1. > > > And this interface might still work for later revisions, no? > > > > We can add _modern_ then, or rename host_features to host_legacy_features > > everywhere as preparation. > > > > OK, I've ditched the "don't modify old stuff" goal and introduced > ->get_features_legacy(). For now, devices will add VERSION_1 in their > ->get_features()...

...; IMHO that's just too messy. > > > Let's add get_legacy_features and host_legacy_features instead? > > > > I wanted to avoid touching anything that does not support version 1. > > And this interface might still work for later revisions, no? > > We can add _modern_ then, or rename host_features to host_legacy_features > everywhere as preparation. > OK, I've ditched the "don't modify old stuff" goal and introduced ->get_features_legacy(). For now, devices will add VERSION_1 in their ->get_features() callback when they support it...

...; IMHO that's just too messy. > > > Let's add get_legacy_features and host_legacy_features instead? > > > > I wanted to avoid touching anything that does not support version 1. > > And this interface might still work for later revisions, no? > > We can add _modern_ then, or rename host_features to host_legacy_features > everywhere as preparation. > OK, I've ditched the "don't modify old stuff" goal and introduced ->get_features_legacy(). For now, devices will add VERSION_1 in their ->get_features() callback when they support it...

On Thu, Dec 11, 2014 at 02:25:20PM +0100, Cornelia Huck wrote: > Devices may support different sets of feature bits depending on which > revision they're operating at. Let's give the transport a way to > re-query the device about its features when the revision has been > changed. > > Signed-off-by: Cornelia Huck <cornelia.huck at de.ibm.com> So now we have both

On Thu, Dec 11, 2014 at 02:25:20PM +0100, Cornelia Huck wrote: > Devices may support different sets of feature bits depending on which > revision they're operating at. Let's give the transport a way to > re-query the device about its features when the revision has been > changed. > > Signed-off-by: Cornelia Huck <cornelia.huck at de.ibm.com> So now we have both