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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2AF80C46467 for ; Tue, 29 Nov 2022 14:34:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231902AbiK2Oeg (ORCPT ); Tue, 29 Nov 2022 09:34:36 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43468 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235592AbiK2Oeb (ORCPT ); Tue, 29 Nov 2022 09:34:31 -0500 Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8AE791124 for ; Tue, 29 Nov 2022 06:34:29 -0800 (PST) Received: by mail-lj1-x229.google.com with SMTP id a19so1732489ljk.0 for ; Tue, 29 Nov 2022 06:34:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=yb4TSztLyoh4rIPeJX6N8PljKLgPvaOweLMv0t2KeKo=; b=MFmeuTaqhysIJMoAymRaSNWqDORiLpwZc2g/jhyKH4uzOsVSy2XFdhXSxKw6YsEXQ2 qr4VsxkTe8Ju6uBUJcp1OLQDMMvF/i1Ik4yYs7rMySNM/QrKgVtXj47aVtW1MFQQU4Xr RqxMMpOlMoOPxNr3VuejX5YC9Ij1qpRMT0ANuNlrwhlN3N1zCz4DUpIz7oskgGIKI9wu SMTFCEIIx29L73IDZWxHFP1K5DYiGa1RpN24Qkov6a/c1IIch1cD5bXqSTAfBvQIPGO4 IbS5y7X7Gq0LTNgAEubBjRylZERLFAi6l5dCRoszXBg+Y4+qUnXU+GZuQj5NVCJkKIC9 777w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=yb4TSztLyoh4rIPeJX6N8PljKLgPvaOweLMv0t2KeKo=; b=gtcAJ8S5i490ThxbV2f0V27775lfqgRUuDDv0PopYmAsuQGVYwWSsKCiaTqHKKpNWE U9Ml1tpF8Zg8WoUnw+1KeiSwpaBQCvPbhTTs7OOTHjzAtpXbr+5LxKF0rdEb8UQJhjPr Q4uiJ3PbF+6lv3vGeF3NCXCaBSiQjVGHbPqDEf3tm0Al4Jt0zyYv2hSm0M2GvVwKcvkJ JHC33E2cPz1BrUMCf1tFAcmjwuW2n3/6p49hPohFNUnqm8fyDZXeijTZQLROiYJmjcwp +ScjmoIOQNvUcKERfaMtS60xTaKBHWHlzpv8XmXyF64NlMKnFie8p5HsobwGz8WR7aVi V26w== X-Gm-Message-State: ANoB5pnbkK72q4dpkRd0OCGg0y9dnZfAkelJsMSYZ06mQJAis0fPBMsg ra0RbdElarHNakV6HVEJ+CVD1g== X-Google-Smtp-Source: AA0mqf4Chw0LBirQnmKUx27euTDQ7XNz3zaqy80g5zFnYAsoozD6M4CZTVp58Bq40rr05Yo5WQ+EEg== X-Received: by 2002:a05:6512:2a8d:b0:498:7c7:b98f with SMTP id dt13-20020a0565122a8d00b0049807c7b98fmr18078871lfb.625.1669732467866; Tue, 29 Nov 2022 06:34:27 -0800 (PST) Received: from [192.168.0.20] (088156142067.dynamic-2-waw-k-3-2-0.vectranet.pl. [88.156.142.67]) by smtp.gmail.com with ESMTPSA id r10-20020a2e994a000000b00279a5b85791sm669608ljj.88.2022.11.29.06.34.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 29 Nov 2022 06:34:27 -0800 (PST) Message-ID: Date: Tue, 29 Nov 2022 15:34:26 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 Subject: Re: [PATCH v5 2/4] dt-bindings: cpufreq: apple,soc-cpufreq: Add binding for Apple SoC cpufreq Content-Language: en-US To: Hector Martin , Ulf Hansson Cc: "Rafael J. Wysocki" , Viresh Kumar , Matthias Brugger , Sven Peter , Alyssa Rosenzweig , Rob Herring , Krzysztof Kozlowski , Stephen Boyd , Marc Zyngier , Mark Kettenis , asahi@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-pm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Linus Torvalds References: <20221128142912.16022-1-marcan@marcan.st> <20221128142912.16022-3-marcan@marcan.st> <41c6882a-bff0-378c-edd3-160b54be7c1d@marcan.st> From: Krzysztof Kozlowski In-Reply-To: <41c6882a-bff0-378c-edd3-160b54be7c1d@marcan.st> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On 29/11/2022 15:00, Hector Martin wrote: > On 29/11/2022 20.36, Ulf Hansson wrote: >> On Mon, 28 Nov 2022 at 15:29, Hector Martin wrote: >>> +examples: >>> + - | >>> + // This example shows a single CPU per domain and 2 domains, >>> + // with two p-states per domain. >>> + // Shipping hardware has 2-4 CPUs per domain and 2-6 domains. >>> + cpus { >>> + #address-cells = <2>; >>> + #size-cells = <0>; >>> + >>> + cpu@0 { >>> + compatible = "apple,icestorm"; >>> + device_type = "cpu"; >>> + reg = <0x0 0x0>; >>> + operating-points-v2 = <&ecluster_opp>; >> >> To me, it looks like the operating-points-v2 phandle better belongs in >> the performance-domains provider node. I mean, isn't the OPPs really a >> description of the performance-domain provider? >> >> That said, I suggest we try to extend the generic performance-domain >> binding [1] with an "operating-points-v2". In that way, we should >> instead be able to reference it from this binding. >> >> In fact, that would be very similar to what already exists for the >> generic power-domain binding [2]. I think it would be rather nice to >> follow a similar pattern for the performance-domain binding. > > While I agree with the technical rationale and the proposed approach > being better in principle... > > We're at v5 of bikeshedding this trivial driver's DT binding, and the > comment could've been made at v3. To quote IRC just now: > >> this way the machines will be obsolete before things are fully upstreamed > > I think it's long overdue for the kernel community to take a deep look > at itself and its development and review process, because it is quite > honestly insane how pathologically inefficient it is compared to, > basically, every other large and healthy open source project of similar > or even greater impact and scope. > > Cc Linus, because this is for your Mac and I assume you care. We're at > v5 here for this silly driver. Meanwhile, rmk recently threw the towel > on upstreaming macsmc for us. We're trying, and I'll keep trying because > I actually get paid (by very generous donors) to do this, but if I > weren't I'd have given up a long time ago. And while I won't give up, I > can't deny this situation affects my morale and willingness to keep > pushing on upstreaming on a regular basis. > > Meanwhile, OpenBSD has been *shipping* full M1 support for a while now > in official release images (and since Linux is the source of truth for > DT bindings, every time we re-bikeshed it we break their users because > they, quite reasonably, aren't interested in waiting for us Linux > slowpokes to figure it out first). > > Please, let's introspect about this for a moment. Something is deeply > broken if people with 25+ years being an arch maintainer can't get a If arch maintainer sends patches which does not build (make dt_binding_check), then what do you exactly expect? Accept them just because it is 25+ years of experience or a maintainer? So we have difference processes - for beginners code should compile. For experienced people, it does not have to build because otherwise they will get discouraged? > 700-line mfd driver upstreamed before giving up. I don't know how we > expect to ever get a Rust GPU driver merged if it takes 6+ versions to > upstream the world's easiest cpufreq hardware. While I understand your point about bikeschedding, but I think your previous bindings got pretty nice and fast reviews, so using examples of non-building case is poor choice. Best regards, Krzysztof