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: <3174DA41-EB38-4C30-8752-0D9C894C74A7@goldelico.com>
Date:   Wed, 1 Dec 2021 17:53:03 +0100
From:   "H. Nikolaus Schaller" <hns@...delico.com>
To:     Mark Brown <broonie@...nel.org>
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

Hi Mark,


> Am 01.12.2021 um 16:10 schrieb Mark Brown <broonie@...nel.org>:
> 
> 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 :/

I see. I had made the mistake myself to not check for NULL pointer on
regulator_disable here...

> 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.

The question may be how we can know for a more generic driver that there is always a regulator.
In the present case we know the schematics but it is just one example.

> 
>> 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.

Indeed. So let's modify it as you have suggested.

BR and thanks,
Nikolaus