From: andrew@lunn•ch (Andrew Lunn)
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 18:16:52 +0100 [thread overview]
Message-ID: <20150110171652.GA30963@lunn.ch> (raw)
In-Reply-To: <20150110175030.186ef929@free-electrons.com>
On Sat, Jan 10, 2015 at 05:50:30PM +0100, Thomas Petazzoni wrote:
> 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.
Hi Thomas
Thanks for this. I will pull the two patches into soc today and into
mvebu/linux-next for some testing.
> > 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.
Yes, the second patch is a lot of removal of code, which is always
nice.
But i would still like comments from others.
Andrew
next prev parent reply other threads:[~2015-01-10 17:16 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
2015-01-10 17:16 ` Andrew Lunn [this message]
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=20150110171652.GA30963@lunn.ch \
--to=andrew@lunn$(echo .)ch \
--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