Re: [PATCH 1/2] MIPS: Add barriers between dcache & icache flushes
Sven Eckelmann <[email protected]> Mon, 06 Mar 2023 11:28:15 +0100
| Newsgroups | gmane.linux.kernel,gmane.linux.ports.mips.general |
|---|---|
| Message-ID | <4818332.31r3eYUQgx@ripper> |
--nextPart4473054.LvFx2qVVIh Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii"; protected-headers="v1" From: Sven Eckelmann <[email protected]> Date: Mon, 06 Mar 2023 11:28:15 +0100 Message-ID: <4818332.31r3eYUQgx@ripper> References: <[email protected]> MIME-Version: 1.0 On Monday, 22 February 2016 19:09:44 CET Paul Burton wrote: > Index-based cache operations may be arbitrarily reordered by out of > order CPUs. Thus code which writes back the dcache & then invalidates > the icache using indexed cache ops must include a barrier between > operating on the 2 caches in order to prevent the scenario in which: > > - icache invalidation occurs. > > - icache fetch occurs, due to speculation. > > - dcache writeback occurs. > > If the above were allowed to happen then the icache would contain stale > data. Forcing the dcache writeback to complete before the icache > invalidation avoids this. > > Signed-off-by: Paul Burton <[email protected]> > Cc: James Hogan <[email protected]> > --- What happened to this patch? Because it seems like it is required for some 74kc devices to get them booting (instead of being stuck in an endless tlbmiss_handler_setup_pgd loop): * https://github.com/freifunk-gluon/gluon/issues/2784 * https://github.com/openwrt/openwrt/commit/ea6fb9c16dfb9763ea681803db65644b68bae873 * https://github.com/freifunk-gluon/gluon/pull/2810 Kind regards, Sven --nextPart4473054.LvFx2qVVIh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEF10rh2Elc9zjMuACXYcKB8Eme0YFAmQFwD8ACgkQXYcKB8Em e0bR3Q//Riq/B7nemvF/RQ63b4IjVgBkq81+RlQ6xLBdaDEnFr8phcT8RnSJ74tb ljc8OkXvqL56Ddt9svcyBRHma4gu3UbowdxJCMw4xgv6SV0Fa8yd0Yk5NSlvOsv2 dlg21L+515rYEz9Ow/FcvC1x60CIOTZLMIw87qu2lOgQY7SdG0QB4z/GZWg6xubR J3iHMB1b0JGdZRLA+u5GK0235oZXU0zbMk8ZOovu111E7AMULcnwCmbUvPEbr21k Gw1BPAuYYpb8h3dk3lkY3GxkwGyeZrblFiOav8pd2y73hDdWgo4da8t+BCAUV4oM Ks7DabVTGZyAFlXcrQZ0RczK3C6MZF6Z1KXSuJxI2NiTNvl78OUbfek9DDVYgA8g nLcjXNZtoOVoF5/1I8+7bCcNnXwfhaEHidO0IkY9RkezYoQWeFeIeLfaV2BFFwG7 RllYLH/NJGVAWJJrmcZEWF6v9Q6w/G/QySO+OjJ007Ph9HyjWLmiHGrizOkkTj0z KozMR8iRY6bpT6B+t2Zm0xmN9JRDpHRgCVkqZcE4BF2fptwcB/7GsfiogJ7heiIL OyDLNNoUmE7I6eJDCR/bHL4yLHp/8SctrD/wB7nk9NEouhXeCtqw/xg5e2elOBGw 7K3T3F5lICq0FXFZg5dM863XK7sCeIVzObj2O9CBuS3BGZhwDL4= =WpWD -----END PGP SIGNATURE----- --nextPart4473054.LvFx2qVVIh--