linux-kernel - Re: [PATCH V3 2/2] base/drivers/arch_topology: Default dmips-mhz if they are not set in DT

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 linux-cve-announce 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]

Message-ID: <20181126110915.372tanwevpfcr7zp@queper01-ThinkPad-T460s>
Date:   Mon, 26 Nov 2018 11:09:15 +0000
From:   Quentin Perret <quentin.perret@...aro.org>
To:     Viresh Kumar <viresh.kumar@...aro.org>
Cc:     Daniel Lezcano <daniel.lezcano@...aro.org>, rjw@...ysocki.net,
        linux-kernel@...r.kernel.org,
        Chris Redpath <chris.redpath@...aro.org>,
        Amit Kucheria <amit.kucheria@...aro.org>,
        Nicolas Dechesne <nicolas.dechesne@...aro.org>,
        Niklas Cassel <niklas.cassel@...aro.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>
Subject: Re: [PATCH V3 2/2] base/drivers/arch_topology: Default dmips-mhz if
 they are not set in DT

On Monday 26 Nov 2018 at 15:49:55 (+0530), Viresh Kumar wrote:
> On 26-11-18, 11:08, Daniel Lezcano wrote:
> > On 26/11/2018 10:52, Quentin Perret wrote:
> > > Maybe you want to test 'if (!raw_capacity || cap_parsing_failed)' at the
> > > top of topology_parse_cpu_capacity() ?
> > 
> > I prefer to update the documentation, it makes more sense than adding
> > more cumbersome tests in the current code.
> 
> +1
> 
> Throwing an error and ignoring DT number completely for the capacity
> are good enough in my opinion as well.
> 
> And who cares for the platforms that can't even fill the DT properly :)

Right, I think we all agree the case with a partially filled DT is
broken. I don't actually care too much about the behaviour in this case,
but it needs to be consistent with the doc.

So, as long as you fix the doc, that change is fine by me :-)

Thanks,
Quentin