Message-ID: <CA+HBbNHZyYnnyz9=4Hgav96ZH8-R-nYoi300j2x3fgei8aa4zQ@mail.gmail.com>
Date:   Tue, 24 Aug 2021 10:03:01 +0200
From:   Robert Marko <robert.marko@...tura.hr>
To:     Linus Walleij <linus.walleij@...aro.org>
Cc:     Rob Herring <robh@...nel.org>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>,
        Lee Jones <lee.jones@...aro.org>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        devicetree <devicetree@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Luka Perkov <luka.perkov@...tura.hr>, jmp@...phyte.org,
        Paul Menzel <pmenzel@...gen.mpg.de>,
        Donald Buczek <buczek@...gen.mpg.de>
Subject: Re: [PATCH v6 5/6] dt-bindings: mfd: Add Delta TN48M CPLD drivers bindings

On Wed, Aug 11, 2021 at 2:17 PM Linus Walleij <linus.walleij@...aro.org> wrote:
>
> On Tue, Aug 3, 2021 at 9:23 PM Robert Marko <robert.marko@...tura.hr> 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

>
> 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.

>
> > GPIO regmap works perfectly for this as its generic enough to cover all of
> > these cases.
>
> Yeah but it might be the wrong thing to do even if it is simple
> to use and works.
>
> > CPLD also provides pins to test the port LED-s per color as well,
> > but I have chosen not to expose them so far.
>
> Have you considered
> Documentation/devicetree/bindings/leds/register-bit-led.txt

Yeah, but unfortunately in this case it wont work as the LED-s
are for debugging/test purposes only and you first need to switch
the CPLD out of it interpreting the LED state with a BIT flip.

Regards,
Robert
>
> > > If it is a regmap in Linux then that is fine, just pass the regmap
> > > around inside the kernel, OK finished. But really that is an OS
> > > detail.
> >
> > Yes, its regmap but I cant really pass it to the SFP driver as I don't have
> > special driver handling the SFP but rather the generic kernel one.
> > It only knows how to handle GPIO-s.
>
> Of course you have to program it. If I know which driver it
> is it is easier to provide architecture ideas.
>
> Yours,
> Linus Walleij



-- 
Robert Marko
Staff Embedded Linux Engineer
Sartura Ltd.
Lendavska ulica 16a
10000 Zagreb, Croatia
Email: robert.marko@...tura.hr
Web: www.sartura.hr

Powered by blists - more mailing lists