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 X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 315E5C433ED for ; Tue, 20 Apr 2021 15:19:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E0F1361154 for ; Tue, 20 Apr 2021 15:19:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232450AbhDTPTl (ORCPT ); Tue, 20 Apr 2021 11:19:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34246 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232901AbhDTPTk (ORCPT ); Tue, 20 Apr 2021 11:19:40 -0400 Received: from thorn.bewilderbeest.net (thorn.bewilderbeest.net [IPv6:2605:2700:0:5::4713:9cab]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 745F9C06174A; Tue, 20 Apr 2021 08:19:07 -0700 (PDT) Received: from hatter.bewilderbeest.net (unknown [IPv6:2600:6c44:7f:ba20::7c6]) (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 1925421B; Tue, 20 Apr 2021 08:19:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bewilderbeest.net; s=thorn; t=1618931946; bh=oQsjsO0Yl4yjifxeL/OMKHJvvkUd/jcIQKwEeqW7BDA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Rgqiz1wtPfW54DSKSL8gCSziB2bmtE2CHeyGWJk1RuLk7ibMPtNNu7Bt2PHu3+c8Z ZOuCiZcBM/zHQK256DVdxfxB5ykkIbES9HH5dRcI1T4STN3KcU/1oPvc69wQVO3pFg ndAZyKi+o0BH+U87lPpQNYnVXAJubvSV0sr06DyE= Date: Tue, 20 Apr 2021 10:19:04 -0500 From: Zev Weiss To: Guenter Roeck Cc: Mark Brown , Jean Delvare , linux-hwmon@vger.kernel.org, Andrew Jeffery , Liam Girdwood , linux-kernel@vger.kernel.org, openbmc@lists.ozlabs.org Subject: Re: Enabling pmbus power control Message-ID: References: <20210330174221.GJ4976@sirena.org.uk> <20210330180200.GK4976@sirena.org.uk> <20210330193810.GA235990@roeck-us.net> <20210420033648.GA227111@roeck-us.net> <9639fa33-01ca-9802-e745-5e3edb81e305@roeck-us.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-hwmon@vger.kernel.org On Tue, Apr 20, 2021 at 05:52:16AM CDT, Guenter Roeck wrote: >On 4/20/21 12:06 AM, Zev Weiss wrote: >> On Tue, Apr 20, 2021 at 01:00:25AM CDT, Guenter Roeck wrote: >>> On 4/19/21 10:50 PM, Zev Weiss wrote: >>> [ ... ] >>> >>>> I had a glance at the enclosure driver; it looks pretty geared toward SES-like things (drivers/scsi/ses.c being its only usage I can see in the kernel at the moment) and while it could perhaps be pressed into working for this it seems like it would probably drag in a fair amount of boilerplate and result in a somewhat gratuitously confusing driver arrangement (calling the things involved in the cases we're looking at "enclosures" seems like a bit of a stretch). >>>> >>>> As an alternative, would something like the patch below be more along the lines of what you're suggesting?  And if so, would it make sense to generalize it into something like 'pmbus-switch.c' and add a PMBUS_HAVE_POWERSWITCH functionality bit or similar in the pmbus code instead of hardcoding it for only LM25066 support? >>>> >>>> >>> >>> No. Don't access pmbus functions from outside drivers/hwmon/pmbus. >>> >>> I used to be opposed to function export restrictions (aka export namespaces), >>> but you are making a good case that we need to introduce them for pmbus >>> functions. >>> >>> Guenter >> >> Okay -- I figured that was likely to be frowned upon, but the alternative seemed to be effectively duplicating non-trivial chunks of the pmbus code.  However, upon realizing that the LM25066 doesn't actually require any of the paging work the generic pmbus code provides, I suppose it can actually be done with a simple smbus read & write.  Does this version look better? >> > >It is just getting worse and worse. You are re-implementing regulator >support for the lm25066. The correct solution would be to implement >regulator support in the lm25066 and use it from the secondary driver >(which should be chip independent). > >Guenter > Implementing it by way of regulator support seems like it would make sense, but that in turn sounds like it would then end up just being a reimplementation of REGULATOR_USERSPACE_CONSUMER, which (unless there was some more subtle distinction that I missed) Mark already told me in no uncertain terms is not the way to go. So I hope I could be forgiven for feeling a bit stuck here. Mark, do you have any further input on what a viable approach might look like? Thanks, Zev