From: Chen-Yu Tsai <wenst@chromium.org>
To: Doug Anderson <dianders@chromium.org>
Cc: Rob Herring <robh+dt@kernel.org>,
Frank Rowand <frowand.list@gmail.com>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Conor Dooley <conor+dt@kernel.org>,
Matthias Brugger <matthias.bgg@gmail.com>,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com>,
Hsin-Yi Wang <hsinyi@chromium.org>,
Dmitry Torokhov <dmitry.torokhov@gmail.com>,
andriy.shevchenko@linux.intel.com,
Jiri Kosina <jikos@kernel.org>,
linus.walleij@linaro.org, broonie@kernel.org,
gregkh@linuxfoundation.org, hdegoede@redhat.com,
james.clark@arm.com, james@equiv.tech, keescook@chromium.org,
rafael@kernel.org, tglx@linutronix.de,
Jeff LaBundy <jeff@labundy.com>,
linux-input@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org,
linux-kernel@vger.kernel.org, Johan Hovold <johan@kernel.org>
Subject: Re: [RFC PATCH v2 0/7] of: Introduce hardware prober driver
Date: Tue, 14 Nov 2023 16:44:10 +0800 [thread overview]
Message-ID: <CAGXv+5GHFn_Xr0ta7b5M9WMBJzCE6NJWo_PR+XOYXO0oaoPeaQ@mail.gmail.com> (raw)
In-Reply-To: <CAD=FV=WZCyp1aaSmpF-_TQ0CTWG1ZuvPZVw4mR=wJH=NTkKqqg@mail.gmail.com>
On Sat, Nov 11, 2023 at 8:22 AM Doug Anderson <dianders@chromium.org> wrote:
>
> Hi,
>
> On Thu, Nov 9, 2023 at 2:06 AM Chen-Yu Tsai <wenst@chromium.org> wrote:
> >
> > The driver as
> > implemented currently doesn't deal with regulators or GPIO pins,
> > since in the existing device trees they are either always on for
> > regulators, or have GPIO hogs or pinmux and pinconfig directly
> > tied to the pin controller.
>
> I guess I won't object too much about this limitation for v1, but IMO
> it would be good to get this sorted out since I think part of the
> power of having the HW Prober is specifically that it can handle this
> type of use case. You have a little bit of board-specific code that
> knows how to turn on the regulators / GPIOs and can then probe the
> devices.
>
> Note: even if this is "board specific", it doesn't mean you couldn't
> share code between boards. For instance, you could have a helper
> function that would turn on regulators/GPIOs based on some type of
> table and that helper function could be used across a whole pile of
> Chromebooks. If a Chromebook is sufficiently different that it
> couldn't use the helper function then it could call its own function,
> but presumably it wouldn't be hard to support a bunch of boards
> without much code.
I agree this part is fairly generic and should be implemented.
We probably don't even need such a table. If these components share
a common connection to the mainboard, they certainly will have the
same GPIO lines and regulator supplies. The prober could just scan
the nodes looking for -gpio and -supply properties, de-duplicate
them, and turn them on.
The reason this isn't implemented in this version is because the devices
I'm currently using do not have these resources togglable. The supply is
always on, and the GPIO line is disconnected from the SoC. So I have no
way of testing it yet.
> As part of this, I think that your main "HW Prober" for Chromebooks
> should be in "drivers/platform/chrome/". I think that the only things
> that should be in the "drivers/of" directory should be helper
> functions used by the Chromebook HW Probers.
Sound like what Rob wants.
ChenYu
prev parent reply other threads:[~2023-11-14 8:44 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-09 10:05 [RFC PATCH v2 0/7] of: Introduce hardware prober driver Chen-Yu Tsai
2023-11-09 10:05 ` [RFC PATCH v2 1/7] of: base: Add of_device_is_fail Chen-Yu Tsai
2023-11-09 10:05 ` [RFC PATCH v2 2/7] of: Introduce hardware prober driver Chen-Yu Tsai
2023-11-09 15:13 ` Rob Herring
2023-11-14 8:30 ` Chen-Yu Tsai
2023-11-09 17:54 ` Andy Shevchenko
2023-11-14 8:26 ` Chen-Yu Tsai
2023-11-09 10:06 ` [RFC PATCH v2 3/7] arm64: dts: mediatek: mt8173-elm-hana: Mark touchscreens and trackpads as fail Chen-Yu Tsai
2023-11-09 10:06 ` [RFC PATCH v2 4/7] arm64: dts: mediatek: mt8173-elm-hana: Add G2touch G7500 touchscreen Chen-Yu Tsai
2023-11-09 10:06 ` [RFC PATCH v2 5/7] of: hw_prober: Support Chromebook SKU ID based component selection Chen-Yu Tsai
2023-11-10 21:07 ` Rob Herring
2023-11-09 10:06 ` [RFC PATCH v2 6/7] dt-bindings: arm: mediatek: Remove SKU specific compatibles for Google Krane Chen-Yu Tsai
2023-11-10 21:04 ` Rob Herring
2023-11-11 0:29 ` Doug Anderson
2023-11-09 10:06 ` [RFC PATCH v2 7/7] arm64: dts: mediatek: mt8183-kukui: Merge Krane device trees Chen-Yu Tsai
2023-11-09 10:54 ` [RFC PATCH v2 0/7] of: Introduce hardware prober driver AngeloGioacchino Del Regno
2023-11-09 13:51 ` Rob Herring
2023-11-11 0:12 ` Doug Anderson
2023-11-15 19:28 ` Rob Herring
2023-11-15 20:44 ` Doug Anderson
2023-11-15 21:34 ` Rob Herring
2023-11-15 22:13 ` Doug Anderson
2023-11-16 5:11 ` Chen-Yu Tsai
2023-11-19 14:34 ` Rob Herring
2023-11-16 5:07 ` Chen-Yu Tsai
2023-11-14 7:05 ` Chen-Yu Tsai
2023-11-14 8:57 ` Chen-Yu Tsai
2023-11-14 10:04 ` AngeloGioacchino Del Regno
2023-11-11 0:22 ` Doug Anderson
2023-11-14 8:44 ` Chen-Yu Tsai [this message]
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=CAGXv+5GHFn_Xr0ta7b5M9WMBJzCE6NJWo_PR+XOYXO0oaoPeaQ@mail.gmail.com \
--to=wenst@chromium.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=angelogioacchino.delregno@collabora.com \
--cc=broonie@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dianders@chromium.org \
--cc=dmitry.torokhov@gmail.com \
--cc=frowand.list@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=hdegoede@redhat.com \
--cc=hsinyi@chromium.org \
--cc=james.clark@arm.com \
--cc=james@equiv.tech \
--cc=jeff@labundy.com \
--cc=jikos@kernel.org \
--cc=johan@kernel.org \
--cc=keescook@chromium.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=matthias.bgg@gmail.com \
--cc=rafael@kernel.org \
--cc=robh+dt@kernel.org \
--cc=tglx@linutronix.de \
/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).