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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4E69DC4332F for ; Sun, 3 Oct 2021 22:48:33 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2AA5E61181 for ; Sun, 3 Oct 2021 22:48:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231920AbhJCWuT (ORCPT ); Sun, 3 Oct 2021 18:50:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35886 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231794AbhJCWuS (ORCPT ); Sun, 3 Oct 2021 18:50:18 -0400 Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 21FB5C061780 for ; Sun, 3 Oct 2021 15:48:30 -0700 (PDT) Received: by mail-lf1-x12b.google.com with SMTP id i4so64229885lfv.4 for ; Sun, 03 Oct 2021 15:48:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sW+crIeDmhAMH4pK5GASAaCZE8D1VZtdK5/sygrAG2k=; b=lQrEOA0euWiU9H9sWtnhFM9pj1nGUVTgMmT1inlS8kcAIcWUCFr349N1dSAz2SVqFj T7ORD7odD/G0eN6Z706ABNk23F2RpNaz9XiITGtS4a/oLqxc8vuWRXMazGo3kVH7nEhf id6efAjoCVCJj4EHeoDcPwnvEdhdrZYcay0MmicPuvWvTC2tTU4WHwu9kmjVm1V4AwTR u6HEKMibBBBYXjB040lkOfpApeYAiOmDVboF7H14zEQd2CgkvyFRV06wLTn0go2HgEcm q5Ki3D4KVSRrkUBia9z2Nc7Z2wKuTuJ7Xo21FCTQ2IL9079vG1F49SrZu+4+Y7LN8iJb jIIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sW+crIeDmhAMH4pK5GASAaCZE8D1VZtdK5/sygrAG2k=; b=hMRW7SQxljbGN4s1XtHDySs0ugcYeRaPZmgScTQ0d3K9EGpx6Nb0mCm164Pcz0RnY3 9pcGglm/57NM5o8CUsUniD53DlzIMb25XlmKaWU2tSy4xfY5NPmENfoHLvD5T1F3QOFx ZuyO8qYXQ4ExXgoH3fyUc5J3saKkUCwqGm72Yp998pQhp6okjyo9EVxVaa9MU8kp+OO3 7x0CNQXfC5yd6Ho6BvvOFqGZ06eNmGefCXRS/bZI10Huj74TxuRu+D1P8yBdwp28OJvu l1jEzlHyV3eBCbqgJAlvxFfESZkPHyFuvUi7auQ2WC4N+IByBc82s9uYbX3ddY23VXXp tjxA== X-Gm-Message-State: AOAM533IfYzYX3eBClDWLqZcnkQJbNpty6/b5aOm/I4xpnFOxbC4tsPt IThwMqw6VdesTtqdCmfW44wk6Wv/dTh/XB8+Dhnmdg== X-Google-Smtp-Source: ABdhPJwlIO3xJmMne7SA3V9EP6o49YZWJtcqreYaPVZa30sqz5Vxc/CuLZ5GbJ4uqeokuIsg0281gvTYxIzcMfCsea0= X-Received: by 2002:a2e:4e11:: with SMTP id c17mr11819356ljb.19.1633301308432; Sun, 03 Oct 2021 15:48:28 -0700 (PDT) MIME-Version: 1.0 References: <20210607123317.3242031-1-robert.marko@sartura.hr> <20210607123317.3242031-5-robert.marko@sartura.hr> <20210713222528.GA952399@robh.at.kernel.org> <20210719225906.GA2769608@robh.at.kernel.org> In-Reply-To: From: Linus Walleij Date: Mon, 4 Oct 2021 00:48:17 +0200 Message-ID: Subject: Re: [PATCH v6 5/6] dt-bindings: mfd: Add Delta TN48M CPLD drivers bindings To: Robert Marko Cc: Rob Herring , Bartosz Golaszewski , Lee Jones , Philipp Zabel , "open list:GPIO SUBSYSTEM" , devicetree , Linux Kernel Mailing List , Luka Perkov , jmp@epiphyte.org, Paul Menzel , Donald Buczek Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Robert, sorry for slow reply, I am a bit busy. On Tue, Aug 24, 2021 at 10:03 AM Robert Marko wrote: > On Wed, Aug 11, 2021 at 2:17 PM Linus Walleij wrote: > > > > On Tue, Aug 3, 2021 at 9:23 PM Robert Marko wrote: > > > > > The pins that this driver wants to expose are used for SFP-s only, > > > they are provided by the Lattice CPLD which also does other things. > > > > > > Linux has a generic SFP driver which is used to manage these SFP > > > ports, but it only supports GPIO-s, it has no concept of anything else. > > > Since the driver is fully generic, I have no idea how could one extend it > > > to effectively handle these pins internally, especially since I have more > > > switches that use the CPLD for SFP-s as well, even for 48 ports and 192 > > > pins for them. > > > > Which file is this driver in so I can look? > > Hi Linus, > Sorry for the late reply. > > Sure, here is the generic Linux driver that is used for SFP handling: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/phy/sfp.c?h=v5.14-rc7 So this has this: enum { GPIO_MODDEF0, GPIO_LOS, GPIO_TX_FAULT, GPIO_TX_DISABLE, GPIO_RATE_SELECT, GPIO_MAX, SFP_F_PRESENT = BIT(GPIO_MODDEF0), SFP_F_LOS = BIT(GPIO_LOS), SFP_F_TX_FAULT = BIT(GPIO_TX_FAULT), SFP_F_TX_DISABLE = BIT(GPIO_TX_DISABLE), SFP_F_RATE_SELECT = BIT(GPIO_RATE_SELECT), SFP_E_INSERT = 0, SFP_E_REMOVE, This does not look general purpose to me at all? It's just some hardware engineer that thougt "GPIO" was a nice thing to call this. > > Maybe it is not a good idea to look for generic code just because > > it is convenient? I have had this problem before with GPIO, along > > the lines "lemme just do this dirty thing this one time because it > > is so convenient for me" (more or less) and the answer is still > > "no". > > > > Can you either augment the driver to handle a regmap with bit indices > > instead or write a new similar driver for that or refactor it some other > > way? > > > > It is not a simple solution to your problem, but it might be the right > > solution even if it means some more work. > > I understand your position, believe me, I spend some time looking at > what would be the logical way for these switches. > But I see no way how could the SFP driver be extended in a generic way > that would allow supporting different register layouts when it comes to pins. Why do you think you have to use the GPIO abstraction and bindings? Just invent something that satisfy your needs, the bindings are just strings. Why does the consumer have to use the GPIO binding? They can just use phandle named anything. Some "sfp-foo-resource = <&...> or so. For example I created this: Documentation/devicetree/bindings/firmware/intel,ixp4xx-network-processing-engine.yaml It's handling out a resource using a phandle. Nothing different than GPIO, regulator, clock etc. Just invent something for SFP? Yours, Linus Walleij