linux-kernel - pca954x devices sharing reset-gpios

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

Message-ID: <ff1f75bb-75aa-e22e-9e68-721e8d80a755@alliedtelesis.co.nz>
Date:   Thu, 2 Dec 2021 20:18:42 +0000
From:   Chris Packham <Chris.Packham@...iedtelesis.co.nz>
To:     "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: pca954x devices sharing reset-gpios

Hi All,

I've run into a problem trying to accurately model some hardware.

In this particular design there are a bunch of pca9548 i2c muxes and 
some of them share the same reset pins coming out of a custom FPGA 
(we've written a gpio driver to represent that part of the FPGA). 
Initially we had this working by using a gpio-hog for the reset lines 
and pretty much forgetting they were there.

If I start building the fpga-gpio driver as a module I run into a 
situation where there is an implicit dependency between the fpga-gpio 
driver and the pca954x i2c muxes. Because it's implicit the 
pca954x_probe runs early and fails for these devices. I can make that 
dependency explicit by using the reset-gpios property which correctly 
defers the probe until the fpga-gpio driver is loaded. But as some of 
these pca9548 share reset lines they ones that get probed second get 
-EBUSY when they request the GPIO.

Is there any way I can represent these pca9548 devices as a group with a 
single reset-gpio property for the group?

Thanks,
Chris