linux-kernel - Re: [PATCH 2/4] soundwire: Provide build stubs for common functions

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: <20221115110345.GM10437@ediswmail.ad.cirrus.com>
Date:   Tue, 15 Nov 2022 11:03:45 +0000
From:   Charles Keepax <ckeepax@...nsource.cirrus.com>
To:     Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
CC:     <vkoul@...nel.org>, <yung-chuan.liao@...ux.intel.com>,
        <sanyog.r.kale@...el.com>, <alsa-devel@...a-project.org>,
        <linux-kernel@...r.kernel.org>, <patches@...nsource.cirrus.com>
Subject: Re: [PATCH 2/4] soundwire: Provide build stubs for common functions

On Mon, Nov 14, 2022 at 10:13:07AM -0600, Pierre-Louis Bossart wrote:
> 
> 
> On 11/14/22 04:29, Charles Keepax wrote:
> > Provide stub functions when CONFIG_SOUNDWIRE is not set for functions
> > that are quite likely to be used from common code on devices supporting
> > multiple control buses.
> 
> So far this case has been covered by splitting SoundWire related code
> away from, say I2C, and with a clear 'depends on SOUNDWIRE'. This is the
> case for rt5682, max98373, etc.
> 
> Is this not good enough?
> 
> I am not against this patch, just wondering if allowing code for
> different interfaces to be part of the same file will lead to confusions
> with e.g. register offsets or functionality exposed with different
> registers.
> 

I guess this is a bit of a grey area this one. Both work, I guess
the reason I was leaning this way is that in order to avoid a
circular dependency if I put all the soundwire DAI handling into
the soundwire code then I have to duplicate the snd_soc_dai_driver
structure into both the sdw and i2c specific code (worth noting
the I2S DAIs are still usable when the part is sdw to the host). But
there are also downsides to this approach in that it will likely have
some small impact on driver size when soundwire is not built in.

Thanks,
Charles