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: <e1182432-19d8-6c9d-fd41-bb4d739b579a@gmail.com>
Date:   Sat, 2 Nov 2019 12:34:45 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Stefan Wahren <wahrenst@....net>,
        Matthias Brugger <matthias.bgg@...nel.org>,
        Matthias Brugger <mbrugger@...e.com>,
        "David S . Miller" <davem@...emloft.net>,
        Florian Fainelli <f.fainelli@...il.com>
Cc:     Eric Anholt <eric@...olt.net>,
        Nicolas Saenz Julienne <nsaenzjulienne@...e.de>,
        Doug Berger <opendmb@...il.com>, netdev@...r.kernel.org,
        bcm-kernel-feedback-list@...adcom.com,
        linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH RFC V2 3/6] net: bcmgenet: use optional max DMA burst size
 property

On 11/2/2019 6:41 AM, Stefan Wahren wrote:
> From: Matthias Brugger <mbrugger@...e.com>
> 
> Depending on the HW, the maximal usable DMA burst size can vary.
> If not set accordingly a timeout in the transmit queue happens and no
> package can be sent. Read to optional max-burst-sz property, if not
> present, fallback to the standard value.
> 
> Signed-off-by: Matthias Brugger <mbrugger@...e.com>

Missing your Signed-off-by here since you are carrying this patch from
Matthias.

> ---

[snip]

> +	if (dn) {
> +		of_property_read_u32(dn, "dma-burst-sz",
> +				     &priv->dma_max_burst_length);
> +	} else {
> +		priv->dma_max_burst_length = DMA_MAX_BURST_LENGTH;
> +	}

I would maintain the previous position provided on Matthias' patch
series, which is the integration of the GENETv5 hardware block in 2711
is done in a way that is different enough (due to the SCB/AXI bridge)
that a separate compatibility string would be in order. Once you that
defined that "brcm,bcm2711-genet-v5" compatibility string defined, you
can derive the DMA burst size off of it.

If adding a compatibility string is not practical because of the
downstream DTBs, then can we at least fix this patch in two ways:

- define the property in the binding document
- spell out the property in full names: max-dma-burst-size so as to
reflect what it does

Thanks!
-- 
Florian


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ