linux-kernel - Re: [PATCH v1 1/8] dt-bindings: pinctrl: Add thead,th1520-pinctrl bindings

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] [day] [month] [year] [list]

Date: Sat, 23 Dec 2023 01:18:19 +0100
From: Linus Walleij <linus.walleij@...aro.org>
To: Emil Renner Berthing <emil.renner.berthing@...onical.com>
Cc: Rob Herring <robh@...nel.org>, linux-gpio@...r.kernel.org, devicetree@...r.kernel.org, 
	linux-kernel@...r.kernel.org, linux-riscv@...ts.infradead.org, 
	Hoan Tran <hoan@...amperecomputing.com>, Serge Semin <fancer.lancer@...il.com>, 
	Bartosz Golaszewski <brgl@...ev.pl>, Andy Shevchenko <andy@...nel.org>, 
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>, Conor Dooley <conor+dt@...nel.org>, 
	Jisheng Zhang <jszhang@...nel.org>, Guo Ren <guoren@...nel.org>, Fu Wei <wefu@...hat.com>, 
	Paul Walmsley <paul.walmsley@...ive.com>, Palmer Dabbelt <palmer@...belt.com>
Subject: Re: [PATCH v1 1/8] dt-bindings: pinctrl: Add thead,th1520-pinctrl bindings

On Thu, Dec 21, 2023 at 3:07 PM Emil Renner Berthing
<emil.renner.berthing@...onical.com> wrote:
> Linus Walleij wrote:

> > Do the people designing boards using this have better documentation than what
> > you have? Then either get that documentation or just don't give them
> > too much rope.
>
> We can certainly prevent Linux from ever combining the strong pull-up with the
> regular bias, but that doesn't mean that the vendor u-boot can't find a use for
> it and might hand over pins in such states Linux then wouldn't know how to
> handle.

What you are saying is "there might be people who have access to
documentation that I don't have so they do this crazy thing".

Clearly you cannot design for that.

Print a big fat warning and fail probe if it happens.

If U-Boot is using some feature you definitely cannot deal with if this
happens, and then the people doing this can very well write a patch for
the kernel.

> If you think its better we could just postpone that problem to when/if it ever
> happens.

Yes please.

Yours,
Linus Walleij