From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by ash.osuosl.org (Postfix) with ESMTP id B42001BF3DF for ; Sat, 24 Nov 2018 07:38:48 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id B0A78815E8 for ; Sat, 24 Nov 2018 07:38:48 +0000 (UTC) Received: from whitealder.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kp8nCgIM-Asd for ; Sat, 24 Nov 2018 07:38:47 +0000 (UTC) Received: from mail-ot1-f66.google.com (mail-ot1-f66.google.com [209.85.210.66]) by whitealder.osuosl.org (Postfix) with ESMTPS id A0BDF815E3 for ; Sat, 24 Nov 2018 07:38:47 +0000 (UTC) Received: by mail-ot1-f66.google.com with SMTP id t5so12422172otk.1 for ; Fri, 23 Nov 2018 23:38:47 -0800 (PST) MIME-Version: 1.0 References: <1541328599-18396-1-git-send-email-sergio.paracuellos@gmail.com> <20181111193552.GA17578@kroah.com> <87zhufuwcl.fsf@notabene.neil.brown.name> <20181112054444.GA16266@foobar> <87lg5j9vgq.fsf@notabene.neil.brown.name> In-Reply-To: <87lg5j9vgq.fsf@notabene.neil.brown.name> From: Sergio Paracuellos Date: Sat, 24 Nov 2018 08:38:35 +0100 Message-ID: Subject: Re: [PATCH v6 00/33] staging: mt7621-pci: Parse ports info from DT and other minor cleanups List-Id: Linux Driver Project Developer List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: driverdev-devel-bounces@linuxdriverproject.org Sender: "devel" To: NeilBrown Cc: Greg KH , driverdev-devel@linuxdriverproject.org On Sat, Nov 24, 2018 at 1:21 AM NeilBrown wrote: > > On Mon, Nov 12 2018, Sergio Paracuellos wrote: > > > On Mon, Nov 12, 2018 at 08:40:10AM +1100, NeilBrown wrote: > >> On Sun, Nov 11 2018, Greg KH wrote: > >> > >> > On Sun, Nov 04, 2018 at 11:49:26AM +0100, Sergio Paracuellos wrote: > >> >> This patch series parse remaining port info from device tree storing > >> >> it in mt7621_pcie_port struct created for this. It also performs a lot > >> >> of cleanups to get the driver in a good shape to give it a try to get > >> >> mainlined. All of this changes are only compile-tested. > >> > > >> > Given the lack of responses here, I guess I'll just merge this and see > >> > what happens :) > >> > >> Sounds like a good plan. > >> I had meant to look at it this past weekend, but ran out of time. > >> It is a bit awkward for me to test on mainline at the moment as > >> > >> # first bad commit: [f8c55dc6e828324fc58c0bb32d72a5a4041d1c3b] MIPS: use generic dma noncoherent ops for simple noncoherent platforms > >> > >> breaks mmc on my hardware, and my root filesystem is on mmc. > >> > >> But I should still be able to get it tested sometime in the next couple > >> of weeks, and will provide feedback once I have it. > > > > Thanks, Neil. Please, let me know if I can help in any way. > > I've got all the way to the end of the series and with the fixes that > I've already posted, my device still works. > There are lots of nice clean-ups in there - thanks! I didn't review > them very closely as I was mostly focused on testing but what I saw > generally looked nice. Thanks for your effort in reviewing and testing this series. There were a bit long and with lots of changes and cleanups. > > For the clock issue, I would just make a missing driver non-fatal. > clk_enable() is a no-op on ralink-mips, and I'm not sure that > clk_prepare does much either. Do you mean just remove clocks from bindings and its clk_* references in code? > > Handling the reset issue is a bit harder. > It seems that most bits in the reset register are > 1=assert 0=deassert > but that on some chips, the three PCI reset lines are inverted. > It would be easiest to put a quirk in arch/mips/ralink/reset.c > to check the CHIP_REV for the three lines and invert. I'll see how to achieve this issue. Is it ok to submit the patch to staging if I add a quirk in the mainlined reset.c file? Include linux-mips mail list in the CC is enough? > > It might be cleaner to add some information to devicetree, but I cannot > easily find any precedent for that. > > BTW, rather than calling > reset_control_deassert(port->pcie_rst); > reset_control_assert(port->pcie_rst); > > maybe we should > reset_control_reset(port->pcie_rst); > and not worry about a delay. I'll also check this. > > Are you OK to submit patches to address the various issues that I found? I'll do my best to try to fix this up. > > Thanks a lot, > NeilBrown Best regards, Sergio Paracuellos _______________________________________________ devel mailing list devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel