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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 1 Dec 2021 15:33:24 +0100
From:   "H. Nikolaus Schaller" <hns@...delico.com>
To:     Paul Cercueil <paul@...pouillou.net>
Cc:     Mark Brown <broonie@...nel.org>, 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 Paul,

> Am 01.12.2021 um 15:03 schrieb Paul Cercueil <paul@...pouillou.net>:
> 
> Hi Nikolaus, Mark,
> 
> Le mer., déc. 1 2021 at 14:51:51 +0100, H. Nikolaus Schaller <hns@...delico.com> a écrit :
>> Hi,
>>> Am 01.12.2021 um 14:39 schrieb Mark Brown <broonie@...nel.org>:
>>> On Wed, Dec 01, 2021 at 01:02:45PM +0000, Paul Cercueil wrote:
>>>> Le mar., nov. 30 2021 at 22:26:37 +0100, H. Nikolaus Schaller
>>>>> +	regulator = devm_regulator_get_optional(&pdev->dev, "hdmi-5v");
>>>>> +	if (IS_ERR(regulator)) {
>>>>> +		ret = PTR_ERR(regulator);
>>> Why is this using _optional()?  This should only be done when the supply
>>> can be physically absent
>> There can be +5V for HDMI but without a regulator that is visible to or controllable
>> by the driver.
> 
> There is always a power supply though. Either a controllable one (through e.g. a GPIO), or it's just connected to the mains +5V; the pin is never left floating. In the second case, in DTS the "hdmi-5v" would be connected to some 5v regulator, even if it's just a dummy VCC-5V regulator. So Mark has a point.
> 
>> So hdmi-5v can be simply missing in DTS in which case the driver does not need to
>> care about. The driver just can't turn it on or off.
> 
> 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.

And if it is not allowed, why some DTS should be forced to add not physically existing dummy-regulators.
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.

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.
In last consequence, it seems as if we have to describe all dummy regulators from the power plant to our hdmi-5v :)

Since I always follow the KISS principle I tend to leave out what is not relevant...

Of course adding a dummy regulator to the DTS allows to avoid the NULL pointer test
in the driver code.

Anyways, you are maintainers :)

So should I spin a v11 for the series or just this patch or how should we do it?

BR and thanks,
Nikolaus

> 
> Cheers,
> -Paul
> 
>>> (in which case I'd expect to see special
>>> handling).
>> The special case is to not enable/disable the regulator if it does not exist
>> and assume that there is hardware providing it otherwise (the driver can't know
>> that except by using get_optional). This is done by the code below
>>>>> +	if (IS_ERR(regulator)) {
>> ...
>>> +	if (!regulator)
>>> +		return 0;
>>> +	ret = regulator_enable(regulator);
>> ...
>> BR and thanks,
>> Nikolaus
> 
>