linux-kernel - Re: [alsa-devel] [RFC PATCH 00/40] soundwire: updates for 5.4

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: <6db19ecc-3cb0-68f6-537f-be1df4bf2750@linux.intel.com>
Date:   Fri, 26 Jul 2019 10:23:01 -0500
From:   Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
To:     Cezary Rojewski <cezary.rojewski@...el.com>
Cc:     alsa-devel@...a-project.org, tiwai@...e.de,
        gregkh@...uxfoundation.org, linux-kernel@...r.kernel.org,
        vkoul@...nel.org, broonie@...nel.org,
        srinivas.kandagatla@...aro.org, jank@...ence.com,
        slawomir.blauciak@...el.com
Subject: Re: [alsa-devel] [RFC PATCH 00/40] soundwire: updates for 5.4

>> Comments and feedback welcome!
> 
> Hello Pierre,
> 
> This patchset is pretty large - I'd suggest dividing next RFC into 
> segments: debugfs, info, power-management, basic flow corrections and 
> frame shape calculator.

There was an intent to provide a logical progression...

First debugfs, since I believe it was reviewed before, and I wanted 
folks like Greg to double-check it without burrying it too deep.

Then all corrections, followed by the allocator.

And last all PM stuff, split by regular suspend/resume and pm_runtime.

The RFC state is precisely to gather feedback, if folks want a different 
order that's fine. I just wanted to be transparent and share what we have.

> Some commits have no messages and others lack additional info - tried to 
> provide feedback wherever I could, though, especially for the last one, 
> it would be vital to post additional info so in-depth feedback can be 
> provided.

The lack of commits is a miss, I went from 170 debug/integration patches 
to 40 yesterday and my brain was fried.

> Maybe nothing for calculator will come up, maybe something will. In 
> general I remember it being an essential part of SDW and one where many 
> bugs where found during the initial verification phase.

the frame allocation is a critical piece and it does need to be 
hardened. However we can do so in steps. The current setups we have 
support 1 Slave per link and a limited amount of bandwidth. The links 
themselves don't operate at the max frequency.
Also note that that the streams are 'statically' defined by the 
dailinks, and the allocation is not fully dynamic with random 
configurations being request. If you fail you fail fast.

Nevertheless I do plan to recheck the allocator with an additional 
scripting tool. It'd be very good to e.g. dump the current setup in a 
debugfs file and show to users what is happening (or not happening). I 
didn't recall you worked on SoundWire and I can use your practical 
knowledge to make the code and tools better :-)

> 
> Thanks for your contribution and have a good day!

Thanks for reviewing this long series and have a nice week-end.
-Pierre