linux-kernel - Re: [PATCH 11/11] ASoC: SOF: topology: Add new DAI type entry for SOF_DAI_AMD

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <f3d98291-0bf6-45b2-bf4f-b0268d13af63@collabora.com>
Date: Fri, 15 Dec 2023 12:57:34 +0200
From: Cristian Ciocaltea <cristian.ciocaltea@...labora.com>
To: Venkata Prasad Potturu <venkataprasad.potturu@....com>,
 Mark Brown <broonie@...nel.org>
Cc: Liam Girdwood <lgirdwood@...il.com>, Jaroslav Kysela <perex@...ex.cz>,
 Takashi Iwai <tiwai@...e.com>,
 Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>,
 Peter Ujfalusi <peter.ujfalusi@...ux.intel.com>,
 Bard Liao <yung-chuan.liao@...ux.intel.com>,
 Ranjani Sridharan <ranjani.sridharan@...ux.intel.com>,
 Daniel Baluta <daniel.baluta@....com>,
 Kai Vehmanen <kai.vehmanen@...ux.intel.com>,
 Alper Nebi Yasak <alpernebiyasak@...il.com>,
 Syed Saba Kareem <Syed.SabaKareem@....com>,
 Kuninori Morimoto <kuninori.morimoto.gx@...esas.com>,
 Marian Postevca <posteuca@...ex.one>,
 Vijendar Mukunda <Vijendar.Mukunda@....com>,
 V sujith kumar Reddy <Vsujithkumar.Reddy@....com>,
 Mastan Katragadda <Mastan.Katragadda@....com>,
 Ajit Kumar Pandey <AjitKumar.Pandey@....com>, linux-sound@...r.kernel.org,
 linux-kernel@...r.kernel.org, sound-open-firmware@...a-project.org,
 kernel@...labora.com
Subject: Re: [PATCH 11/11] ASoC: SOF: topology: Add new DAI type entry for
 SOF_DAI_AMD_BT

On 12/15/23 11:58, Venkata Prasad Potturu wrote:
> 
> On 12/14/23 22:12, Cristian Ciocaltea wrote:
>> On 12/14/23 15:15, Venkata Prasad Potturu wrote:
>>> On 12/14/23 17:53, Cristian Ciocaltea wrote:
>>>> On 12/11/23 07:58, Venkata Prasad Potturu wrote:
>>>>> On 12/10/23 21:20, Cristian Ciocaltea wrote:
>>>>>> On 12/10/23 16:01, Mark Brown wrote:
>>>>>>> On Sun, Dec 10, 2023 at 12:12:53PM +0200, Cristian Ciocaltea wrote:
>>>>>>>> On 12/10/23 11:51, Venkata Prasad Potturu wrote:
>>>>>>>>> This should send to SOF git repo for rewiew, once SOF reviewers
>>>>>>>>> approved
>>>>>>>>> this, again need to send to broonie git.
>>>>>>>>> All the changes in sound/soc/sof/ path should go to SOF git.
>>>>>>>> Unfortunately I'm not familiar with the SOF dev workflow. So
>>>>>>>> it's not
>>>>>>>> enough to have this patch cc-ed to
>>>>>>>> sound-open-firmware@...a-project.org?
>>>>>>> The SOF people basically do their own thing in github at
>>>>>>>
>>>>>>>       https://github.com/thesofproject/linux
>>>>>>>
>>>>>>> with a github workflow and submit their patches upstream in
>>>>>>> batches a
>>>>>>> few times a release, however my understanding is that their
>>>>>>> workflow can
>>>>>>> cope with things going in directly upstream as well.
>>>>>> Thanks for clarifying, Mark!  That would greatly simplify and speedup
>>>>>> the whole process, at least for trivial patches like this one.
>>>>> Hi Cristian,
>>>>>
>>>>> We have created a Pull request in SOF git hub for I2S BT support.
>>>>> please hold v2 version SOF patches till below PR get's merged.
>>>>> PR:- https://github.com/thesofproject/linux/pull/4742
>>>> Hi Venkata,
>>>>
>>>> If this is going to be handled via the github workflow, this patch
>>>> should be removed from the series.  Since there is no dependency on it,
>>>> I cannot see a reason to put v2 on hold.
>>>>
>>>> Do I miss something?
>>> Non-sof driver related patches can directly send to broonie git ad v2
>>> series.
>>> SOF driver patches should send to SOF github to avoid merge conflicts
>>> as  per guidelines of SOF community.
>> Honestly, I don't really see a high risk of conflicts, the patches are
>> not that complex and can be simply cherry-picked when needed.  Moreover,
>> as we already had people reviewing this, splitting this up will only add
>> confusion and unnecessary burden.
>>
>> Are there any specific changes you are concerned about and cannot be
>> really handled here?
> This is not the concern about this patch series,
> Generally sof driver patches sends to SOF git hub as a PR, these are the
> guidelines by SOF maintainers.
> If you still want to send alsa devel list directly, please discuss with
> SOF maintainers.

I think this series makes sense as a whole and it's best to be handled
here, as it only provides trivial fixes to issues found on mainline.

If the SOF workflow is unable to integrate fixes submitted upstream, I
would perceive that as a significant drawback of adhering to that
process.  It is hard to believe, though, that this is really the case.

Hence, I kindly ask everyone here to shed some light and help move this
forward.

Thank you,
Cristian