All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
From: broonie@kernel.org (Mark Brown)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm64: topology: add MPIDR-based detection
Date: Tue, 3 Jun 2014 22:04:24 +0100	[thread overview]
Message-ID: <20140603210424.GJ31751@sirena.org.uk> (raw)
In-Reply-To: <20140603173103.GA18004@red-moon>

On Tue, Jun 03, 2014 at 06:31:03PM +0100, Lorenzo Pieralisi wrote:

> I refactored the patch (UP code path) and deliberately removed the
> code that packs affinity levels into the cluster id. I do not
> like packing the affinity levels and on second thoughts packing the
> unused affinity levels into cluster_id is as correct as packing
> the unused affinity levels into core_id (ie it is arbitrary), so I do

I'm having a really hard time seeing this as anything other than a step
back.  Your change causes us to discard the higher affinity levels which
seems like something we actively know to be misleading and means that we
will be handing the scheduler two different identically numbered cores
(all the affinity levels we do pay attention to will be identical) if we
ever encounter such a system which is actively broken.

> not think we should do it, that's the reason why we defined DT bindings
> to add a proper topology semantics and we should use them when the MPIDR
> values deviate from the "recommendations".

I'd agree with not going to great lengths unless someone defines
semantics for the higher affinity levels in the future however it does
seem like completely ignoring them when it's so easy to take some
account of them is insufficiently defensive - it's similar to things
like putting the of_node_put() calls in even though they don't do
anything at the minute.

> Patch attached, my ack included, should be ready to go, unless you
> object to that.

Well, I certainly don't object to getting something merged here.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140603/817d97c1/attachment.sig>

  reply	other threads:[~2014-06-03 21:04 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-01 17:37 [PATCH] arm64: topology: add MPIDR-based detection Mark Brown
2014-06-03 17:31 ` Lorenzo Pieralisi
2014-06-03 21:04   ` Mark Brown [this message]
2014-06-04  9:34     ` Lorenzo Pieralisi
2014-06-04 11:57       ` Mark Brown
2014-06-04 13:01         ` Lorenzo Pieralisi
2014-06-04 13:54           ` Mark Brown
2014-06-04 15:51             ` Lorenzo Pieralisi
2014-06-04 16:34               ` Mark Brown
2014-06-04 17:10                 ` Lorenzo Pieralisi
2014-08-18  7:39                   ` Ganapatrao Kulkarni
2014-08-18 22:36                     ` Lorenzo Pieralisi
2014-08-20  4:08                       ` Ganapatrao Kulkarni
2014-08-21  5:15                         ` Zi Shen Lim
2014-08-23 10:43                           ` Lorenzo Pieralisi
2014-08-28  6:49                             ` Ganapatrao Kulkarni

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=20140603210424.GJ31751@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.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.