linux-kernel - Re: [PATCH v1 1/1] dmaengine: dw: Program xBAR hardware for Elkhart Lake

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, 7 Jun 2021 15:30:12 +0300
From:   Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To:     Vinod Koul <vkoul@...nel.org>
Cc:     Serge Semin <Sergey.Semin@...kalelectronics.ru>,
        dmaengine@...r.kernel.org, linux-kernel@...r.kernel.org,
        Viresh Kumar <vireshk@...nel.org>
Subject: Re: [PATCH v1 1/1] dmaengine: dw: Program xBAR hardware for Elkhart
 Lake

On Mon, Jun 07, 2021 at 05:04:57PM +0530, Vinod Koul wrote:
> On 02-06-21, 11:56, Andy Shevchenko wrote:
> > Intel Elkhart Lake PSE DMA implementation is integrated with crossbar IP
> > in order to serve more hardware than there are DMA request lines available.
> > 
> > Due to this, program xBAR hardware to make flexible support of PSE peripheral.

...

> > -// Copyright (C) 2013,2018 Intel Corporation
> > +// Copyright (C) 2013,2018,2020 Intel Corporation
> 
> 2021..?

Actually 2020.
But I can add 2021.

...

> > +static unsigned int idma32_get_slave_devid(struct dw_dma_chan *dwc)
> > +{
> > +	struct device *slave = dwc->chan.slave;
> > +
> > +	if (!slave || !dev_is_pci(slave))
> > +		return 0;
> > +
> > +	return to_pci_dev(slave)->devfn;
> 
> so this return devfn.. maybe rename function to get_slave_devfn() ?

Will do in v2.

> > +}

...

> > +	switch (dwc->direction) {
> > +	case DMA_MEM_TO_MEM:
> > +		value |= CTL_CH_TRANSFER_MODE_D2D;
> > +		break;
> > +	case DMA_MEM_TO_DEV:
> > +		value |= CTL_CH_TRANSFER_MODE_D2S;
> > +		value |= CTL_CH_WR_NON_SNOOP_BIT;
> > +		break;
> > +	case DMA_DEV_TO_MEM:
> > +		value |= CTL_CH_TRANSFER_MODE_S2D;
> > +		value |= CTL_CH_RD_NON_SNOOP_BIT;
> > +		break;
> > +	case DMA_DEV_TO_DEV:
> > +	default:
> > +		value |= CTL_CH_WR_NON_SNOOP_BIT | CTL_CH_RD_NON_SNOOP_BIT;
> > +		value |= CTL_CH_TRANSFER_MODE_S2S;
> > +		break;
> 
> aha, how did you test this...

Not sure what the question is about. You are talking about last two cases
or the entire switch? Last two weren't tested, just filed for the sake of
being documented. First two were tested with SPI host controllers.

-- 
With Best Regards,
Andy Shevchenko