linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Daniel Scally <djrscally@gmail.com>
Cc: linux-kernel@vger.kernel.org,
	platform-driver-x86@vger.kernel.org, hdegoede@redhat.com,
	mgross@linux.intel.com, luzmaximilian@gmail.com,
	lgirdwood@gmail.com, andy.shevchenko@gmail.com,
	laurent.pinchart@ideasonboard.com,
	kieran.bingham@ideasonboard.com
Subject: Re: [RFC PATCH 2/2] platform/surface: Add Surface Go 2 board file
Date: Fri, 9 Jul 2021 18:40:00 +0100	[thread overview]
Message-ID: <20210709174000.GF4112@sirena.org.uk> (raw)
In-Reply-To: <20210708224226.457224-3-djrscally@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2106 bytes --]

On Thu, Jul 08, 2021 at 11:42:26PM +0100, Daniel Scally wrote:

> The DSDT tables on the Surface Go 2 contain no power control methods for
> the world facing camera, so the regulator, gpio and clk frameworks have no
> way to discover the appropriate connections and settings.

Does anything actually need these connections or settings?

> +static const struct property_entry core_properties[] = {
> +	PROPERTY_ENTRY_STRING("regulator-name", "CORE"),
> +	PROPERTY_ENTRY_U32("regulator-min-microvolt", 1200000),
> +	PROPERTY_ENTRY_U32("regulator-max-microvolt", 1200000),
> +	{ }
> +};

Does anything actually care about the voltages here - why specify them?
As far as I can tell from grepping all the supplies you're adding are
digital.

> +static const struct software_node regulator_nodes[] = {
> +	{"ANA", &tps68470_node, ana_properties},
> +	{"VSIO", &tps68470_node, vsio_properties},
> +	{"CORE", &tps68470_node, core_properties},
> +};

> +static const struct property_entry sensor_properties[] = {
> +	PROPERTY_ENTRY_REF("avdd-supply", &regulator_nodes[0]),
> +	PROPERTY_ENTRY_REF("dovdd-supply", &regulator_nodes[1]),
> +	PROPERTY_ENTRY_REF("dvdd-supply", &regulator_nodes[2]),
> +	{ }

I would strongly caution against this idiom of referencing elements in
other arrays using magic numbers, it is both hard to read and error
prone when someone goes in making changes.  If they need to be in arrays
then constants for the array indexes would help a lot.

> +static struct software_node sensor_node = {
> +	.name		= "INT347A",
> +	.properties	= sensor_properties,
> +};
> +
> +static struct gpiod_lookup_table surface_go_2_gpios = {
> +	.dev_id = "i2c-INT347A:00",
> +	.table = {
> +		GPIO_LOOKUP("tps68470-gpio", 9, "reset", GPIO_ACTIVE_LOW),
> +		GPIO_LOOKUP("tps68470-gpio", 7, "powerdown", GPIO_ACTIVE_LOW)
> +	}
> +};

This appears to be using regular board file stuff for GPIOs, if this
swnode stuff is somehow needed for regulators why is it not also needed
for GPIOs?  I think this is going back to the thing I was saying earlier
about not really understanding the problem being solved here.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2021-07-09 17:40 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-08 22:42 [RFC PATCH 0/2] Add software node support to regulator framework Daniel Scally
2021-07-08 22:42 ` [RFC PATCH 1/2] regulator: Add support for software node connections Daniel Scally
2021-07-09 17:26   ` Mark Brown
2021-07-08 22:42 ` [RFC PATCH 2/2] platform/surface: Add Surface Go 2 board file Daniel Scally
2021-07-09 17:40   ` Mark Brown [this message]
2021-07-09 17:04 ` [RFC PATCH 0/2] Add software node support to regulator framework Mark Brown
2021-07-10 22:48   ` Daniel Scally
2021-07-12 14:15     ` Mark Brown
2021-07-12 16:55       ` Laurent Pinchart
2021-07-12 17:32         ` Mark Brown
2021-07-11  9:37   ` Andy Shevchenko
2021-07-12 12:42     ` Mark Brown
2021-07-12 13:01       ` Andy Shevchenko
2021-07-12 13:34         ` Mark Brown
2021-07-12 16:08           ` Andy Shevchenko
2021-07-12 17:01             ` Mark Brown
2021-07-12 23:32               ` Daniel Scally
2021-07-13 15:24                 ` Mark Brown
2021-07-13 15:42                   ` Laurent Pinchart
2021-07-13 16:02                     ` Mark Brown
2021-07-13 16:06                       ` Laurent Pinchart
2021-07-13 18:24                         ` Mark Brown
2021-07-13 15:55                   ` Andy Shevchenko
2021-07-13 18:18                     ` Mark Brown
2021-07-13 19:46                       ` Andy Shevchenko
2021-07-14 16:05                         ` Mark Brown
2021-07-14  7:25                       ` Laurent Pinchart
2021-07-14 16:59                         ` Mark Brown
2021-07-14 17:18                           ` Laurent Pinchart
2021-07-14 17:28                             ` Mark Brown
2021-07-14 17:41                               ` Laurent Pinchart
2021-07-14 19:18                                 ` Mark Brown
2021-07-14 21:53                                   ` Laurent Pinchart
2021-07-13 22:06                   ` Daniel Scally
2021-07-10 22:28 ` Laurent Pinchart
2021-07-10 22:54   ` Daniel Scally
2021-07-11 16:55     ` Laurent Pinchart
2021-07-12  8:13       ` Daniel Scally
2021-07-12 11:50         ` Laurent Pinchart
2021-07-12 13:23         ` Mark Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210709174000.GF4112@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=andy.shevchenko@gmail.com \
    --cc=djrscally@gmail.com \
    --cc=hdegoede@redhat.com \
    --cc=kieran.bingham@ideasonboard.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luzmaximilian@gmail.com \
    --cc=mgross@linux.intel.com \
    --cc=platform-driver-x86@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).