Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp2529876pxb; Fri, 17 Sep 2021 11:54:25 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx8lCvDqoufpbJ8NBb9M/eNLMMxO0h3INALNMYout10ZVF9ChNu/c6/kvDPcIWfCZVwKsEO X-Received: by 2002:aa7:c5d5:: with SMTP id h21mr14237500eds.233.1631904865103; Fri, 17 Sep 2021 11:54:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1631904865; cv=none; d=google.com; s=arc-20160816; b=C2TCl+0sNpprGThx9AVGALVUDG78Ie/swzyuu64t7ggojCjcfDNcoWe+MdfDGKsfTH bQyL6LAShNj9VOTLmYy4qQ3D2Yr8OROgWfvwNqT7zROjmDPnN4Su+uCNz3GkY51cAini 45VcPJZd/5/V+GDkKrTDN74DAmglnObWb9bUz6tlHOFjPMOmukkMOPsZfUmPMAZEuEzp 5L1trq+IEa4s5LgONnT9rUvvgLefuJIoCvImCvtlJ/Ei5Jtwpnm4qu7ZH4TdnhfzRxP2 ALEpQ4+/IeIeALbAG5madr6Flahmnhp4WjfuHU9oySl4sjn+jKmLnHTjzGGx5FW6G3KJ gmEA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=MZ6qaAK1Jzdhzj7IsoucdmHU5eSJRp4I5FtVX2CzJXQ=; b=XUPYkayBpYH5XallhL4xeon8sSGvjX+MZoJbxK91zqXA63GoXUatEEr6T6fYP3vVSz QH4xCMkccc1/UiRkBFVJdqD7lVNSnhncgb+W+ReB1xAOhnbODq6BshYj2bL1FXFZvkt9 kyRzOcExr4QmBs+lv2VJlvOVNHuGvMlKZIod1dypxF6Er6+nz42/wiZPu5MGUt+f7E0D jDi4OmMiQOHrGxRmDzMhl5QAq8iSqvU6lROb0f3+QqJ/8DXt66VrgPLwekaz++u7iTaX LH75M0VM8lPPd+K7w/pyyS7b34SQBHFmtyWSqhrR9IwQzr2wO1rYEb+OygmM+YuNvEJ7 mC/Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=marcan.st Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id d3si981392edm.263.2021.09.17.11.54.01; Fri, 17 Sep 2021 11:54:25 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=marcan.st Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343743AbhIQKoQ (ORCPT + 99 others); Fri, 17 Sep 2021 06:44:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40632 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231364AbhIQKoP (ORCPT ); Fri, 17 Sep 2021 06:44:15 -0400 Received: from mail.marcansoft.com (marcansoft.com [IPv6:2a01:298:fe:f::2]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 35A32C061574; Fri, 17 Sep 2021 03:42:53 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: marcan@marcan.st) by mail.marcansoft.com (Postfix) with ESMTPSA id 3658541E57; Fri, 17 Sep 2021 10:42:46 +0000 (UTC) Subject: Re: [PATCH v3 04/10] PCI: apple: Add initial hardware bring-up To: Marc Zyngier , Sven Peter Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org, Bjorn Helgaas , Rob Herring , Lorenzo Pieralisi , =?UTF-8?Q?Krzysztof_Wilczy=c5=84ski?= , Alyssa Rosenzweig , Stan Skowronek , Mark Kettenis , Robin Murphy , kernel-team@android.com References: <20210913182550.264165-1-maz@kernel.org> <20210913182550.264165-5-maz@kernel.org> <6eb53661-e11e-4634-9fa5-5e7e62d57a15@www.fastmail.com> <87lf3vblt6.wl-maz@kernel.org> From: Hector Martin Message-ID: <9cf94456-d7ab-ac2b-fb12-019e40424793@marcan.st> Date: Fri, 17 Sep 2021 19:42:44 +0900 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <87lf3vblt6.wl-maz@kernel.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: es-ES Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 17/09/2021 18.20, Marc Zyngier wrote: > On Mon, 13 Sep 2021 21:48:47 +0100, >> On Mon, Sep 13, 2021, at 20:25, Marc Zyngier wrote: >>> +static inline void rmwl(u32 clr, u32 set, void __iomem *addr) >>> +{ >>> + writel_relaxed((readl_relaxed(addr) & ~clr) | set, addr); >>> +} >> >> This helper is a bit strange, especially since it's always only used >> with either clr != 0 or set != 0 but never (clr = 0 and set = 0) afaict. >> Maybe create two instead for setting and clearing bits? > > That's indeed nicer, and it makes the code more readable. This seems to be a pattern in Corellium code; the cpufreq code is the same and I honestly found it quite hard to read when used for simple set or clear operations. I find set32/clear32 style helpers much more readable, so it's probably a good idea to make this change any time we upstream stuff derived from their tree. -- Hector Martin (marcan@marcan.st) Public Key: https://mrcn.st/pub