On Mon, Oct 4, 2021 at 12:48 AM Linus Walleij [off-list ref] wrote:

Hi Robert,

sorry for slow reply, I am a bit busy.

On Tue, Aug 24, 2021 at 10:03 AM Robert Marko [off-list ref] wrote:

quoted

On Wed, Aug 11, 2021 at 2:17 PM Linus Walleij [off-list ref] wrote:

quoted

On Tue, Aug 3, 2021 at 9:23 PM Robert Marko [off-list ref] wrote:

quoted

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.

quoted

quoted

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@sartura.hr
Web: www.sartura.hr