linux-kernel - Re: [PATCH v3 5/6] ARM: mvebu: Add driver for mv98dx3236-soc-id

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 17 Feb 2017 17:17:32 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     Chris Packham <Chris.Packham@...iedtelesis.co.nz>
Cc:     "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        Andrew Lunn <andrew@...n.ch>,
        Jason Cooper <jason@...edaemon.net>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Russell King <linux@...linux.org.uk>,
        Gregory Clement <gregory.clement@...e-electrons.com>,
        Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>
Subject: Re: [PATCH v3 5/6] ARM: mvebu: Add driver for mv98dx3236-soc-id

On Fri, Feb 17, 2017 at 5:22 AM, Chris Packham
<Chris.Packham@...iedtelesis.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@...iedtelesis.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.

     Arnd