Re: [PATCH v6 5/6] dt-bindings: mfd: Add Delta TN48M CPLD drivers bindings

[Robert Marko <robert.marko@xxxxxxxxxx>]

On Mon, Oct 4, 2021 at 12:48 AM Linus Walleij <linus.walleij@xxxxxxxxxx> wrote:
>
> Hi Robert,
>
> sorry for slow reply, I am a bit busy.
>
> On Tue, Aug 24, 2021 at 10:03 AM Robert Marko <robert.marko@xxxxxxxxxx> wrote:
> > On Wed, Aug 11, 2021 at 2:17 PM Linus Walleij <linus.walleij@xxxxxxxxxx> wrote:
> > >
> > > On Tue, Aug 3, 2021 at 9:23 PM Robert Marko <robert.marko@xxxxxxxxxx> 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.

Hi Linus.
These were historically always just regular GPIO-s, usually connected
directly to the SoC
GPIO controller or some kind of a GPIO expander and thus it uses gpiod.

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

The SFP driver requires GPIO-s, it only knows how to use GPIO-s, and
its a generic driver,
it covers any device that has an SFP port that is implemented per spec.
So, I cannot just extend it to suit my devices needs and I don't see
how can I extend it in
a generic manner so that it controls the pins directly via a regmap
for example, especially since
each switch has a different number of SFP ports and thus pins and a
different register layout.

I have added Andrew Lunn as he is one of the maintainers of PHYLIB
under which the SFP driver
is, he may have some input on how to proceed with this.

I honestly think that we have some kind of misunderstanding here and
look forward to resolving it.

Regards,
Robert

>
> Yours,
> Linus Walleij



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