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

Message-ID: <609b03e1-66e0-9bfd-cbe1-810d816df659@gmail.com>
Date:   Fri, 28 Jan 2022 22:18:52 +0200
From:   Péter Ujfalusi <peter.ujfalusi@...il.com>
To:     Jayesh Choudhary <j-choudhary@...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 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.

-- 
Péter