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:   Fri, 22 Jan 2021 13:21:21 +0000
From:   Charles Keepax <ckeepax@...nsource.cirrus.com>
To:     Hans de Goede <hdegoede@...hat.com>
CC:     Richard Fitzgerald <rf@...nsource.cirrus.com>,
        Andy Shevchenko <andy.shevchenko@...il.com>,
        Lee Jones <lee.jones@...aro.org>,
        Cezary Rojewski <cezary.rojewski@...el.com>,
        Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>,
        Liam Girdwood <liam.r.girdwood@...ux.intel.com>,
        Jie Yang <yang.jie@...ux.intel.com>,
        Mark Brown <broonie@...nel.org>,
        <patches@...nsource.cirrus.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        ALSA Development Mailing List <alsa-devel@...a-project.org>
Subject: Re: [PATCH v2 08/12] ASoC: arizona-jack: convert into a helper
 library for codec drivers

On Thu, Jan 21, 2021 at 05:55:00PM +0100, Hans de Goede wrote:
> On 1/19/21 10:51 AM, Richard Fitzgerald wrote:
> > On 18/01/2021 17:24, Andy Shevchenko wrote:
> >> On Sun, Jan 17, 2021 at 6:06 PM Hans de Goede <hdegoede@...hat.com> wrote:
> 1. Keep the code as is, live with the debugfs error. This might be
> best for now, as I don't want to grow the scope of this series too much.
> I will go with this for the next version of this series (unless
> I receive feedback otherwise before I get around to posting the next
> version).

Thinking about this more, I seem to remember this is something
that has been discussed before, having the need to have
situations where a driver and the framework are both managing the
regulator at once on the same device.

I wonder if this commit was related to that:

commit ff268b56ce8c ("regulator: core: Don't spew backtraces on duplicate sysfs")

Apologies I don't have as much time as I normally would to look
into such issues at the moment, due to various internal company
things going on.

I do suspect that this option is the way to go though and if
there are issues of duplicates being created by the regulator
core those probably need to be resolved in there. But that can
probably be done separate from this series.

Thanks,
Charles

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ