From: Eli Billauer <eli.billauer@gmail.com>
To: arnd@arndb.de, gregkh@linuxfoundation.org
Cc: linux-kernel@vger.kernel.org, Eli Billauer <eli.billauer@gmail.com>
Subject: [PATCH] char: xillybus: Fix internal data structure initialization
Date: Wed, 24 Feb 2016 10:40:51 +0200 [thread overview]
Message-ID: <1456303251-7726-1-git-send-email-eli.billauer@gmail.com> (raw)
A couple of fields in a data structure, which is used by the driver only,
were not initialized properly during the driver's setup.
The primary issue with this bug was that channel->wr_buf_size remained zero,
so calls to dma_sync_single_for_cpu() took place with zero size, and
consequently did nothing.
This had a rather minimal practical impact, because
(a) these calls are NOPs on Intel/AMD platforms, as well as other platforms
with coherent cache, and
(b) it's extremely rare that any cache line would survive between two reads
from a given DMA buffer
Hence no significant practical difference is expected with this patch.
Signed-off-by: Eli Billauer <eli.billauer@gmail.com>
---
drivers/char/xillybus/xillybus_core.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/char/xillybus/xillybus_core.c b/drivers/char/xillybus/xillybus_core.c
index 77d6c12..dcd19f3 100644
--- a/drivers/char/xillybus/xillybus_core.c
+++ b/drivers/char/xillybus/xillybus_core.c
@@ -509,7 +509,7 @@ static int xilly_setupchannels(struct xilly_endpoint *ep,
channel->log2_element_size = ((format > 2) ?
2 : format);
- bytebufsize = channel->rd_buf_size = bufsize *
+ bytebufsize = bufsize *
(1 << channel->log2_element_size);
buffers = devm_kcalloc(dev, bufnum,
@@ -523,6 +523,7 @@ static int xilly_setupchannels(struct xilly_endpoint *ep,
if (!is_writebuf) {
channel->num_rd_buffers = bufnum;
+ channel->rd_buf_size = bytebufsize;
channel->rd_allow_partial = allowpartial;
channel->rd_synchronous = synchronous;
channel->rd_exclusive_open = exclusive_open;
@@ -533,6 +534,7 @@ static int xilly_setupchannels(struct xilly_endpoint *ep,
bufnum, bytebufsize);
} else if (channelnum > 0) {
channel->num_wr_buffers = bufnum;
+ channel->wr_buf_size = bytebufsize;
channel->seekable = seekable;
channel->wr_supports_nonempty = supports_nonempty;
--
1.7.2.3
next reply other threads:[~2016-02-24 8:41 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-24 8:40 Eli Billauer [this message]
-- strict thread matches above, loose matches on Subject: below --
2016-02-23 11:41 [PATCH] char: xillybus: Fix internal data structure initialization Eli Billauer
2016-02-23 15:22 ` Greg KH
2016-02-23 15:35 ` Eli Billauer
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=1456303251-7726-1-git-send-email-eli.billauer@gmail.com \
--to=eli.billauer@gmail.com \
--cc=arnd@arndb.de \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox