Hi Brett,
On Sat, Jul 6, 2019 at 3:43 PM Brett Neumeier <bneumeier@xxxxxxxxx> wrote:
>
> On Sat, Jul 6, 2019 at 4:00 AM Sergio Paracuellos
> <sergio.paracuellos@xxxxxxxxx> wrote:
> > > Out of curiosity, if it's not too complex an answer to go into, what's
> > > the benefit of the staging-next driver? Is there a reason to prefer it
> > > to the 4.2 driver?
> >
> > In terms of stability, the driver which is in staging-next now is not
> > always working as expected,
> > so I really apologize for that because main changes have been done by
> > myself. In the other hand,
> > you have to think what is staging tree for. Staging contains drivers
> > that are not ready to be properly
> > mainlined into the "real" tree because they are not clean enough, the
> > use old apis and so on. The idea
> > of staging is to have a temporal place to properly clean drivers in
> > order to get them properly added into
> > the official mainline tree and directories. Doing that it will always
> > be supported in the kernel and it won't be
> > deleted for the tree. The mt7621 pci driver is now clean enough to
> > give it a try to be mainlined but we have to
> > achieve the problem of pci link stability that sometimes gets the
> > driver to hang.
>
> I'm sorry, I think my question was unclear! I am not complaining about
> the instability introduced in the current driver. I understand that
> dealing with hardware is complicated and sometimes things are broken
> for a while -- especially in staging or experimental drivers. That
> doesn't bother me!
>
> I am curious, though, about the motivation for this change --
> obviously there must be some reason you rewrote the driver, but it's
> not at all clear to me.
The original driver was using legacy pci code, the 4.20 version also
have a lot of changes in order to use current generic pci apis which
is the way to go.
Just looking at the code, you can see real differences with
readability and maintainability. Those two are really important. Or at
least for me they are :)
> I see that with the staging driver it looks
> like maybe the 4.20 driver was split into the PCI controller driver
> and a separate PCI PHY driver? If that's the main architectural
> change, what's better about splitting them up that way?
Well, it really depends of the hardware. In this case in order to get
a chance to be properly mainlined (which is the main reason for making
changes in a staging driver and should be the final aim) pci phy part
and pci host controller driver seems neccessary because of how mt7621
SoC is described. There are not the only changes comparing it with the
4.20 version. With current staging version, all is properly described
using device tree instead of having hardcoded stuff which is not clean
at all (reset lines, phy, hw resources...),. The only thing is not
clear yet is that we are using pci clocks for the RC and ports because
there is not a "ralink" clock gate driver and other similar drivers
directly access to registers without using a custom clock driver for
that.
And another important thing for making this changes is because it is
fun and you learn a lot in the way :))
>
> Again, I understand that sometimes a question sounds really simple but
> the answer is long and involved, and I don't want to take up a lot of
> your time or energy. So if it is more complicated than a thirty-second
> explanation, that's cool.
No problem at all :) No time / energy consuming. I think if you are
curious is always better to ask :-).
Best regards,
Sergio Paracuellos
>
> --
> Brett Neumeier (bneumeier@xxxxxxxxx)
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
