linux-kernel - Re: [PATCH v5] ASoC: dt-bindings: davinci-mcasp: convert McASP bindings to yaml schema

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] [day] [month] [year] [list]

Date:   Tue, 8 Feb 2022 21:50:20 +0530
From:   Jayesh Choudhary <j-choudhary@...com>
To:     Péter Ujfalusi <peter.ujfalusi@...il.com>,
        <robh+dt@...nel.org>
CC:     <lgirdwood@...il.com>, <broonie@...nel.org>,
        <alsa-devel@...a-project.org>, <devicetree@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v5] ASoC: dt-bindings: davinci-mcasp: convert McASP
 bindings to yaml schema



On 29/01/22 01:48, Péter Ujfalusi wrote:
> 
> On 1/17/22 12:07, Jayesh Choudhary wrote:
> 
>>>>> +properties:
>>>>> +  compatible:
>>>>> +    enum:
>>>>> +      - ti,dm646x-mcasp-audio
>>>>> +      - ti,da830-mcasp-audio
>>>>> +      - ti,am33xx-mcasp-audio
>>>>> +      - ti,dra7-mcasp-audio
>>>>> +      - ti,omap4-mcasp-audio
>>>
>>> This is the only thing which bugs me: the pointless '-audio' postfix for
>>> the compatible string...
>>>
>>
>> Removing the postfix would also require a lot of dts changes which might
>> be backward incompatible. So it is probably not a good idea.
> 
> My plan was to not convert the ti,*-mcasp-audio txt file to yaml in the
> first place, but do it right with as ti,*-mcasp
> 
> One of the outstanding issue is the multiple serializer support. It
> should be in core as things are just working by luck atm when more than
> one serializer is in use (via the card node).
> 
>> Should we still consider this?
> 
> Since we are officially documenting the -mcasp-audio, I don't think it
> would be a good idea to introduce different binding for the very same IP
> just for the sake of it.
> 
> The new (and imho correct) binding would require quite a bit of work in
> the driver and in the core level (plus the simple-card family), but I'm
> afraid, I will not have time for it.
> 

Peter,

I think all the new changes can be picked up later on.
For now, to support the current device tree and binding, I am posting a
v6 patch with 'acked-by' and 'reviewed-by' so that they are not lost in
this thread and this patch could be merged.