[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20161221.132104.1026207180067066991.davem@davemloft.net>
Date: Wed, 21 Dec 2016 13:21:04 -0500 (EST)
From: David Miller <davem@...emloft.net>
To: Joao.Pinto@...opsys.com
Cc: peppe.cavallaro@...com, hock.leong.kweh@...el.com,
niklas.cassel@...s.com, pavel@....cz, linux-kernel@...r.kernel.org,
netdev@...r.kernel.org
Subject: Re: [PATCH] stmmac: CSR clock configuration fix
From: Joao Pinto <Joao.Pinto@...opsys.com>
Date: Tue, 20 Dec 2016 11:21:47 +0000
> When testing stmmac with my QoS reference design I checked a problem in the
> CSR clock configuration that was impossibilitating the phy discovery, since
> every read operation returned 0x0000ffff. This patch fixes the issue.
>
> Signed-off-by: Joao Pinto <jpinto@...opsys.com>
This isn't enough.
It looks like various parts of this driver set the mask field
differently.
dwmac1000_core.c and dwmac100_core.c set the mask to be the low bits.
But dwmac4_core.c uses GENMASK(11, 8) which means the mask is a value
which is shifted up already.
So your patch will break chips driven by dwmac4_core.c.
In order for your change to be correct you must consolidate all of
these various pieces to use the same convention.
Powered by blists - more mailing lists