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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 826C2C4321E for ; Tue, 29 Nov 2022 14:35:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To: Subject:MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=rkOH3Fe8iHiXhpx7BBkbcj70BwRJdWpKf9qXNxDCChI=; b=IIqFH0Cl4qHZV3 DyJegAMmzKiyljNgDMdn8XrS+R4zGDuXyzQt8msqSlOct/GHAh/ErPtVAX06dh85XO68upVPbKXqQ bnAr8tEpD+CSQFJ0/BJhrgglSSnK6XVCEqghAqI5GQ69mAI3mbLjNZlpfDjpfw9bfCUrOn9Mb53rR 9PxuBKNm902PpojYNAZcoH32IGiz1jMFYuvr2e2TBIse8DcXVXjIhNaGhYKUhQbeXOjiq/eNmBiS4 QjoYa4PhfptdGLzAeV32ZZXUBUigi/MYkIvFoWdhyaU8oVmZF4fO2AGhco3DYS2NNfsJkxxn996rn Bt0Rza0Ox2MzWq2gHaHA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1p01gy-009IQr-4t; Tue, 29 Nov 2022 14:34:36 +0000 Received: from mail-lj1-x236.google.com ([2a00:1450:4864:20::236]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1p01gt-009INF-AE for linux-arm-kernel@lists.infradead.org; Tue, 29 Nov 2022 14:34:32 +0000 Received: by mail-lj1-x236.google.com with SMTP id h10so769540ljk.11 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=aFj3UCZBpcSZW915gvEqXQUiElWfmLqkaM29WP963lzsR3+jho8YIAW8yrd7PfK5Rp PP4RmyDPVzevDtV+O87wXTl0P2IYYUD61ycbH5meSmsh4jNsWLe2M403w9p/6V64VtZy CPMCAHZbDuIcmo/h5oYEG06mkj9J393Tvvur39aDxpEejSqyF1BJ6+ulyTKV4+5bQUnB ezHHuCSypodv9kVl1whY1K3nNnO1xqbgCAFEBue9H3YtaT6gqUe2ilfqYspsU3nyTCg3 VQaRjq85zmM+jbHJ5nC60+WhK7uO0rDMhHkm+W0V0nB45jEG+UESMP21LeYTFx+0A0r2 dnWw== X-Gm-Message-State: ANoB5pkRfdbDuMw0r8KSp2gVkvlta84Z2aMO6PXTSr//YaYOtliaR7ql GJYfJ0b29mOfMIdz/s6tL0nDvg== 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> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221129_063431_436904_4F085823 X-CRM114-Status: GOOD ( 33.43 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel