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:   Wed, 7 Jun 2023 09:58:32 +0200
From:   Köry Maincent <kory.maincent@...tlin.com>
To:     Cai Huoqing <cai.huoqing@...ux.dev>
Cc:     vkoul@...nel.org, Serge Semin <fancer.lancer@...il.com>,
        Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>,
        Manivannan Sadhasivam <mani@...nel.org>,
        Gustavo Pimentel <gustavo.pimentel@...opsys.com>,
        Jingoo Han <jingoohan1@...il.com>,
        Lorenzo Pieralisi <lpieralisi@...nel.org>,
        Krzysztof Wilczyński <kw@...ux.com>,
        Rob Herring <robh@...nel.org>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        linux-kernel@...r.kernel.org, dmaengine@...r.kernel.org,
        linux-pci@...r.kernel.org,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>
Subject: Re: [PATCH v11 3/4] dmaengine: dw-edma: Add support for native HDMA

On Sat, 20 May 2023 13:08:51 +0800
Cai Huoqing <cai.huoqing@...ux.dev> wrote:

> Add support for HDMA NATIVE, as long the IP design has set
> the compatible register map parameter-HDMA_NATIVE,
> which allows compatibility for native HDMA register configuration.

I know the patch has been merged in dmaengine tree but something seems weird on
my side.

The akida_dw_edma_probe function is selecting the minimum read and write
channels by doing the minimum between ll_wr_cnt and the ch_count callback.
The hdma ch_count callback is counting the number of channels enabled by reading
the number of ch_en registers set. At probe time there is no channels registers
that has been set as it is done later in the dw_hdma_v0_core_start function.
Then the dw_hdma_v0_core_ch_count will always return 0 at probe time and the
number of channels will be set to 0 which is not what we want.
Could I miss something?

See the functions bellow:

> int akida_dw_edma_probe(struct dw_edma_chip *chip)                         
> {                                                                          
 ...                               
>         dw->wr_ch_cnt = min_t(u16, chip->ll_wr_cnt,                        
>                               dw_edma_core_ch_count(dw, EDMA_DIR_WRITE));  
>         dw->wr_ch_cnt = min_t(u16, dw->wr_ch_cnt, EDMA_MAX_WR_CH);         
>                                                                            
>         dw->rd_ch_cnt = min_t(u16, chip->ll_rd_cnt,                        
>                               dw_edma_core_ch_count(dw, EDMA_DIR_READ));   
>         dw->rd_ch_cnt = min_t(u16, dw->rd_ch_cnt, EDMA_MAX_RD_CH);         
>                                                                            
>         if (!dw->wr_ch_cnt && !dw->rd_ch_cnt)                              
>                 return -EINVAL;            
...
}


> +static u16 dw_hdma_v0_core_ch_count(struct dw_edma *dw, enum dw_edma_dir dir)
> +{
> +	u32 num_ch = 0;
> +	int id;
> +
> +	for (id = 0; id < HDMA_V0_MAX_NR_CH; id++) {
> +		if (GET_CH_32(dw, id, dir, ch_en) & BIT(0))
> +			num_ch++;
> +	}
> +
> +	if (num_ch > HDMA_V0_MAX_NR_CH)
> +		num_ch = HDMA_V0_MAX_NR_CH;
> +
> +	return (u16)num_ch;
> +}



> +static void dw_hdma_v0_core_start(struct dw_edma_chunk *chunk, bool first)
> +{
> +	struct dw_edma_chan *chan = chunk->chan;
> +	struct dw_edma *dw = chan->dw;
> +	u32 tmp;
> +
> +	dw_hdma_v0_core_write_chunk(chunk);
> +
> +	if (first) {
> +		/* Enable engine */
> +		SET_CH_32(dw, chan->dir, chan->id, ch_en, BIT(0));
...
> +}

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ