linux-kernel - Re: [RFC PATCH 0/2] Add software node support to regulator framework

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: <YO8hxyrHqY7K43wp@pendragon.ideasonboard.com>
Date:   Wed, 14 Jul 2021 20:41:27 +0300
From:   Laurent Pinchart <laurent.pinchart@...asonboard.com>
To:     Mark Brown <broonie@...nel.org>
Cc:     Andy Shevchenko <andy.shevchenko@...il.com>,
        Daniel Scally <djrscally@...il.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Platform Driver <platform-driver-x86@...r.kernel.org>,
        Hans de Goede <hdegoede@...hat.com>,
        Mark Gross <mgross@...ux.intel.com>,
        Maximilian Luz <luzmaximilian@...il.com>,
        Liam Girdwood <lgirdwood@...il.com>,
        kieran.bingham@...asonboard.com
Subject: Re: [RFC PATCH 0/2] Add software node support to regulator framework

On Wed, Jul 14, 2021 at 06:28:46PM +0100, Mark Brown wrote:
> On Wed, Jul 14, 2021 at 08:18:13PM +0300, Laurent Pinchart wrote:
> > On Wed, Jul 14, 2021 at 05:59:48PM +0100, Mark Brown wrote:
> 
> > > really look like each other and AIUI this stuff isn't getting adopted
> > > for actual firmware (as opposed to swnodes) outside of the embedded x86
> > > space.
> 
> > It's only one data point, but we're seeing adoption of the ACPI
> > DT-in-DSD for camera. It's still not pretty of course.
> 
> By non-Linux system vendors?

For Windows-based machines, yes. It's fairly new, and the information I
have is that those machines may ship DSDT containing both Windows-style
(read: crap) data and Linux-style data for the same nodes. My fear is
that only the former will be properly tested and the latter will thus be
incorrect. The future will tell (I'm as usual very hopeful).

> My understanding has been that for audio people are just unwilling to
> provide the level of firmware description required to avoid quirks,
> there was some limited stuff with the NHLT table but it still required
> system software to quirk things.  If there's progress elsewhere
> perhaps the relevant people can be persuaded to have another go...
> 
> > Once travel will be easier again, we'll plot a take over of the world in
> > a bar. Dealing with ACPI requires lots of whisky :-)
> 
> Indeed!

-- 
Regards,

Laurent Pinchart