linux-kernel - Re: [PATCH] net: macb: Clean 64b dma addresses if they are not detected

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: <20eb98a9-edbd-c613-1f76-eccd7e06e052@microchip.com>
Date:   Fri, 21 Sep 2018 14:38:02 +0200
From:   Nicolas Ferre <nicolas.ferre@...rochip.com>
To:     Michal Simek <michal.simek@...inx.com>,
        "Edgar E. Iglesias" <edgar.iglesias@...inx.com>
CC:     <linux-kernel@...r.kernel.org>, <monstr@...str.eu>,
        "Edgar E. Iglesias" <edgari@...inx.com>,
        "David S. Miller" <davem@...emloft.net>, <netdev@...r.kernel.org>,
        <u-boot@...ts.denx.de>, Joe Hershberger <joe.hershberger@...com>
Subject: Re: [PATCH] net: macb: Clean 64b dma addresses if they are not
 detected

Michal,

On 20/09/2018 at 08:23, Michal Simek wrote:
> On 19.9.2018 20:08, Edgar E. Iglesias wrote:
>> On Wed, Sep 19, 2018 at 06:08:18PM +0200, Michal Simek wrote:
>>> Clear ADDR64 dma bit in DMACFG register in case that HW_DMA_CAP_64B
>>> is not detected on 64bit system.
>>> The issue was observed when bootloader(u-boot) does not check macb
>>> feature at DCFG6 register (DAW64_OFFSET) and enabling 64bit dma support
>>> by default. Then macb driver is reading DMACFG register back and only
>>> adding 64bit dma configuration but not cleaning it out.
>>>
>>> This is also align with other features which are also cleared if they are not
>>> present.
>>
>> Hi Michal,
>>
>>>
>>> Signed-off-by: Michal Simek <michal.simek@...inx.com>
>>> ---
>>>
>>>   drivers/net/ethernet/cadence/macb_main.c | 2 ++
>>>   1 file changed, 2 insertions(+)
>>>
>>> diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
>>> index 16e4ef7d7185..79707dff3f13 100644
>>> --- a/drivers/net/ethernet/cadence/macb_main.c
>>> +++ b/drivers/net/ethernet/cadence/macb_main.c
>>> @@ -2163,6 +2163,8 @@ static void macb_configure_dma(struct macb *bp)
>>>   #ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
>>>   		if (bp->hw_dma_cap & HW_DMA_CAP_64B)
>>>   			dmacfg |= GEM_BIT(ADDR64);
>>> +		else
>>> +			dmacfg &= ~GEM_BIT(ADDR64);
>>>   #endif
>>
>> I think you might want to do this clearing outside of the #ifdef.
>> If CONFIG_ARCH_DMA_ADDR_T_64BIT is not defined, we'd want to make
>> sure the ADDR64 is cleared. E.g something like:
>>
>>               dmacfg &= ~GEM_BIT(ADDR64);
>> #ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
>>               if (bp->hw_dma_cap & HW_DMA_CAP_64B)
>>                       dmacfg |= GEM_BIT(ADDR64);
>> #endif
>>
>>
>> Same thing for the USE_HWSTAMP/PTP flags below.
> 
> Origin patch, which introduce this read with mask,
> macfg = gem_readl(bp, DMACFG) & ~GEM_BF(RXBS, -1L);
> was done in 2011 and from that time this function was extended a little
> bit. I am even not quite sure if make sense to read this reg and apply
> setting on the top of it.
> 
> Nicolas: Isn't it better simply compose that reg from scratch?

I have several arguments against composing this register from scratch:

1/ the reset value of this register is non-null for both of our 
platforms and it could be meaningful to keep some of these values.

2/ one bitfield could use different values between Zynq and AT91: RXBMS 
(1kB to 8kB for Zynq and 512 to 4KB for AT91), with same encoding.

3/ and well, this is the type of register with multiple bits that are 
marked as "reserved" and that experience tells that they might be 
connected to something...

So, I'm all for correcting the code like what Edgar suggests.

Best regards,
-- 
Nicolas Ferre