linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chris Packham <Chris.Packham@alliedtelesis.co.nz>
To: Arnd Bergmann <arnd@arndb.de>
Cc: "linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	Andrew Lunn <andrew@lunn.ch>,
	"Jason Cooper" <jason@lakedaemon.net>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Russell King <linux@armlinux.org.uk>,
	"Gregory Clement" <gregory.clement@free-electrons.com>,
	Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Subject: Re: [PATCH v3 5/6] ARM: mvebu: Add driver for mv98dx3236-soc-id
Date: Tue, 21 Feb 2017 04:16:39 +0000	[thread overview]
Message-ID: <e8aa98ec22214e77ae4b060dccec8a78@svr-chch-ex1.atlnz.lc> (raw)
In-Reply-To: CAK8P3a0Zyii5QbGAtR0TCEsUnGwkH1G5+_bPku4VYPKM-aTS8g@mail.gmail.com

On 18/02/17 05:17, Arnd Bergmann wrote:
> On Fri, Feb 17, 2017 at 5:22 AM, Chris Packham
> <Chris.Packham@alliedtelesis.co.nz> wrote:
>> Hi Arnd,
>> On 17/02/17 02:28, Arnd Bergmann wrote:
>>> On Thursday, February 16, 2017 9:50:39 PM CET Chris Packham wrote:
>>>> The DFX server on the 98dx3236 and compatible SoCs has an ID register
>>>> that provides revision information that the PCI based ID register
>>>> doesn't have. Use this if it's available.
>>>>
>>>> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
>>>>
>>>
>>> How about putting this new code into a separate driver in
>>> drivers/soc/? I don't think you need the early probing we have
>>> here, and not that much is shared otherwise.
>>>
>>
>> Not putting it there means we'll get the pci fall-back behaviour which
>> will result in a incorrect rev value. Having said that no callers of
>> mvebu_get_soc_id() currently care about these specific SoCs so not
>> having the right rev is not an issue at the moment.
>
> We should still care about incorrect IDs as they are shown to user space,
> which could start relying on it in theory.
>
> However, the PCI ID should only be used on chips that have a PCI
> host with an ID known to be correct, so maybe we can restrict
> get_soc_id_by_pci() in a way that the mvebu_pcie_of_match_table
> matching does not trigger on chips on which we don't want it to.
>

I think we'd need to add some kind of soc-id-from-pci node to indicate 
devices where the best ID is from the PCI registers. We'd also need to 
worry about backwards compatibility etc.

For now since nothing is relying on the rev and the SoC ID is correct 
coming from the PCI registers I'm happy to sit on this patch until a 
need to get the rev arises.

  reply	other threads:[~2017-02-21  4:16 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-16  8:50 [PATCH v2 0/6] Updates for Marvell Switch SoCs Chris Packham
2017-02-16  8:50 ` [PATCH v3 1/6] ARM: dts: Fix typo in armada-xp-98dx4251 Chris Packham
2017-02-27 14:50   ` Rob Herring
2017-02-16  8:50 ` [PATCH v3 2/6] ARM: dts: armada-xp-98dx3236: combine dfx server nodes Chris Packham
2017-02-27 14:49   ` Rob Herring
2017-02-16  8:50 ` [PATCH v3 3/6] ARM: dts: Use armada-370-xp as a base for armada-xp-98dx3236 Chris Packham
2017-02-16  8:50 ` [PATCH v3 4/6] ARM: dts: mvebu: Add binding for mv98dx3236-soc-id Chris Packham
2017-02-27 15:00   ` Rob Herring
2017-02-16  8:50 ` [PATCH v3 5/6] ARM: mvebu: Add driver " Chris Packham
2017-02-16 13:27   ` Arnd Bergmann
2017-02-17  4:22     ` Chris Packham
2017-02-17 16:17       ` Arnd Bergmann
2017-02-21  4:16         ` Chris Packham [this message]
2017-02-16  8:50 ` [PATCH v3 6/6] ARM: dts: mvebu: Move mv98dx3236 clock bindings Chris Packham
2017-02-27 15:15   ` Rob Herring
2017-03-07 17:10 ` [PATCH v2 0/6] Updates for Marvell Switch SoCs Gregory CLEMENT
2017-03-07 19:38   ` Chris Packham

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=e8aa98ec22214e77ae4b060dccec8a78@svr-chch-ex1.atlnz.lc \
    --to=chris.packham@alliedtelesis.co.nz \
    --cc=andrew@lunn.ch \
    --cc=arnd@arndb.de \
    --cc=gregory.clement@free-electrons.com \
    --cc=jason@lakedaemon.net \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=sebastian.hesselbarth@gmail.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).