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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <YO9c3Aofj0UJ1c3f@pendragon.ideasonboard.com>
Date:   Thu, 15 Jul 2021 00:53:32 +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,
        Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>,
        Cezary Rojewski <cezary.rojewski@...el.com>,
        Liam Girdwood <liam.r.girdwood@...ux.intel.com>,
        Jie Yang <yang.jie@...ux.intel.com>
Subject: Re: [RFC PATCH 0/2] Add software node support to regulator framework

On Wed, Jul 14, 2021 at 08:18:55PM +0100, Mark Brown wrote:
> On Wed, Jul 14, 2021 at 08:41:27PM +0300, Laurent Pinchart wrote:
> > 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:
> > > > 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).
> 
> Adding the Intel audio people - it'd be good if we could get some
> similar stuff started for the audio things.  Sadly in these sorts of
> cases AIUI the Windows thing is broadly to match DMI data and supply
> platform data so it's more a case of just not having essential
> information in firmware, a bad format would be better TBH (assuming it's
> accurate which also requires loads of quirks...).

On the camera side, the Windows-based machines I've worked with (Skylake
and Kabylak) have data in the DSDT. There's data we can use directly,
and there's a lot that is hardcoded in the Windows driver (including
what voltage to program on the different outputs of an I2C-controlled
regulator - you get that wrong, you fry your camera). I believe Intel
provides a small set of reference designs with several options to the
OEMs, and I wouldn't be surprised if some of the data present in ACPI
that we don't know how to interpret would identify these options. I
don't think the Windows driver has DMI-based quirks, the driver isn't
machine-specific as far as I can tell.

For newer devices, ACPI should contain Windows data in a format that the
Windows team decides on its own, and data that is actually usable in the
_DSD for Linux. I've also heard that the power management would be
saner, with PM actually implemented in the DSDT. I haven't seen those
DSDT yet though.

-- 
Regards,

Laurent Pinchart