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 206F9C83F33 for ; Thu, 31 Aug 2023 11:28:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S245512AbjHaL2J (ORCPT ); Thu, 31 Aug 2023 07:28:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60836 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242955AbjHaL2I (ORCPT ); Thu, 31 Aug 2023 07:28:08 -0400 Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 55AEFCFC for ; Thu, 31 Aug 2023 04:28:04 -0700 (PDT) Received: by mail-ej1-x632.google.com with SMTP id a640c23a62f3a-99bdeae1d0aso79073766b.1 for ; Thu, 31 Aug 2023 04:28:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fairphone.com; s=fair; t=1693481283; x=1694086083; darn=vger.kernel.org; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-transfer-encoding:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=9yvHyjPG7qUuINUCRplJZoEcbwB6qImIpL5RY/TwBK8=; b=gJPowC5T5XnE2dRfmE1HYdTrXIJUiGjy10McutUK/lhG2Hl2hrLyYC2sp5NqioJr4v aF5VY/zgu882zOxp2UY6NEGyBiVPXUXRa3rP+ZWNtKWn+e+b+hFtOgzziUNE4AG5wOTx Qvw9OP58Y5qNHW39HdGvLzNBtzDrKh9xWVUtiv1tsKe45f8yIqrFPns17Cer45bskcwo 4xcWiy7Z6lz8OfaGc+inoTw34CxFSYyweK2WUKp1lI0qy8GPpbCiG4xFEsyuU5eAOn2C LKJDMxe4ZdLjwoTvAQLXPDz6fgOLR+DLe4eJ4zjPc9+2VyexjSJuSHwj4qQgPdt3XNPe dfew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693481283; x=1694086083; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-transfer-encoding:mime-version:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=9yvHyjPG7qUuINUCRplJZoEcbwB6qImIpL5RY/TwBK8=; b=Kj2a+2GWjVUiiT5BiCSMxNbvMN/ZiO9ddXLPMiujh6MpPzShjD2mgIwngr1RTibf3w 95W4ZPFrgboUUfwnFKYI6ajGzkUmIBGU6J6Fi1hg8n+jqNiUCeEujQKnFhVlRl9n1ph6 zRBhAZTdpcRdD0oMccDcxnSicPccbA6E7feOyg+3w4shKie2h/MDbBBxx8BJhywJLvI4 IP/ozMkBxDxOaZGg+0Yu9XTd9HlLaTojPFz4Zytx4bD2YZH0nBt8htHX9V1HKwu7jVpp r63NqbxWFpcfkygZbBpTBa2gNwNiN10sliFq7CVzD0lkZ2Fdvf99gGfiwmK1LhN766Tj cdyQ== X-Gm-Message-State: AOJu0YzEtAph/FQYBUf9AFX5v4CgtClaYMf6XPItH3tJH9+I+PH6OZ40 Sf0zRWDcqZ5sDrrHY9mpOZlL5A== X-Google-Smtp-Source: AGHT+IG/hpDsEDtftxv8WRfScAb1QpBlf4Zc8+8cS6j6PB4BK2HHNwPv823nbljA1+JmHjuosy8iUw== X-Received: by 2002:a17:906:3195:b0:9a5:c49e:7145 with SMTP id 21-20020a170906319500b009a5c49e7145mr3734010ejy.69.1693481282782; Thu, 31 Aug 2023 04:28:02 -0700 (PDT) Received: from localhost (144-178-202-138.static.ef-service.nl. [144.178.202.138]) by smtp.gmail.com with ESMTPSA id r10-20020a170906c28a00b0099297782aa9sm655606ejz.49.2023.08.31.04.28.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 31 Aug 2023 04:28:02 -0700 (PDT) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Thu, 31 Aug 2023 13:28:01 +0200 Message-Id: Cc: <~postmarketos/upstreaming@lists.sr.ht>, , , , , , Subject: Re: [PATCH 03/11] arm64: dts: qcom: sc7280: Move qfprom clock to chrome-common From: "Luca Weiss" To: "Konrad Dybcio" , , "Andy Gross" , "Bjorn Andersson" , "Rob Herring" , "Krzysztof Kozlowski" , "Conor Dooley" , "Srinivas Kandagatla" , "Linus Walleij" , "Rafael J. Wysocki" , "Viresh Kumar" X-Mailer: aerc 0.15.2 References: <20230830-fp5-initial-v1-0-5a954519bbad@fairphone.com> <20230830-fp5-initial-v1-3-5a954519bbad@fairphone.com> <0ab29903-9861-4736-b827-5dd45b504baa@linaro.org> In-Reply-To: <0ab29903-9861-4736-b827-5dd45b504baa@linaro.org> Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Wed Aug 30, 2023 at 12:09 PM CEST, Konrad Dybcio wrote: > On 30.08.2023 11:58, Luca Weiss wrote: > > On non-ChromeOS boards the clock cannot be touched, so move it in the > > chrome-common dtsi which is the only place where it's needed. > >=20 > > Signed-off-by: Luca Weiss > > --- > If that clock is not registered (e.g. it's in protected-clocks =3D <>, > would the _optional handler not handle it just fine? Right, that appears to work! ~ # ls -d /sys/bus/platform/drivers/qcom,qfprom/*.efuse /sys/bus/platform/drivers/qcom,qfprom/784000.efuse ~ # cat /sys/firmware/devicetree/base/soc@0/efuse@784000/clock-names; echo core ~ # hexdump -C /sys/firmware/devicetree/base/soc@0/efuse@784000/clocks 00000000 00 00 00 03 00 00 00 b8 |........| 00000008 Never tested this case before, but since it appears to work with the patched qfprom driver (other patch in this series) I think we can drop this patch. Will also have to adjust some other patches in my local tree then that do similar things ;) Regards Luca > > Konrad