Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Received-SPF: Pass (protection.outlook.com: domain of xilinx.com designates
 149.199.60.83 as permitted sender) receiver=protection.outlook.com;
 client-ip=149.199.60.83; helo=xsj-pvapsmtpgw01;
Subject: Re: [PATCH] net: macb: Clean 64b dma addresses if they are not
 detected
To:     Nicolas Ferre <nicolas.ferre@microchip.com>,
        Michal Simek <michal.simek@xilinx.com>,
        "Edgar E. Iglesias" <edgar.iglesias@xilinx.com>
CC:     <linux-kernel@vger.kernel.org>, <monstr@monstr.eu>,
        "Edgar E. Iglesias" <edgari@xilinx.com>,
        "David S. Miller" <davem@davemloft.net>, <netdev@vger.kernel.org>,
        <u-boot@lists.denx.de>, Joe Hershberger <joe.hershberger@ni.com>
References: <0997a0e77b5e5c04c9a4d277d702d93a1a8a7448.1537373294.git.michal.simek@xilinx.com>
 <20180919180806.3tps6yukhm3ry43i@toto>
 <7e641346-dd4c-4e2a-637f-1b666f13485c@xilinx.com>
 <20eb98a9-edbd-c613-1f76-eccd7e06e052@microchip.com>
From:   Michal Simek <michal.simek@xilinx.com>
Message-ID: <af9f6deb-08a2-4c94-9839-ebe629063e6c@xilinx.com>
Date:   Tue, 25 Sep 2018 08:34:30 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <20eb98a9-edbd-c613-1f76-eccd7e06e052@microchip.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Sep 2018 06:34:41.9114
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 5cfa4d9d-1457-46c6-80b6-08d622b0f9f5
X-MS-Exchange-CrossTenant-Id: 657af505-d5df-48d0-8300-c31994686c5c
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=657af505-d5df-48d0-8300-c31994686c5c;Ip=[149.199.60.83];Helo=[xsj-pvapsmtpgw01]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR02MB5109
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 21.9.2018 14:38, Nicolas Ferre wrote:
> 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@xilinx.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.

ok. I have sent v2.

M