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: <ZSzb9OEo6cIbln3A@matsya>
Date:   Mon, 16 Oct 2023 12:15:08 +0530
From:   Vinod Koul <vkoul@...nel.org>
To:     "Mehta, Sanju" <Sanju.Mehta@....com>
Cc:     "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "dan.j.williams@...el.com" <dan.j.williams@...el.com>,
        "robh@...nel.org" <robh@...nel.org>,
        "mchehab+samsung@...nel.org" <mchehab+samsung@...nel.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "dmaengine@...r.kernel.org" <dmaengine@...r.kernel.org>
Subject: Re: [PATCH 1/3] dmaengine: ae4dma: Initial ae4dma controller driver
 with multi channel

On 14-10-23, 08:26, Mehta, Sanju wrote:
> [AMD Official Use Only - General]

??

> > > diff --git a/drivers/dma/ae4dma/ae4dma-pci.c
> > > b/drivers/dma/ae4dma/ae4dma-pci.c new file mode 100644 index
> > > 0000000..a77fbb5
> > > --- /dev/null
> > > +++ b/drivers/dma/ae4dma/ae4dma-pci.c
> > > @@ -0,0 +1,247 @@
> > > +// SPDX-License-Identifier: GPL-2.0-only
> > > +/*
> > > + * AMD AE4DMA device driver
> > > + * -- Based on the PTDMA driver
> >
> > cant we use ptdma driver to support both cores?
> >
> AE4DMA has multiple channels per engine, whereas PTDMA is limited to a single channel per engine. Furthermore, there are significant disparities in both the DMA engines and their respective handling methods. Hence wanted to keep separate codes for PTDMA and AE4DMA.

Pls wrap your replies to 80chars!

The channel count should be configurable and for the handling methods,
you can have low level handler functions for each controller which can
be selected based on device probe

I feel reuse of code is better idea than having two different drivers
-- 
~Vinod

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ