Re: [RFC PATCH 0/3] alsa-lib/ASoC: use inclusive language for bclk/fsync/topology

[Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>]

On 9/4/20 3:50 AM, Mark Brown wrote:
> On Thu, Sep 03, 2020 at 04:32:22PM -0500, Pierre-Louis Bossart wrote:
>> On 9/3/20 3:42 PM, Jaroslav Kysela wrote:
> 
>>>
>>> Only my 2 cents: It's just another word combo. See bellow for sources for others.
>>>
>>> I would prefer probably provider/consumer . It sounds more technic.
> 
>> Thanks Jaroslav for chiming in. I had a similar set of comments in internal
>> reviews, but we didn't really have any consensus and I have not seen good
>> guidance specifically for clocks.
> 
>> Provider/consumer is typically used for discrete data exchange with some
>> sort of locking and buffer fullness metric, but for clocks we'd want
>> something that hints at one device following the timing defined by another.
> 
>> "follow" or "track" seem clearer than 'consume' IMHO, but I will side with
>> the majority, this is an RFC which can be modified at will.
> 
> Producer/consumer is already quite widely used for clocks (possibly
> following the regulator API which was templated off the clock API and
> uses consumer).  The follow/track stuff definitely seems awkward to me.
> Have we seen any movement from anyone like CODEC vendors on this?

No, I haven't seen any input from CODEC vendors.

I'll use consumer then since that's preferred by both Jaroslav and Mark. 
Thanks for the feedback.