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 B0B22C433EF for ; Wed, 4 May 2022 21:36:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1378816AbiEDVjk (ORCPT ); Wed, 4 May 2022 17:39:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48612 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1379266AbiEDVjO (ORCPT ); Wed, 4 May 2022 17:39:14 -0400 Received: from thorn.bewilderbeest.net (thorn.bewilderbeest.net [IPv6:2605:2700:0:5::4713:9cab]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 07117532DE; Wed, 4 May 2022 14:35:12 -0700 (PDT) Received: from hatter.bewilderbeest.net (174-21-163-222.tukw.qwest.net [174.21.163.222]) (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: zev) by thorn.bewilderbeest.net (Postfix) with ESMTPSA id 2D00F368; Wed, 4 May 2022 14:35:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bewilderbeest.net; s=thorn; t=1651700112; bh=TG2ba4y/RDwlDe7aExNpDRvQBRZU2FOjp8nvEg6cd1I=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=lugkWU3M8aQidzPUa+dHs6yMf6mvFols8gAAPjnxADbicqw7Vawf0nVlFXHAKBXIM oej/qo8TkXReRDIV5f3qpZy/xJTgR1zzWwIArKgcTxibjps/HdiiWmdyDMmeHgXhOx 0Ap6n1nxdYp9bGIwkgIA2fQ2KqdNfVf/7Aa4Bgnw= Date: Wed, 4 May 2022 14:35:08 -0700 From: Zev Weiss To: Mark Brown Cc: Liam Girdwood , Rob Herring , Krzysztof Kozlowski , linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, Greg Kroah-Hartman , openbmc@lists.ozlabs.org, MyungJoo Ham , Chanwoo Choi Subject: Re: [PATCH 2/6] dt-bindings: regulator: Add reg-external-output binding Message-ID: References: <20220504065252.6955-1-zev@bewilderbeest.net> <20220504065252.6955-2-zev@bewilderbeest.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [Adding extcon maintainers...] On Wed, May 04, 2022 at 01:49:12PM PDT, Mark Brown wrote: >On Wed, May 04, 2022 at 01:33:58PM -0700, Zev Weiss wrote: >> On Wed, May 04, 2022 at 05:55:53AM PDT, Mark Brown wrote: > >> > I think at a minimum anything like this would need some sort of >> > representation of how the output physically appears so that people can >> > work out how outputs are mapped to the hardware they see. > >> I don't quite understand what you're describing here -- could you elaborate >> on what you mean by "how the output physically appears", and what that might >> look like in a DT binding? > >For example if the output comes out on a socket then that socket should >be described. > Okay -- in the case of an Open19 power shelf like the ahe-50dc, there are 50 instances of this, 48 of which are in four ganged connectors each with 12 pairs of pins, but two of which have their own dedicated little individual sockets. The connectors are physically different, but they're all identical as far as software is concerned, so I'm not clear on why it would need to be expressed in any DT properties or the like. Or did you just mean explanatory free-form text in the description field? >> > However we >> > already have a subsystem for external connectors - extcon. Perhaps this >> > should be a regulator client in the extcon API? It's common for >> > connectors to include some sort of power provision so it seems like this >> > would fit right in. > >> Interesting -- I wasn't previously aware of the extcon subsystem, thanks for >> the pointer. However, after looking at it a bit, I'm not sure I see how >> it'd be applicable here, since it looks like it's built to handle hardware >> that's at least sophisticated enough for software to tell whether or not >> something's plugged in, which isn't the case here. The connector is just a >> ground pin and +12VDC pin, no presence-detection mechanism or anything else. >> Outside of the regulator itself there's really no "device" there for >> software to talk to or otherwise interact with at all. > >Sure, but there's no reason why it can't scale down to something >simpler. It's easier to support something simpler than have to extend >to support something more complicated. Alright, so would you suggest creating something like drivers/extcon/extcon-regulator-output.c, and just having its extcon functionality be something of a stub for now? Thanks, Zev 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 lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (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 CBAFBC433F5 for ; Wed, 4 May 2022 21:35:56 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4KtqrW2THqz3bqZ for ; Thu, 5 May 2022 07:35:55 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=bewilderbeest.net header.i=@bewilderbeest.net header.a=rsa-sha256 header.s=thorn header.b=lugkWU3M; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=bewilderbeest.net (client-ip=2605:2700:0:5::4713:9cab; helo=thorn.bewilderbeest.net; envelope-from=zev@bewilderbeest.net; receiver=) Authentication-Results: lists.ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=bewilderbeest.net header.i=@bewilderbeest.net header.a=rsa-sha256 header.s=thorn header.b=lugkWU3M; dkim-atps=neutral Received: from thorn.bewilderbeest.net (thorn.bewilderbeest.net [IPv6:2605:2700:0:5::4713:9cab]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4Ktqqk5zL2z3bbr for ; Thu, 5 May 2022 07:35:14 +1000 (AEST) Received: from hatter.bewilderbeest.net (174-21-163-222.tukw.qwest.net [174.21.163.222]) (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: zev) by thorn.bewilderbeest.net (Postfix) with ESMTPSA id 2D00F368; Wed, 4 May 2022 14:35:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bewilderbeest.net; s=thorn; t=1651700112; bh=TG2ba4y/RDwlDe7aExNpDRvQBRZU2FOjp8nvEg6cd1I=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=lugkWU3M8aQidzPUa+dHs6yMf6mvFols8gAAPjnxADbicqw7Vawf0nVlFXHAKBXIM oej/qo8TkXReRDIV5f3qpZy/xJTgR1zzWwIArKgcTxibjps/HdiiWmdyDMmeHgXhOx 0Ap6n1nxdYp9bGIwkgIA2fQ2KqdNfVf/7Aa4Bgnw= Date: Wed, 4 May 2022 14:35:08 -0700 From: Zev Weiss To: Mark Brown Subject: Re: [PATCH 2/6] dt-bindings: regulator: Add reg-external-output binding Message-ID: References: <20220504065252.6955-1-zev@bewilderbeest.net> <20220504065252.6955-2-zev@bewilderbeest.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: X-BeenThere: openbmc@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Development list for OpenBMC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: devicetree@vger.kernel.org, Greg Kroah-Hartman , openbmc@lists.ozlabs.org, Liam Girdwood , linux-kernel@vger.kernel.org, Chanwoo Choi , Rob Herring , MyungJoo Ham , Krzysztof Kozlowski Errors-To: openbmc-bounces+openbmc=archiver.kernel.org@lists.ozlabs.org Sender: "openbmc" [Adding extcon maintainers...] On Wed, May 04, 2022 at 01:49:12PM PDT, Mark Brown wrote: >On Wed, May 04, 2022 at 01:33:58PM -0700, Zev Weiss wrote: >> On Wed, May 04, 2022 at 05:55:53AM PDT, Mark Brown wrote: > >> > I think at a minimum anything like this would need some sort of >> > representation of how the output physically appears so that people can >> > work out how outputs are mapped to the hardware they see. > >> I don't quite understand what you're describing here -- could you elaborate >> on what you mean by "how the output physically appears", and what that might >> look like in a DT binding? > >For example if the output comes out on a socket then that socket should >be described. > Okay -- in the case of an Open19 power shelf like the ahe-50dc, there are 50 instances of this, 48 of which are in four ganged connectors each with 12 pairs of pins, but two of which have their own dedicated little individual sockets. The connectors are physically different, but they're all identical as far as software is concerned, so I'm not clear on why it would need to be expressed in any DT properties or the like. Or did you just mean explanatory free-form text in the description field? >> > However we >> > already have a subsystem for external connectors - extcon. Perhaps this >> > should be a regulator client in the extcon API? It's common for >> > connectors to include some sort of power provision so it seems like this >> > would fit right in. > >> Interesting -- I wasn't previously aware of the extcon subsystem, thanks for >> the pointer. However, after looking at it a bit, I'm not sure I see how >> it'd be applicable here, since it looks like it's built to handle hardware >> that's at least sophisticated enough for software to tell whether or not >> something's plugged in, which isn't the case here. The connector is just a >> ground pin and +12VDC pin, no presence-detection mechanism or anything else. >> Outside of the regulator itself there's really no "device" there for >> software to talk to or otherwise interact with at all. > >Sure, but there's no reason why it can't scale down to something >simpler. It's easier to support something simpler than have to extend >to support something more complicated. Alright, so would you suggest creating something like drivers/extcon/extcon-regulator-output.c, and just having its extcon functionality be something of a stub for now? Thanks, Zev