[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <Z3vKeVipRSC9ABia@opensource.cirrus.com>
Date: Mon, 6 Jan 2025 12:20:09 +0000
From: Charles Keepax <ckeepax@...nsource.cirrus.com>
To: Pierre-Louis Bossart <pierre-louis.bossart@...ux.dev>
CC: <broonie@...nel.org>, <lgirdwood@...il.com>,
<peter.ujfalusi@...ux.intel.com>, <yung-chuan.liao@...ux.intel.com>,
<linux-sound@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<patches@...nsource.cirrus.com>
Subject: Re: [PATCH 4/5] ASoC: SDCA: Add missing function type names
On Thu, Jan 02, 2025 at 04:01:19PM -0600, Pierre-Louis Bossart wrote:
> On 12/20/24 11:35, Charles Keepax wrote:
> > case SDCA_FUNCTION_TYPE_IMP_DEF:
> > - dev_warn(dev, "unsupported SDCA function type %d\n", *function_type);
> > - return -EINVAL;
> > + *function_name = SDCA_FUNCTION_TYPE_IMP_DEF_NAME;
> > + break;
>
> but this one is controversial. We really have no idea what to do in this
> case. There could be completely different 'imp-def' functions that require
> different drivers. I don't know how the entire binding mechanism would work.
> Probably best to err on the side of throwing a 'not supported' error?
>
I would certainly agree with you that a generic class driver
implementation would not bind against an imp def function, but I
see no reason to prevent custom driver implementations from being
able to access this function. They will be creating the parent
auxilary stuff and can bind whatever they like to this imp def
function.
Thanks,
Charles
Powered by blists - more mailing lists