Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Sat, 3 Oct 2020 10:49:34 +0200
From:   Borislav Petkov <bp@alien8.de>
To:     Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
Cc:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>, x86@kernel.org,
        Ingo Molnar <mingo@kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
        Tony Luck <tony.luck@intel.com>,
        Len Brown <len.brown@intel.com>,
        "Ravi V. Shankar" <ravi.v.shankar@intel.com>,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/4] drivers core: Introduce CPU type sysfs interface
Message-ID: <20201003084934.GA14035@zn.tnic>
References: <20201003011745.7768-1-ricardo.neri-calderon@linux.intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20201003011745.7768-1-ricardo.neri-calderon@linux.intel.com>
Precedence: bulk

On Fri, Oct 02, 2020 at 06:17:41PM -0700, Ricardo Neri wrote:
> Patch 1 of the series proposes the generic interface, with hooks
> that architectures can override to suit their needs. The three patches
> patches implement such interface for x86 (as per request from Boris,
> I pulled patch 2 from a separate submission [1]).

So I ask you to show me the whole thing, how this is supposed to be used
in a *real* use case and you're sending me a couple of patches which
report these heterogeneous or whatever they're gonna be called CPUs.

Are you telling me that all this development effort was done so that
you can report heterogeneity in sysfs? Or you just had to come up with
*something*?

Let me try again: please show me the *big* *picture* with all the code
how this is supposed to be used. In the patches I read a bunch of "may"
formulations of what is possible and what userspace could do and so on.

Not that - show me the *full* and *real* use cases which you are
enabling and which justify all that churn. Instead of leaving it all to
userspace CPUID and the kernel not caring one bit.

Does that make more sense?

> [1]. https://lkml.org/lkml/2020/10/2/1013

For supplying links, we use lore.kernel.org/r/<message-id> solely.
Please use that from now on.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette