[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5433D98A.2060904@freescale.com>
Date: Tue, 7 Oct 2014 15:16:10 +0300
From: Claudiu Manoil <claudiu.manoil@...escale.com>
To: David Laight <David.Laight@...LAB.COM>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
CC: "David S. Miller" <davem@...emloft.net>,
Xiubo Li <Li.Xiubo@...escale.com>,
Shruti Kanetkar <Shruti@...escale.com>,
"Kim Phillips" <kim.phillips@...escale.com>
Subject: Re: [net v2 3/8] net/fsl_pq_mdio: Replace spin_event_timeout() with
arch independent
On 10/7/2014 11:12 AM, David Laight wrote:
> From: netdev-owner@...r.kernel.
>> spin_event_timeout() is PPC dependent, use an arch independent
>> equivalent instead.
>
> I think you should white a local function/#define that expands to spin_event_timeout()
> on ppc and to the code below you are substituting on other architectures.
>
>> /* Wait for the transaction to finish */
>> - status = spin_event_timeout(!(ioread32be(®s->miimind) &
>> - MIIMIND_BUSY), MII_TIMEOUT, 0);
>> + timeout = MII_TIMEOUT;
>> + while ((ioread32be(®s->miimind) & MIIMIND_BUSY) && timeout) {
>> + cpu_relax();
>> + timeout--;
>> + }
>
> David
>
>
>
Hi David,
This point is debatable. Still better than adding a new local function
would be to provide an implementation for spin_even_timeout() for ARM.
But it is not the place of the ethernet driver to provide an
implementation of spin_event_timeout() on ARM.
Instead, I opted to simplify the busy wait/ timeout mechanism
in the driver using a simple and arch independent implementation
replacing the PPC specific spin_event_timeout(). This timeout
implementation, open-coded as a while() loop, is commonly used by other
drivers too and I think that for this particular driver (fsl_pq_mdio) it
is good enough to do the job, while keeping the code simple and
portable. It may not be as precise as spin_event_timeout() on PPC, but
good enough.
Thanks,
Claudiu
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists