linux-kernel - Re: [PATCH 5/9] drivers: gpio: add QIXIS FPGA GPIO controller

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: <o5v2xdlrtjcgcd6usrfmtq6qffyigudvx3flhhetnd4ufg2mcx@5tem3jrlpxw5>
Date: Thu, 10 Jul 2025 13:01:58 +0300
From: Ioana Ciornei <ioana.ciornei@....com>
To: Andrew Lunn <andrew@...n.ch>
Cc: devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linux-gpio@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, 
	Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, 
	Conor Dooley <conor+dt@...nel.org>, Linus Walleij <linus.walleij@...aro.org>, 
	Bartosz Golaszewski <brgl@...ev.pl>, Shawn Guo <shawnguo@...nel.org>, 
	Michael Walle <mwalle@...nel.org>, Lee Jones <lee@...nel.org>, Frank Li <Frank.Li@....com>
Subject: Re: [PATCH 5/9] drivers: gpio: add QIXIS FPGA GPIO controller

On Wed, Jul 09, 2025 at 05:17:18PM +0200, Andrew Lunn wrote:
> > A GPIO controller has a maximum of 8 lines (all found in the same
> > register). Even within the same controller, the GPIO lines' direction is
> > fixed, either output or input, without the possibility to change it.
> 
> Since this is an FPGA, not silicon, is the selection of output or
> input a syntheses option?

I suppose so, yes. The idea is that in this particular case, the fixed
direction for each GPIO line (bit in the register) matches the use case
and will not be changed. For example, the presence detect or rx los
GPIOs for the SFP cages are only input, while the tx enable one is
output always.

>
> > +static const struct of_device_id qixis_cpld_gpio_of_match[] = {
> > +	{
> > +		.compatible = "fsl,lx2160ardb-fpga-gpio-sfp2",
> > +		.data = &lx2160ardb_sfp2_cfg,
> > +	},
> > +	{
> > +		.compatible = "fsl,lx2160ardb-fpga-gpio-sfp3",
> > +		.data = &lx2160ardb_sfp3_cfg,
> > +	},
> > +	{
> > +		.compatible = "fsl,ls1046aqds-fpga-gpio-stat-pres2",
> > +		.data = &ls1046aqds_stat_pres2_cfg,
> > +	},
> 
> Does the FPGA have an ID register you can read to confirm it is what
> you think it is?
> 
> Or is the bitstream downloaded at boot by another driver? Can you ask
> that driver what bitstream it downloaded?
> 
> Given how similar these devices are, it seems like a typ0 could give a
> mostly working device which passes testing, so doing some validation
> of the compatible against the actual FPGA would be nice.
> 

The FPGA does have an ID register that we could verify and match against
the board type that we expect.

On the other hand, I am not 100% on board with the idea to check this
from the GPIO driver which teoretically should only touch its one
register. Maybe from the parent's driver we could do that and prevent
the probing of children if things don't match up. But this does prove to
be complicated since those drivers are simple-mfd (for LS1046AQDS) and
simple-mfd-i2c (for LX2160ARDB). And I don't think it would be wise to
add some specific board logic into of/platform.c.

Ioana