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]
Date:   Thu, 4 Oct 2018 03:43:35 +0000
From:   Kuninori Morimoto <kuninori.morimoto.gx@...esas.com>
To:     Jiada Wang <jiada_wang@...tor.com>
Cc:     <lgirdwood@...il.com>, <broonie@...nel.org>, <perex@...ex.cz>,
        <tiwai@...e.com>, <alsa-devel@...a-project.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [alsa-devel] [PATCH linux-next v2 9/9] ASoC: rsnd: add busif property to dai stream


Hi Jiada

Thank you for your feedback

> >> in GEN3 SSI may use different BUSIF for data transfer,
> >> this patch adds busif property to each dai stream,
> >> to indicate the BUSIF used by playback/capture stream.
> >> 
> >> Also adds rsnd_ssi_select_busif() to automatically select
> >> BUSIF (currently only BUSIF0 is selected)
> >> 
> >> Signed-off-by: Jiada Wang <jiada_wang@...tor.com>
> >> ---
(snip)
> > And this patch selects it on runtime (= hw_param) ?
> Because, in order to automatically determine BUSIF number,
> information like SSI mode (non-Split/Split/Ex-Split), runtime channel,
> are required
> (in our internal implementation, SSI mode is selected by kctrl)
> because of this, in this patch, BUSIF is selected on runtime
> 
> > But, I think we can/should select it on probe timing from DT connection.
> > Am I misunderstanding ?
> with the above reasoning, BUSIF is selected on runtime.
> what do you think?

I have no objection that you are customizing your kernel locally.
But, upstreaming kernel based on it is not acceptable for me.
I'm not sure detail of your local implementation, but I don't think we
need to select SSI mode by kctrl.
If my understanding was correct, it can also be selected automatically somehow.
Or, am I misunderstanding ?

I could understand what you want to do, and yes, I can agree that we want/need
to have it on upstream. Thank you very much to indicating it to me.
But we need to consider more how to implement it.
Especially, it is related to DT bindings.
As you already know, if it is implemented on upstream kernel, we need to keep
compatibility in the future, and it is very difficult.

So, my opinions for BUSIFn support are
	- SSI mode should be selected automatically
	- BUSIFn connection should be selected on DT
	  (I think we don't want random sound output position ?)
	  - To select it, we need to have new "ssiu" DT seetings,
	    or parse sound card. Maybe adding ssiu is realistic.


Best regards
---
Kuninori Morimoto

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ