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: <20250227114642.28752709@donnerap.manchester.arm.com>
Date: Thu, 27 Feb 2025 11:46:42 +0000
From: Andre Przywara <andre.przywara@....com>
To: Jernej Škrabec <jernej.skrabec@...il.com>
Cc: Linus Walleij <linus.walleij@...aro.org>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Chen-Yu Tsai <wens@...e.org>, Samuel Holland
 <samuel@...lland.org>, linux-gpio@...r.kernel.org,
 devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
 linux-sunxi@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 5/8] pinctrl: sunxi: allow reading mux values from DT

On Tue, 18 Feb 2025 18:09:09 +0100
Jernej Škrabec <jernej.skrabec@...il.com> wrote:

Hi,

> Dne petek, 14. februar 2025 ob 01:37:31 Srednjeevropski standardni čas je Andre Przywara napisal(a):
> > So far every Allwinner SoC needs a large table in the kernel code, to
> > describe the mapping between the pinctrl function names ("uart") and
> > the actual pincontroller mux value to be written into the registers.
> > This adds a lot of data into a single image kernel, and also looks
> > somewhat weird, as the DT can easily store the mux value.
> > 
> > Add some code that allows to avoid that table: the struct that describes
> > the existing pins will be build at *runtime*, based on very basic
> > information provided by the respective SoC's pinctrl driver. This
> > consists of the number of pins per bank, plus information which bank
> > provides IRQ support, along with the mux value to use for that.
> > The code will then iterate over all children of the pincontroller DT
> > node (which describe each pin group), and populate that struct with the
> > mapping between function names and mux values. The only thing that needs
> > adding in the DT is a property with that value, per pin group.
> > 
> > When this table is built, it will be handed over to the existing sunxi
> > pinctrl driver, which cannot tell a difference between a hardcoded
> > struct and this new one built at runtime. It will take care of
> > registering the pinctrl device with the pinctrl subsystem.
> > 
> > All a new SoC driver would need to do is to provide two arrays, and then
> > call the sunxi_pinctrl_dt_table_init() function.
> > 
> > Signed-off-by: Andre Przywara <andre.przywara@....com>  
> 
> I went through the code and it makes sense.

Many thanks, that's much appreciated!

> I wonder if we really need to
> build whole table instead of having on demand lookups into DT. However,
> for now, this will do. So:

I agree that would make some sense, but is also quite a departure from the
current driver, which we have been using for more than a decade now. And I
guess that would mean that we would need to maintain the two approaches,
for the old SoCs, and the new ones? With that patch here generic changes
can be applied just to the one core driver, dealing with the pinctrl
subsystem.

> Reviewed-by: Jernej Skrabec <jernej.skrabec@...il.com>

Thanks,
Andre

> Thanks!
> 
> Best regards,
> Jernej
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ