linux-kernel - Re: [PATCH v10 4/8] drm/ingenic: Add dw-hdmi driver for jz4780

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: <YaeQW/akoLE6SpEi@sirena.org.uk>
Date:   Wed, 1 Dec 2021 15:10:19 +0000
From:   Mark Brown <broonie@...nel.org>
To:     "H. Nikolaus Schaller" <hns@...delico.com>
Cc:     Paul Cercueil <paul@...pouillou.net>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        Kees Cook <keescook@...omium.org>,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        Miquel Raynal <miquel.raynal@...tlin.com>,
        David Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel@...ll.ch>,
        Neil Armstrong <narmstrong@...libre.com>,
        Robert Foss <robert.foss@...aro.org>,
        Laurent Pinchart <Laurent.pinchart@...asonboard.com>,
        Jernej Skrabec <jernej.skrabec@...il.com>,
        Harry Wentland <harry.wentland@....com>,
        Sam Ravnborg <sam@...nborg.org>,
        Maxime Ripard <maxime@...no.tech>,
        Hans Verkuil <hverkuil-cisco@...all.nl>,
        Liam Girdwood <lgirdwood@...il.com>,
        Paul Boddie <paul@...die.org.uk>, devicetree@...r.kernel.org,
        linux-mips@...r.kernel.org, linux-kernel@...r.kernel.org,
        letux-kernel@...nphoenux.org, Jonas Karlman <jonas@...boo.se>,
        dri-devel@...ts.freedesktop.org,
        Ezequiel Garcia <ezequiel@...labora.com>
Subject: Re: [PATCH v10 4/8] drm/ingenic: Add dw-hdmi driver for jz4780

On Wed, Dec 01, 2021 at 03:33:24PM +0100, H. Nikolaus Schaller wrote:
> > Am 01.12.2021 um 15:03 schrieb Paul Cercueil <paul@...pouillou.net>:

> > Please make it mandatory in DTS then, and use devm_regulator_get() in the driver.

> Well, I just wonder why the elegant devm_regulator_get_optional() exists at all
> and seems to be used in ca. 80 places.

Frankly because half of them are broken usages like this since people
seem determined to have the most fragile error handling they can :/
There are valid use cases for it, with things like SD cards where some
supplies are genuinely optional and simply constrain what features are
available if they're omitted from the design.  You also see some devices
with the ability to replace internal regulators with external ones.

> And if it is not allowed, why some DTS should be forced to add not physically existing dummy-regulators.

Again, if the supply can be physically absent that is a sensible use
case but that means completely absent, not just not software
controllable.  We can represent fixed voltage regulators just fine.

> AFAIR drivers should implement functionality defined by DTS but not the other way round: enforce DTS style.
> BTW: there is no +5 mains dummy regulator defined in ci20.dts.

It wouldn't be the first time a DTS were incomplete, and I'm sure it
won't be the last.

> What I fear is that if we always have to define the mains +5V (which is for example not
> defined in ci20.dts), which rules stops us from asking to add a dummy-regulator from 110/230V to +5V as well.

It is good practice to specify the full tree of supplies all the way to
the main supply rail of the board, this ensures that if we need the
information for something we've got it (even if that thing is just that
we've got to the root of the tree).  There's potential applications in
battery supplied devices for managing very low power situations.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)