Re: [PATCH v1 3/3] misc: ls6000se-sdf: Add driver for Loongson 6000SE SDF

[Greg Kroah-Hartman]

On Wed, Jan 15, 2025 at 10:58:52AM +0800, Qunqin Zhao wrote:
> 
> 在 2025/1/14 下午9:21, Greg Kroah-Hartman 写道:
> > On Tue, Jan 14, 2025 at 06:43:24PM +0800, Xi Ruoyao wrote:
> > > On Tue, 2025-01-14 at 11:17 +0100, Arnd Bergmann wrote:
> > > > On Tue, Jan 14, 2025, at 10:55, Qunqin Zhao wrote:
> > > > > Loongson Secure Device Function device supports the functions specified
> > > > > in "GB/T 36322-2018". This driver is only responsible for sending user
> > > > > data to SDF devices or returning SDF device data to users.
> > > > I haven't been able to find a public version of the standard
> > > A public copy is available at
> > > https://openstd.samr.gov.cn/bzgk/gb/newGbInfo?hcno=69E793FE1769D120C82F78447802E14F,
> > > pressing the blue "online preview" button, enter a captcha and you can
> > > see it.  But the copy is in Chinese, and there's an explicit notice
> > > saying translating this copy is forbidden, so I cannot translate it for
> > > you either.
> > > 
> > > > but
> > > > from the table of contents it sounds like this is a standard for
> > > > cryptographic functions that would otherwise be implemented by a
> > > > driver in drivers/crypto/ so it can use the normal abstractions
> > > > for both userspace and in-kernel users.
> > > > 
> > > > Is there some reason this doesn't work?
> > > I'm not an lawyer but I guess contributing code for that may have some
> > > "cryptography code export rule compliance" issue.
> > Issue with what?  And why?  It's enabling the functionality of the
> > hardware either way, so the same rules should apply no matter where the
> > driver ends up in or what apis it is written against, right?
> 
> SDF and tpm2.0 are both  "library specifications",  which means that
> 
> it supports a wide variety of functions not only cryptographic functions,
> 
> but unlike tpm2.0, SDF is only used in China.
> 
> You can refer to the tpm2.0 specification:
> https://trustedcomputinggroup.org/resource/tpm-library-specification/

So this is an accelerator device somehow?  If it provides crypto
functions, it must follow the crypto api, you can't just provide a "raw"
char device node for it as that's not going to be portable at all.
Please fit it into the proper kernel subsystem for the proper
user/kernel api needed to drive this hardware.

thanks,

greg k-h