From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.9 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 01BFCC4363D for ; Sat, 3 Oct 2020 08:49:46 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id AD0DB206F8 for ; Sat, 3 Oct 2020 08:49:45 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=alien8.de header.i=@alien8.de header.b="JfEMjALM" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725803AbgJCIto (ORCPT ); Sat, 3 Oct 2020 04:49:44 -0400 Received: from mail.skyhub.de ([5.9.137.197]:57056 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725648AbgJCIto (ORCPT ); Sat, 3 Oct 2020 04:49:44 -0400 Received: from zn.tnic (p200300ec2f1db40057382cf78206bf6d.dip0.t-ipconnect.de [IPv6:2003:ec:2f1d:b400:5738:2cf7:8206:bf6d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 0C2631EC046C; Sat, 3 Oct 2020 10:49:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1601714983; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:in-reply-to:in-reply-to: references:references; bh=8aK0fTH6/q1KJZHJYswOgg0ec7iKPfMyHMyRu4CPSP0=; b=JfEMjALMNN03rvQd6UQUkkAQe/eMe6fCN3kgA//lixqMg6xlYdUH3Ga129XnjdCEukrQgd FzI7FnUaW4N9rcdg3BXMWecDV73bOCwIYthKbFxeRuPrMBTfVcyXZxNxttEJeTUUPsxVxW RPXQig2/6LHLDit+sMjy4PkWA1SRlIk= Date: Sat, 3 Oct 2020 10:49:34 +0200 From: Borislav Petkov To: Ricardo Neri Cc: Greg Kroah-Hartman , x86@kernel.org, Ingo Molnar , Thomas Gleixner , "Rafael J. Wysocki" , Tony Luck , Len Brown , "Ravi V. Shankar" , 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 List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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/ solely. Please use that from now on. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette