linux-kernel - Re: [PATCH 0/5] fsi: Add regmap and refactor sbefifo

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]

Message-ID: <36908c1d-4672-807a-d157-d3ccd0b03148@linux.ibm.com>
Date:   Tue, 18 Oct 2022 09:02:33 -0500
From:   Eddie James <eajames@...ux.ibm.com>
To:     Mark Brown <broonie@...nel.org>
Cc:     joel@....id.au, jk@...abs.org, alistair@...ple.id.au,
        linux-kernel@...r.kernel.org, linux-fsi@...ts.ozlabs.org
Subject: Re: [PATCH 0/5] fsi: Add regmap and refactor sbefifo


On 10/17/22 12:37, Mark Brown wrote:
> On Fri, Oct 14, 2022 at 05:05:35PM -0500, Eddie James wrote:
>> The SBEFIFO hardware can now be attached over a new I2C endpoint
>> interface called the I2C Responder (I2CR). In order to use the
>> existing SBEFIFO driver, add regmap drivers for both FSI busses
>> and the I2CR. Then, refactor the SBEFIFO and OCC drivers to clean
>> up and use the new regmap drivers.
> Is there any great reason to provide support in the regmap core for this
> rather than just implementing in drivers/fsi?  AFAICT this is just
> ending up as an implementation detail of shared code in drivers/fsi and
> won't have any external users?


One reason is to have a common interface with the new FSI regmap. That 
way abstracting out the bus transfer is trivial in the new SBEFIFO 
driver, assuming the SBEFIFO driver should switch to use the FSI regmap.

But you are correct, I doubt anyone else will use this. I suppose 
SBEFIFO may as well not use the regmap and just use some callbacks for 
whichever bus transfer...


Thanks,

Eddie