From: Lino Sanfilippo <LinoSanfilippo@gmx•de>
To: Bryan.Whitehead@microchip•com, davem@davemloft•net
Cc: netdev@vger•kernel.org
Subject: Re: [PATCH net-next,V2] Add LAN9352 Ethernet Driver
Date: Tue, 16 Feb 2016 23:09:56 +0100 [thread overview]
Message-ID: <56C39E34.9080801@gmx.de> (raw)
In-Reply-To: <90A7E81AE28BAE4CBDDB3B35F187D264402EF62A@CHN-SV-EXMX02.mchp-main.com>
On 12.02.2016 20:10, Bryan.Whitehead@microchip•com wrote:
> Lino,
>
> Regarding "a matching smp_rmb() in the irq handler"
> There is a smp_wmb() in the irq handler, since in both cases we are forcing a write operation on software_irq_signal.
>
> I suppose using atomic operations on software_irq_signal would also work, but this driver was based on
> drivers/net/ethernet/smsc/smsc911x.c
> And if possible I'd prefer to keep logical changes to a minimum.
> Plus this is not a "read modify write" scenario so I think the memory barrier is sufficient.
> Do you agree?
>
Hi Bryan,
youre right, smsc911x.c does the same thing and probably its ok. As far
as I have understood smp memory barriers (mainly from reading
memory-barriers.txt), they normally should be paired to ensure that a
"reader" thread actually sees what an "updater" thread writes - paired
in a sense that there is a corresponding smp_rmb() for a smp_wmb().
So in this case I expected the need for a smp_rmb() at least in that
loop in open() which waits for the software_irq_signal flag to toggle.
Something like
while (timeout--) {
smp_rmb();
if (pdata->software_irq_signal)
break;
usleep_range(1000, 10000);
}
But AFAICS calling usleep_range() already implies memory barriers, so I
agree that there is probably no need for an explicit smp_rmb.
Regards,
Lino
next prev parent reply other threads:[~2016-02-16 22:10 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-11 18:58 [PATCH net-next,V2] Add LAN9352 Ethernet Driver Bryan.Whitehead
2016-02-11 21:55 ` Andrew Lunn
2016-02-12 16:51 ` Bryan.Whitehead
2016-02-12 17:11 ` Andrew Lunn
2016-02-16 19:34 ` Bryan.Whitehead
2016-02-16 19:51 ` David Miller
2016-02-16 20:21 ` Andrew Lunn
2016-02-12 0:14 ` Lino Sanfilippo
2016-02-12 19:10 ` Bryan.Whitehead
2016-02-16 22:09 ` Lino Sanfilippo [this message]
2016-02-12 2:18 ` Florian Fainelli
2016-02-12 7:20 ` Andrew Lunn
2016-02-12 16:53 ` Bryan.Whitehead
2016-02-12 17:18 ` Andrew Lunn
2016-02-16 19:41 ` Bryan.Whitehead
2016-02-16 19:52 ` David Miller
2016-02-16 20:36 ` Andrew Lunn
2016-02-16 20:43 ` David Miller
2016-02-16 20:48 ` Bryan.Whitehead
2016-02-16 20:52 ` David Miller
2016-02-16 21:32 ` Bryan.Whitehead
2016-02-16 21:38 ` David Miller
2016-02-16 22:15 ` Andrew Lunn
2016-02-17 0:06 ` Florian Fainelli
2016-02-17 0:31 ` Andrew Lunn
2016-02-19 19:29 ` Bryan.Whitehead
2016-02-19 20:14 ` Andrew Lunn
2016-02-19 21:21 ` Bryan.Whitehead
2016-03-24 21:16 ` Bryan.Whitehead
2016-03-24 22:06 ` Andrew Lunn
2016-03-24 22:36 ` Florian Fainelli
2016-02-16 20:57 ` Andrew Lunn
2016-02-16 21:37 ` Bryan.Whitehead
2016-02-16 21:40 ` David Miller
2016-02-12 23:21 ` Bryan.Whitehead
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56C39E34.9080801@gmx.de \
--to=linosanfilippo@gmx$(echo .)de \
--cc=Bryan.Whitehead@microchip$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=netdev@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox