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 9D162C4332F for ; Tue, 22 Nov 2022 08:00:34 +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=QcZjIlLwil6luKDSPnYJW9YCYFQpg3i3GGF57i+wz5o=; b=HLHwBdb1nI1C7Q t/1n8IRwL+JD64hPCfyILXMPE6u/VEan5Y9CUfLmo4iCsUaKJh/JlGpFjU1vrDY2lTj32Ltjfd62a 7nOV4105kN+is9Wlr1LoKjYzlawLMuVlp+54bEjL3eWrZeJeXGbUYlJDetWZh2cGlBEb0xAgkCyBF lqCInu2vdSWySN5hCusFdh9iLelIkXNonRv62RsvftVFVOqIN0nB9nRLYWOBka0lypVa0BHlaPgWm yV4il+rBFJZCU1Tl/jDu6Adzwq5DfBsd4uIyV2t8hcXnOng47YUOeTPBilxsw7Z2I6nLDC1tYz6Ve OEhweoA6JSwo7Sx8WETw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oxOBn-00614U-Ik; Tue, 22 Nov 2022 07:59:31 +0000 Received: from mail-lf1-x12b.google.com ([2a00:1450:4864:20::12b]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oxOBk-00612x-P4 for linux-arm-kernel@lists.infradead.org; Tue, 22 Nov 2022 07:59:30 +0000 Received: by mail-lf1-x12b.google.com with SMTP id f13so869400lfa.6 for ; Mon, 21 Nov 2022 23:59:28 -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=+rHE42IRQEpvlYwnxD7VJSLOCSycuUnbcPRlGiT0VKU=; b=LpaDHiyMjzQR8FLaKdwyzVpff27TYVCfaRKzwK0kUx3JMZmRxWEClaCfEnPyuwZ8Ez 7+qoE9IH/LdVFqIv8jr7jfgO/Kw4YjAdg3xyZMrZzID0hcsER8U9YuK7Cxq0Hv3IPxqM yr9qr4okK75m/wpxI9ahqrP+Hs7YGVwZ4LF/Op/2VUbXwv3RsnATf7CmdBq8TTQ781q3 YOZTmhSzoVzENPcxqr2IjwT2uulEPnwYAjXj5McwjPJBrnZWf7dY5E1VH+NGMDCjIfkK Y8LygON4f9I8qaf8k5rm0ciyyxQb5XFnUQBO95jU7DtC/oThJ72GmrucpalJamrgrLDn rQvQ== 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=+rHE42IRQEpvlYwnxD7VJSLOCSycuUnbcPRlGiT0VKU=; b=Qyg/u9YxkGiLm4WIv8RWaB07RPCHA3m/rTv1ixWPitqwGhW+cpv14ro4BOCt2+cIu4 Scz3FvT9iqPEEs5veXFtdlIYJVhml8I4dBMj9Zjh80GjBr+1x3+vxy5SSVV7utCS8rFp 6ARHF8IA4/FxSZ+/o+xrKdaoFpXkLSthab9baArDSxr7K2EEVBD0Cxz4gsxJK61MdnJb 8N8JM6Ix3ij9vYVSu3l0mv/6haXhu1svEHE90nc16NVHmMErW1ccBiEYZGBUA6YJgfi4 6IRzX0oLPdCD0FYzwEjuAb64DlcUp44wgbtxMdRu32ObCzwmYhYKR/eaV/iDnjpapwhR k1Fw== X-Gm-Message-State: ANoB5plucEHAqT86e1irdCLHekGnBdiakRWgttNZPc63NJgAWYzPxqW9 r+JESNlYcZvAcoqb/o+v7fP1NQ== X-Google-Smtp-Source: AA0mqf5576Smjd5iC86BrqdWj7qdQ3v5kGphmRORCZi8Fhqujqy/nP6bb0FfF7erLI3gpEizurjsEA== X-Received: by 2002:a05:6512:708:b0:4a2:6d30:fef2 with SMTP id b8-20020a056512070800b004a26d30fef2mr1699692lfs.324.1669103967144; Mon, 21 Nov 2022 23:59: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 l7-20020a2e7007000000b0027776efa48csm1768076ljc.91.2022.11.21.23.59.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Nov 2022 23:59:26 -0800 (PST) Message-ID: <6bb1ee6d-ab8c-824c-4a7d-29769189e4b4@linaro.org> Date: Tue, 22 Nov 2022 08:59:25 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: [PATCH 1/4] dt-bindings: mfd: nxp,bbnsm: Add binding for nxp bbnsm Content-Language: en-US To: Jacky Bai , "lee@kernel.org" , "robh+dt@kernel.org" , "krzysztof.kozlowski+dt@linaro.org" , "shawnguo@kernel.org" , "s.hauer@pengutronix.de" , "dmitry.torokhov@gmail.com" , "a.zummo@towertech.it" , "alexandre.belloni@bootlin.com" Cc: "devicetree@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-input@vger.kernel.org" , "linux-rtc@vger.kernel.org" , "kernel@pengutronix.de" , dl-linux-imx , "festevam@gmail.com" References: <20221121065144.3667658-1-ping.bai@nxp.com> <20221121065144.3667658-2-ping.bai@nxp.com> <2aeb0590-4fd0-5bb4-5e68-0378953a94c3@linaro.org> From: Krzysztof Kozlowski In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221121_235928_866649_B5D73F08 X-CRM114-Status: GOOD ( 20.46 ) 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 21/11/2022 11:26, Jacky Bai wrote: >> Subject: Re: [PATCH 1/4] dt-bindings: mfd: nxp,bbnsm: Add binding for nxp >> bbnsm >> >> On 21/11/2022 07:51, Jacky Bai wrote: >>> Add binding for NXP BBNSM(Battery-Backed Non-Secure Module). >>> >>> Signed-off-by: Jacky Bai >>> --- > > ... > >>> + >>> + properties: >>> + compatible: >>> + const: nxp,bbnsm-rtc >> >> >> Missing ref to rtc.yaml. > > Ok will include in v2. >> >>> + >>> + regmap: >> >> Use vendor prefix, descriptive name and description. Where is the type of >> 'regmap' defined? > > Type is missed. Will add a description and type define if necessary. > >> >>> + maxItems: 1 >> >> I don't think this is correct. Rob explained the simple-mfd means children > do >> not depend on anything from the parent, but taking a regmap from its > parent >> contradicts it. > > For this BBNSM module, basically, it provides two sperate & different > function: RTC and ON/OFF button control. But > no separate register offset range for each of these functions. For example, > the interrupt enable control, > Interrupt status and basic function control are mixed in the same registers' > different bit. > > Any good suggestion on how to handle such case? ^_^ The solution for more complex common parts, dedicated device driver (MFD driver) with its own binding. However I understand why it would be overshoot here. > >> >>> + >>> + interrupts: >>> + maxItems: 1 >> >> You have same interrupt and same address space used by two devices. >> >> Both arguments (depending on parent regmap, sharing interrupt) suggests >> that this is one device block, so describing it with simple-mfd is quite >> unflexible. >> > > It is depends on how SoC integrates this BBNSM module. From the BBNSM side, > it has separate IRQ lines for RTC function and ON/OFF function. Different > IRQ lines > can be used for RTC and ON/OFF button. But in current i.MX93 SoC, those > interrupts > are ORed together at SoC level. That's why same interrupt in the example. It's fine then. Best regards, Krzysztof _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel