All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lars-Peter Clausen <lars@metafoo.de>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Paul Burton <paul.burton@imgtec.com>,
	linux-mmc <linux-mmc@vger.kernel.org>,
	Maarten ter Huurne <maarten@treewalker.org>
Subject: Re: [PATCH] mmc: sd: Meet alignment requirements for raw_ssr DMA
Date: Tue, 20 Dec 2016 21:54:59 +0100	[thread overview]
Message-ID: <5d4329b6-841b-a6e6-f819-b14348bb5ac7@metafoo.de> (raw)
In-Reply-To: <CAPDyKFprZQ1pCQ+8bRXMi1ArD_VJAhBMGd9=hRRwegXf3PxmyQ@mail.gmail.com>

On 12/20/2016 09:41 PM, Ulf Hansson wrote:
> [...]
> 
>>>>>> +       raw_ssr = kmalloc(sizeof(card->raw_ssr), GFP_KERNEL);
>>>>>> +       if (!raw_ssr)
>>>>>> +               return -ENOMEM;
>>>>>> +
>>>
>>> Creating this bounce buffer does of course comes with a small cost.
>>> Maybe we could neglect its impact!?
>>>
>>> However we could also make the card->raw_ssr be cacheline aligned, via
>>> using the __cacheline_aligned attribute for it.
>>>
>>> Also, this isn't the only case when the mmc core creates bounce
>>> buffers while reading card registers during the card initialization.
>>>
>>> Perhaps a better method is to use the __cacheline_aligned for these
>>> buffers that needs to be DMA-able (requests which is
>>> MMC_DATA_READ|WRITE)). Of course that change would affect/increase the
>>> number of bytes allocated for each card struct (due to padding), but
>>> since this is just a single struct being allocated per card, this
>>> shouldn't be an issue.
>>>
>>> What do you think?
>>
>> The issue is now in v4.9 and is causing problems on some platforms with the
>> reported card name becoming corrupted (since it cid.prodname is on the same
>> cacheline).
>>
>> I'd say go with the simple solution for the fix, which is using the bounce
>> buffer. If somebody wants to rework this (and all the other bounce buffers)
>> to use __cacheline_aligned or something else that can be done as a separate
>> patch series on top of this.
>>
>> When you apply the patch can you add
>>
>> Fixes: 5275a652d296 ("mmc: sd: Export SD Status via “ssr” device attribute")
> 
> Ahh, I didn't realize this was a fix for a regression. I thought it
> was a long outstanding issue that more or less never occurred.
> 
>>
>> and tag it for stable?
> 
> Yes, of course. I will deal with it as of tomorrow morning. Thanks for
> pinging me on this!

Thanks for the quick reply!


  reply	other threads:[~2016-12-20 20:56 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-11 14:22 [PATCH] mmc: sd: Meet alignment requirements for raw_ssr DMA Paul Burton
2016-11-17 12:51 ` Ulf Hansson
2016-11-17 13:19   ` Paul Burton
2016-11-23 12:36     ` Ulf Hansson
2016-12-20 18:45       ` Lars-Peter Clausen
2016-12-20 20:41         ` Ulf Hansson
2016-12-20 20:54           ` Lars-Peter Clausen [this message]
2016-12-21  7:42 ` Ulf Hansson

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=5d4329b6-841b-a6e6-f819-b14348bb5ac7@metafoo.de \
    --to=lars@metafoo.de \
    --cc=linux-mmc@vger.kernel.org \
    --cc=maarten@treewalker.org \
    --cc=paul.burton@imgtec.com \
    --cc=ulf.hansson@linaro.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 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.