linux-kernel - Re: [PATCH] ASoC: rt5682: split i2c driver into separate module

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:   Wed, 27 May 2020 23:07:26 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Liam Girdwood <lgirdwood@...il.com>,
        Akshu Agrawal <akshu.agrawal@....com>,
        Jaroslav Kysela <perex@...ex.cz>,
        Takashi Iwai <tiwai@...e.com>,
        Oder Chiou <oder_chiou@...ltek.com>,
        Cezary Rojewski <cezary.rojewski@...el.com>,
        Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        ALSA Development Mailing List <alsa-devel@...a-project.org>
Subject: Re: [PATCH] ASoC: rt5682: split i2c driver into separate module

On Wed, May 27, 2020 at 11:57:33PM +0200, Arnd Bergmann wrote:
> On Wed, May 27, 2020 at 10:57 PM Mark Brown <broonie@...nel.org> wrote:
> > On Wed, May 27, 2020 at 09:34:13PM +0200, Arnd Bergmann wrote:

> > > +static const char *rt5682_supply_names[RT5682_NUM_SUPPLIES] = {
> > > +     "AVDD",
> > > +     "MICVDD",
> > > +     "VBAT",
> > > +};

> > I'm *fairly* sure the device needs power even with Soundwire?

> I have no idea how this is done with ACPI. I'm moving it

There are non-ACPI SoundWire systems - Qualcomm have some systems
upstream.

> back as an exported symbol. There should probably be
> some abstraction that handles this in the common part of
> the driver along with some of the other bits of
> rt5682_i2c_probe, but really don't want to shake things up
> too much and would let this be done by whoever needs to add
> DT support to the soundwire driver in the future and is able
> to test the changes.

Like I say the abstraction is generally just setting up the very basic
stuff and calling into a common init function with a few parameters.

> > This doesn't look very I2C specific either, nor do chunks of the rest of
> > the code.  The usual pattern with this stuff is to have the bus specific
> > code do bus specific stuff like setting up the regmap and then call into
> > a common init function for the shared parts of the chip.  I'd expect a
> > bit more unshared code here but not this much.

> Right, I was surprised the soundwire portion does not tie into
> device tree at all, and none of the other soundwire codecs seem
> to either and no dts files reference it, though there is some code
> for the subsystem and a binding.

The stuff that's upstream for DT platforms is for Qualcomm systems where
the reference designs are generally fully integrated with Qualcomm
components so there's limited overlap.  IIRC they also have a fairly
unusual system design with a mix of SoundWire and Slimbus usually (that
was the case for a while at least).

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)