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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

Linus,

can I offer some further explanation?

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



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



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux