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 AB604C64EC4 for ; Fri, 10 Mar 2023 07:56:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230057AbjCJH46 (ORCPT ); Fri, 10 Mar 2023 02:56:58 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36626 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229929AbjCJH45 (ORCPT ); Fri, 10 Mar 2023 02:56:57 -0500 Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2C02FDDF28 for ; Thu, 9 Mar 2023 23:56:53 -0800 (PST) Received: by mail-ed1-x52a.google.com with SMTP id x3so16943349edb.10 for ; Thu, 09 Mar 2023 23:56:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1678435011; 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=Na4vhlLIT8h87R1c4saJtnoc0rpStTN6SAaJv5Ui0DU=; b=f/cdum7O6TN5gJ9ROGgx6QjE0oljMSgdfelOxJDv/A44aZ7Mm1unTj43LMrAl8qXD3 sHI50PXnWoUWOCaGf+Lw7NcDVU4NiPijijYupEKrMb/i7yVzAFSIs2Sdxro3W9NWDoHv l0FZKC3iXGb6IU9h1xEP+L1xj0TStwEsdmZgH7BeJN1yxjzdFSB6oJFobXTUS45dVs0M ULQH07khMas1d0aBIt/OjZLOHVTDe9lhbsnUreYNdh+WszcP/mDLVMMeWmaL4KFGK0LG +5HnCCB4hC8JohJPmZdM8SSKIi+lKSrrSUXogyHzjsDGs1U97Mara0hXF/7LevUFdWY9 OvCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678435011; 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=Na4vhlLIT8h87R1c4saJtnoc0rpStTN6SAaJv5Ui0DU=; b=tlnn/jZBxOfwEhybDQmdoOi19s7kesXV+QJ19ZF+5BmuLHt8Zkk27+LMZf4ZwZaBYO zBIOZ79o6UrTJCYpTzCbnkD+LfmH3sBXx+KpZTxIHDLSG9YU1eb/i4Q3JgEigm50qo/T 1Qwgjf9LZBatJfYE7UXgQDN5QOy3mf6lOJ4cPPI7C8/++8hNO/5JK5SV14PHmeqjr9qN letfeEM/geFjePkjEGzQIqybDfncuBNxn99H2mmixva94+FeHnMWy5BaJqN0E+HY6bX9 /pFLBD92D1lLAMKRqWQ5qLZ4lYPpJxomb3niRGKg0XSxTYxiA+EhgZZntPZsoQmETw6x FXew== X-Gm-Message-State: AO0yUKXOLB3uuCtqIN9mqmEs24j3unDQCt90yzo/JpT3sSMuVUm0L+Y9 Vnc0gLBhx0Ct6uG1MpYwNcESmw== X-Google-Smtp-Source: AK7set83ouw7MBm0jqo5iH57IkMFwoOVUzIry7zQggJ4hxcJBeN03UC69xrHLWNGpiqGw+nvqtrohA== X-Received: by 2002:a17:906:eecc:b0:90b:167e:3050 with SMTP id wu12-20020a170906eecc00b0090b167e3050mr30865633ejb.36.1678435011591; Thu, 09 Mar 2023 23:56:51 -0800 (PST) Received: from [192.168.1.195] ([5.133.47.210]) by smtp.googlemail.com with ESMTPSA id ox11-20020a170907100b00b008cf6f8798e1sm641097ejb.54.2023.03.09.23.56.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 09 Mar 2023 23:56:50 -0800 (PST) Message-ID: <6108c68b-e38b-3060-f6fa-53be79a795d7@linaro.org> Date: Fri, 10 Mar 2023 07:56:49 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 Subject: Re: [PATCH v1 01/15] dt-bindings: add pwrseq device tree bindings Content-Language: en-US To: Dmitry Baryshkov , Rob Herring Cc: Andy Gross , Bjorn Andersson , Ulf Hansson , Marcel Holtmann , Johan Hedberg , Luiz Augusto von Dentz , Kalle Valo , "David S. Miller" , Jakub Kicinski , Stanimir Varbanov , linux-arm-msm , linux-mmc , "linux-kernel@vger.kernel.org" , "open list:BLUETOOTH DRIVERS" , ath10k@lists.infradead.org, linux-wireless , netdev , Abel Vesa References: <20211006035407.1147909-1-dmitry.baryshkov@linaro.org> <20211006035407.1147909-2-dmitry.baryshkov@linaro.org> <37b26090-945f-1e17-f6ab-52552a4b6d89@linaro.org> <31792ef1-20b0-b801-23b7-29f303b91def@linaro.org> From: Srinivas Kandagatla In-Reply-To: <31792ef1-20b0-b801-23b7-29f303b91def@linaro.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org On 02/11/2021 15:26, Dmitry Baryshkov wrote: > On 28/10/2021 00:53, Rob Herring wrote: >> On Tue, Oct 26, 2021 at 9:42 AM Dmitry Baryshkov >> wrote: >>> >>> On 26/10/2021 15:53, Rob Herring wrote: >>>> On Wed, Oct 06, 2021 at 06:53:53AM +0300, Dmitry Baryshkov wrote: >>>>> Add device tree bindings for the new power sequencer subsystem. >>>>> Consumers would reference pwrseq nodes using "foo-pwrseq" properties. >>>>> Providers would use '#pwrseq-cells' property to declare the amount of >>>>> cells in the pwrseq specifier. >>>> >>>> Please use get_maintainers.pl. >>>> >>>> This is not a pattern I want to encourage, so NAK on a common binding. >>> >>> >>> Could you please spend a few more words, describing what is not >>> encouraged? The whole foo-subsys/#subsys-cells structure? >> >> No, that's generally how common provider/consumer style bindings work. >> >>> Or just specifying the common binding? >> >> If we could do it again, I would not have mmc pwrseq binding. The >> properties belong in the device's node. So don't generalize the mmc >> pwrseq binding. >> >> It's a kernel problem if the firmware says there's a device on a >> 'discoverable' bus and the kernel can't discover it. I know you have >> the added complication of a device with 2 interfaces, but please, >> let's solve one problem at a time. Just to keep this topic updated with some pointers [1] to changes done to solve same problem in USB Hub. These patches (drivers/usb/misc/onboard_usb_hub*) have been merged since last year July. It looks like we can take some inspiration from this to address PCIE Bus issue aswell. Thanks to Neil to point this. [1] https://lore.kernel.org/lkml/20220630193530.2608178-1-mka@chromium.org/T/ --srini > > The PCI bus handling is a separate topic for now (as you have seen from > the clearly WIP patches targeting just testing of qca6390's wifi part). > > For me there are three parts of the device: > - power regulator / device embedded power domain. > - WiFi > - Bluetooth > > With the power regulator being a complex and a bit nasty beast. It has > several regulators beneath, which have to be powered up in a proper way. > Next platforms might bring additional requirements common to both WiFi > and BT parts (like having additional clocks, etc). It is externally > controlled (after providing power to it you have to tell, which part of > the chip is required by pulling up the WiFi and/or BT enable GPIOs. > > Having to duplicate this information in BT and WiFi cases results in > non-aligned bindings (with WiFi and BT parts using different set of > properties and different property names) and non-algined drivers (so the > result of the powerup would depend on the order of drivers probing). > > So far I still suppose that having a single separate entity controlling > the powerup of such chips is the right thing to do. > > I'd prefer to use the power-domain bindings (as the idea seems to be > aligned here), but as the power-domain is used for the in-chip power > domains, we had to invent the pwrseq name. >