linux-kernel - RE: New subsystem for acceleration devices

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]

Date:   Mon, 1 Aug 2022 02:29:52 +0000
From:   <yuji2.ishikawa@...hiba.co.jp>
To:     <gregkh@...uxfoundation.org>, <oded.gabbay@...il.com>
CC:     <jiho.chu@...sung.com>, <arnd@...db.de>,
        <linux-kernel@...r.kernel.org>
Subject: RE: New subsystem for acceleration devices

> -----Original Message-----
> From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> Sent: Monday, August 1, 2022 12:38 AM
> To: Oded Gabbay <oded.gabbay@...il.com>
> Cc: ishikawa yuji(石川 悠司 ○ＲＤＣ□ＡＩＴＣ○ＥＡ開)
> <yuji2.ishikawa@...hiba.co.jp>; Jiho Chu <jiho.chu@...sung.com>; Arnd
> Bergmann <arnd@...db.de>; Linux-Kernel@...r. Kernel. Org
> <linux-kernel@...r.kernel.org>
> Subject: Re: New subsystem for acceleration devices
> 
> On Sun, Jul 31, 2022 at 02:45:34PM +0300, Oded Gabbay wrote:
> > Hi,
> > Greg and I talked a couple of months ago about preparing a new accel
> > subsystem for compute/acceleration devices that are not GPUs and I
> > think your drivers that you are now trying to upstream fit it as well.
> >
> > Would you be open/interested in migrating your drivers to this new
> subsystem ?
> >
> > Because there were no outstanding candidates, I have done so far only
> > a basic and partial implementation of the infrastructure for this
> > subsystem, but if you are willing to join I believe I can finish it
> > rather quickly.
> >
> > At start, the new subsystem will provide only a common device
> > character (e.g. /dev/acX) so everyone will do open/close/ioctl on the
> > same device character. Also sysfs/debugfs entries will be under that
> > device and maybe an IOCTL to retrieve information.
> >
> > In the future I plan to move some of habanalabs driver's code into the
> > subsystem itself, for common tasks such as memory management, dma
> > memory allocation, etc.
> >
> > Of course, you will be able to add your own IOCTLs as you see fit.
> > There will be a range of IOCTLs which are device-specific (similar to
> > drm).
> >
> > wdyt ?
> 
> That sounds reasonable to me as a sane plan forward, thanks for working on
> this.
> 
> greg k-h

Hi,
Thank you for your suggestion.
I'm really interested in the idea to have a dedicated subsystem for accelerators.
Let me challenge if the Visconti DNN driver can be re-written to the framework.
As Visconti SoC has several accelerators as well as DNN,
having a general/common interface will be a big benefit for us to maintain drivers for a long time.

I've heard that the framework has some basic implementation.
Do you have some sample code or enumeration of idea to describe the framework?
Would you share them with me? if that does not bother you.

If you need further information on the current DNN driver, please let me know.
Also, I can provide some for other accelerator drivers which are currently under cleaning up for contribution.

Regards,
	Yuji