From: thomas.petazzoni@free-electrons•com (Thomas Petazzoni)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH 0/6] ARM: mvebu: mvebu-mbus and I/O coherency fixes
Date: Sat, 10 Jan 2015 17:50:30 +0100 [thread overview]
Message-ID: <20150110175030.186ef929@free-electrons.com> (raw)
In-Reply-To: <20150110163001.GA5392@lunn.ch>
Dear Andrew Lunn,
On Sat, 10 Jan 2015 17:30:01 +0100, Andrew Lunn wrote:
> Fixing window 13 is a big fix. It is getting late in the -rc cycle,
> which is partially my responsibility, since i was waiting for some
> tested-by:'s. But these patches are also heading towards
> stable. Stable rules state:
>
> - It must be obviously correct and tested.
> - It cannot be bigger than 100 lines, with context.
> - It must fix only one thing.
> - It must fix a real bug that bothers people (not a, "This could be a
> problem..." type thing).
> - It must fix a problem that causes a build error (but not for things
> marked CONFIG_BROKEN), an oops, a hang, data corruption, a real
> security issue, or some "oh, that's not good" issue. In short, something
> critical.
>
> The first patch is over 300 lines. Because of its size, i'm also not
> able to say it is obviously correct. It does however tick some of the
> other boxes, fix only one thing, fixes a real problem.
>
> Is there a more minimal fix? How big an impact is there in just
> disabling window 13? How much pressure do we have on windows? Can
> Michal Mazur live with one less window?
>
> We could then pushing this proper fix into the next merge window?
I believe pushing the proposed fix for the next merge window, and
having a simpler fix that consists in simply not using window 13 for
stable is a reasonable approach.
> For the IO Coherency fixes, obviousness is an issue. This is
> especially true since your own comment is "still not working 100%
> properly, but it is apparently not worse than it was."
>
> Maybe the correct fix for stable is to simply disable the I/O
> coherency hardware. That at least makes mainline stable. Once we have
> a real, well tested, 100% fix, take it via the normal merge window.
However, I'm not a big fan of this idea. I'd really like to have I/O
coherency progressively improved, and made working.
The patch is actually make the code *simpler* since it removes the
custom dma_map_ops and uses a set of operations that already exists in
the kernel. The changes in the mvebu-mbus driver are minimal.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
next prev parent reply other threads:[~2015-01-10 16:50 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-30 12:43 [PATCH 0/6] ARM: mvebu: mvebu-mbus and I/O coherency fixes Thomas Petazzoni
2014-12-30 12:43 ` [PATCH 1/6] dt: bindings: update mvebu-mbus DT binding with new compatible properties Thomas Petazzoni
2015-01-09 16:53 ` Andrew Lunn
2015-01-19 22:25 ` Andrew Lunn
2014-12-30 12:43 ` [PATCH 2/6] bus: mvebu-mbus: fix support of MBus window 13 on Armada XP/375/38x Thomas Petazzoni
2015-01-18 15:50 ` [PATCH] bus: mvebu-mbus: fix support of MBus window 13 Andrew Lunn
2015-01-18 15:53 ` Andrew Lunn
2015-01-18 16:29 ` Thomas Petazzoni
2015-01-19 22:14 ` Andrew Lunn
2015-01-19 22:29 ` [PATCH 2/6] bus: mvebu-mbus: fix support of MBus window 13 on Armada XP/375/38x Andrew Lunn
2015-01-20 15:05 ` Thomas Petazzoni
2014-12-30 12:43 ` [PATCH 3/6] ARM: mvebu: fix compatible strings of MBus on Armada 375 and Armada 38x Thomas Petazzoni
2015-01-19 22:33 ` Andrew Lunn
2014-12-30 12:43 ` [PATCH 4/6] bus: mvebu-mbus: make sure SDRAM CS for DMA don't overlap the MBus bridge window Thomas Petazzoni
2015-01-09 16:59 ` Andrew Lunn
2015-01-19 22:34 ` Andrew Lunn
2014-12-30 12:43 ` [PATCH 5/6] bus: mvebu-mbus: use automatic I/O synchronization barriers Thomas Petazzoni
2014-12-30 12:43 ` [PATCH 6/6] ARM: mvebu: use arm_coherent_dma_ops Thomas Petazzoni
2014-12-30 16:27 ` [PATCH 0/6] ARM: mvebu: mvebu-mbus and I/O coherency fixes Andrew Lunn
2014-12-30 17:20 ` Thomas Petazzoni
2015-01-09 15:52 ` Thomas Petazzoni
2015-01-10 16:30 ` Andrew Lunn
2015-01-10 16:50 ` Thomas Petazzoni [this message]
2015-01-10 17:16 ` Andrew Lunn
2015-01-10 18:56 ` Arnd Bergmann
2015-01-10 19:57 ` Thomas Petazzoni
2015-01-10 20:40 ` Arnd Bergmann
2015-01-10 21:36 ` Thomas Petazzoni
2015-01-10 21:51 ` Arnd Bergmann
2015-01-12 12:36 ` Russell King - ARM Linux
2015-01-12 12:41 ` Thomas Petazzoni
2015-01-10 16:33 ` Andrew Lunn
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=20150110175030.186ef929@free-electrons.com \
--to=thomas.petazzoni@free-electrons$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.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