Re: [PATCH 11/11] ASoC: SOF: topology: Add new DAI type entry for SOF_DAI_AMD_BT

[Cristian Ciocaltea]

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@xxxxxxxxxxxxxxxx?
>>>>>>> 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