Re: [PATCH 0/4] staging: mt7621-pci: Handle minor issues

2019-06-22 Thread Brett Neumeier
On Fri, Jun 21, 2019 at 7:35 AM Greg Ungerer  wrote:
>
> Hi Sergio,
>
> On 21/6/19 4:15 pm, Sergio Paracuellos wrote:
> > This patch series properly handle minor issues in this driver. These are:
> > * Disable pcie port clock on pci dirver instead of doing it in the phy
> >driver. The pci driver is the correct place to do this.
> > * Add a missing call to phy_exit function to properly handle the function
> >'mt7621_pcie_init_port' error path.
> > * Move driver to init in a later stage using 'module_init' instead of using
> >'arch_initcall'.
> >
> > Patches are only compile-tested. It would be awasome to be tested before 
> > applied
> > them (mainly the change to 'module_init' stuff).

I have similar results to Greg -- on GnuBee PC1 and PC2, six boot
attempts each on a kernel built from staging-next, I have four hangs
and eight successful boots. The hanging patterns are similar to
previous results. If the full boot logs would be helpful let me know,
I can provide them.

-- 
Brett Neumeier (bneume...@gmail.com)
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH 0/4] staging: mt7621-pci: Handle minor issues

2019-07-05 Thread Brett Neumeier
On Wed, Jun 26, 2019 at 7:45 AM Sergio Paracuellos
 wrote:
> No problem, I also miss them rewritting code. That is bad :((.
> > BTW, I applied that on top of your other recent fixes (that ones
> > you pushed to  gregkh for staging). So I tested with the
> > updated GPIO reset code.
> Ok, anyway.. I have just sent the change jus to have the same code behaviour
> that was being there before.

FWIW, I have the same results as Greg -- the 4.2 driver works every
time, staging-next frequently hangs.

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?

-- 
Brett Neumeier (bneume...@gmail.com)
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH 0/4] staging: mt7621-pci: Handle minor issues

2019-07-06 Thread Brett Neumeier
On Sat, Jul 6, 2019 at 4:00 AM Sergio Paracuellos
 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. 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?

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.

-- 
Brett Neumeier (bneume...@gmail.com)
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel