From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
To: David Miller <davem@davemloft.net>, horms+renesas@verge.net.au
Cc: magnus.damm@gmail.com, netdev@vger.kernel.org,
linux-renesas-soc@vger.kernel.org,
wsa+renesas@sang-engineering.com,
kazuya.mizuguchi.ks@renesas.com
Subject: Re: [PATCH/RFC net-next 3/5] ravb: do not write 1 to reserved bits
Date: Sat, 21 Apr 2018 23:44:47 +0300 [thread overview]
Message-ID: <1908c6d0-f3e6-6436-c41c-7d2a388f91d4@cogentembedded.com> (raw)
In-Reply-To: <20180417.101553.1512039208518397234.davem@davemloft.net>
Hello!
On 04/17/2018 05:15 PM, David Miller wrote:
>> From: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
>>
>> This patch corrects writing 1 to reserved bits.
>> The write value should be 0.
>>
>> Signed-off-by: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
>> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
>
> How are we ending up in situations where the driver is trying to write
> non-zero values to those fields in the first place?
The brain damaged AVB core design is to blame here. You have to write 0 to
clear the set bits and, at the same time, you can't write 1 to the reserved
bits... :-/
> The places creating those values should be making sure that the
> reserved bits are never set.
That's basically what this patch is doing.
> If you mask out the reserved bits in the register writing locations,
> this just hides bugs.
There are no *other* locations in some cases...
And I don't think that forcing the reserved bits to 1 after a register is
read would look better. :-(
MBR, Sergei
next prev parent reply other threads:[~2018-04-21 20:44 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-17 8:50 [PATCH/RFC net-next 0/5] ravb: updates Simon Horman
2018-04-17 8:50 ` [PATCH/RFC net-next 1/5] ravb: fix inconsistent lock state at enabling tx timestamp Simon Horman
2018-04-17 10:07 ` Wolfram Sang
2018-04-17 13:11 ` Geert Uytterhoeven
2018-04-17 14:13 ` David Miller
2018-04-17 8:50 ` [PATCH/RFC net-next 2/5] ravb: correct ptp does failure after suspend and resume Simon Horman
2018-04-17 10:05 ` Wolfram Sang
2018-04-17 16:05 ` Sergei Shtylyov
2018-04-21 20:33 ` Sergei Shtylyov
2018-04-17 8:50 ` [PATCH/RFC net-next 3/5] ravb: do not write 1 to reserved bits Simon Horman
2018-04-17 14:15 ` David Miller
2018-04-21 20:44 ` Sergei Shtylyov [this message]
2018-04-21 20:53 ` Sergei Shtylyov
2018-04-17 8:50 ` [PATCH/RFC net-next 4/5] ravb: remove undocumented processing Simon Horman
2018-04-17 10:09 ` Wolfram Sang
2018-04-17 14:14 ` David Miller
2018-04-21 20:59 ` Sergei Shtylyov
2018-04-17 8:50 ` [PATCH/RFC net-next 5/5] ravb: remove tx buffer addr 4byte alilgnment restriction for R-Car Gen3 Simon Horman
2018-04-22 15:11 ` Sergei Shtylyov
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=1908c6d0-f3e6-6436-c41c-7d2a388f91d4@cogentembedded.com \
--to=sergei.shtylyov@cogentembedded.com \
--cc=davem@davemloft.net \
--cc=horms+renesas@verge.net.au \
--cc=kazuya.mizuguchi.ks@renesas.com \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=magnus.damm@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=wsa+renesas@sang-engineering.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.