netdev - Re: [RFC 00/10] add support for fwnode in i2c mux system and sfp

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: <YhfLG6wlFvYY3YU8@paasikivi.fi.intel.com>
Date:   Thu, 24 Feb 2022 20:14:51 +0200
From:   Sakari Ailus <sakari.ailus@...ux.intel.com>
To:     Mark Brown <broonie@...nel.org>
Cc:     Hans de Goede <hdegoede@...hat.com>,
        Clément Léger <clement.leger@...tlin.com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Daniel Scally <djrscally@...il.com>,
        Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Rafael J . Wysocki" <rafael@...nel.org>,
        Wolfram Sang <wsa@...nel.org>, Peter Rosin <peda@...ntia.se>,
        Russell King <linux@...linux.org.uk>,
        Andrew Lunn <andrew@...n.ch>,
        Heiner Kallweit <hkallweit1@...il.com>,
        "David S . Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>, linux-kernel@...r.kernel.org,
        linux-acpi@...r.kernel.org, linux-i2c@...r.kernel.org,
        netdev@...r.kernel.org,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>
Subject: Re: [RFC 00/10] add support for fwnode in i2c mux system and sfp

Hi Mark,

On Thu, Feb 24, 2022 at 03:33:12PM +0000, Mark Brown wrote:
> On Thu, Feb 24, 2022 at 03:58:04PM +0100, Hans de Goede wrote:
> 
> > As Mark already mentioned the regulator subsystem has shown to
> > be a bit problematic here, but you don't seem to need that?
> 
> I believe clocks are also potentially problematic for similar reasons
> (ACPI wants to handle those as part of the device level power management
> and/or should have native abstractions for them, and I think we also
> have board file provisions that work well for them and are less error
> prone than translating into an abstract data structure).

Per ACPI spec, what corresponds to clocks and regulators in DT is handled
through power resources. This is generally how things work in ACPI based
systems but there are cases out there where regulators and/or clocks are
exposed to software directly. This concerns e.g. camera sensors and lens
voice coils on some systems while rest of the devices in the system are
powered on and off the usual ACPI way.

So controlling regulators or clocks directly on an ACPI based system
wouldn't be exactly something new. All you need to do in that case is to
ensure that there's exactly one way regulators and clocks are controlled
for a given device. For software nodes this is a non-issue.

This does have the limitation that a clock or a regulator is either
controlled through power resources or relevant drivers, but that tends to
be the case in practice. But I presume it wouldn't be different with board
files.

-- 
Sakari Ailus