On Wed, 6 Mar 2019, at 08:15, Eddie James wrote: > > On 3/5/19 2:01 AM, Arnd Bergmann wrote: > > On Mon, Mar 4, 2019 at 10:37 PM Eddie James <eajames@xxxxxxxxxxxxx> wrote: > >> The XDMA engine embedded in the AST2500 SOC performs PCI DMA operations > >> between the SOC (acting as a BMC) and a host processor in a server. > >> > >> This commit adds a driver to control the XDMA engine and adds functions > >> to initialize the hardware and memory and start DMA operations. > >> > >> Signed-off-by: Eddie James <eajames@xxxxxxxxxxxxx> > > Hi Eddie, > > > > Thanks for your submission! Overall this looks well-implemented, but > > I fear we already have too many ways of doing the same thing at > > the moment, and I would hope to avoid adding yet another user space > > interface for a specific hardware that does this. > > > > Your interface appears to be a fairly low-level variant, just doing > > single DMA transfers through ioctls, but configuring the PCIe > > endpoint over sysfs. > > Hi, thanks for the quick response! > > There is actually no PCIe configuration done in this driver. The two > sysfs entries control the system control unit (SCU) on the AST2500 > purely to enable and disable entire PCIe devices. It might be possible > to control those devices more finely with a PCI endpoint driver, but > there is no need to do so. The XDMA engine does that by itself to > perform DMA fairly automatically. I had a series a while back to expose random bits from devices in sysfs. It got shot down pretty well, but the main contention was over the devicetree bindings. I think we could revive it as a library-type thing that drivers can use to expose bits like what you're describing without putting the grubby details in the devicetree. The we would have a consistent approach to exposing otherwise hard to describe functions (which is what a lot of a BMC turns out to be). Andrew
