On Thu, 2015-10-29 at 15:34 +0200, Tanu Kaskinen wrote: > On Thu, 2015-10-29 at 14:11 +0100, David Henningsson wrote: > > > > On 2015-10-29 12:49, Tanu Kaskinen wrote: > > > On Tue, 2015-10-27 at 16:09 +0100, David Henningsson wrote: > > > > Changes since v1: > > > > Â Â Â * Rebased to master (thanks Tanu) > > > > Â Â Â * Added pa_device_port_set_preferred_profile > > > > Â Â Â * pa_card_set_profile now updates preferred profile, instead > > > > Â Â Â Â Â of module-card-restore > > > > Â Â Â Â Â (to make Tanu happy - if it was up to me, I probably would have kept > > > > Â Â Â Â Â it as it was) > > > > > > If the preferred_profile semantics are module-dependent, then the > > > variable doesn't belong in the core. If you want to make module-card- > > > restore or some other module the "owner" of the semantics that are > > > implemented in this patch set, I'm fine with that, but then the > > > variable needs to move to some non-core API. > > > > preferred_profile means "the profile that this port prefers", so there's > > no module dependency in the semantics. > > > > But exactly how to determine what profile a port prefers, that's > > something that could benefit from being module dependent. > > You're right, the core isn't really any more suitable place to set the > preferred profile than module-card-restore. The problem with module- > card-restore is that it should only be about making the card state > persistent, so this kind of policy goes beyond its mandate, and the > problem with the core is that the core shouldn't really decide this > kind of policy. Creating another policy module just for this is > probably overkill. If you want, you can move the code back to module- > card-restore. I don't really have a preference any more. I forgot to add: I'm done reviewing the v2 set. --Â Tanu
