Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp3639679imm; Mon, 15 Oct 2018 01:22:24 -0700 (PDT) X-Google-Smtp-Source: ACcGV63al2RHE8VrFnVVAwuOSrwTSoX/fCspx5+/kCaakVw7346/wNNZJ6a8ttrBdwI3RqZXWDpA X-Received: by 2002:a62:6383:: with SMTP id x125-v6mr16510996pfb.13.1539591744798; Mon, 15 Oct 2018 01:22:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539591744; cv=none; d=google.com; s=arc-20160816; b=FXshzxWPHRjQEkLgpkd5OVl0+07nt5VuMmt4A5yHrQVzXrrgXUWJMcGg9/O7U5B20H sTmNrIQGTuGVEEqMcZCdHIpc8gb68VrY91vqDeoJEPUmhv+BaZaIuW8xJQBQDsxz3NrF qHgR0PsXgJK3l5UT75nik59uK1Y2oHgPz7cVjv9dGjeiGXTKly31I0Imr0CNh59DrndW DbTCSendRS8xiIxjStAHaHBOM6oueI8Jmxw64VdN1JVbS6ZgxRwPkmDcxj0qIH0Mu3o9 vsDnO3Bs3QnNzQaodQM0ihZYLqu4T85tdIpc7OJttTBJU5MXRwiGTON9TsBmNEajfFTz rjEg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:in-reply-to:date :references:subject:cc:to:from; bh=5+rdzXGp88hxSeLVYlVO3N5ZAUhm0QE9iLvBugMxb5A=; b=q4LQ9SWYvxWVU74DU+vVsl0VIcx5PbaXr64IJNPpS9dFCMWYrn4IlHJIyN+OLJyr/z dJx8BPyn3zxwXWVb4Bw3cqSTm4yyVUdDfYGipIC7fSHb96iezP+bslAGcLuPVAS7DAXM 2d2+4cSygefUa7bPmYlFphLlmwqG24Y43Se+Ot6qtEv/CkqBXRzsm1PVzgVWPswnl0Tf QebdCSijgESkQ5w99+OoBq8Z98RTHhEeJGhohSkx5rLQztw53rXxsNUAVjGrgEA8MTn+ 1Xq65vrciZK7Ybaab1DWCr7dtqPzOvYCsZfc7NbYX9NhWIQxWKR2j9M6+sfIbG3HHdu0 X3NA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r13-v6si9568911pfb.43.2018.10.15.01.22.09; Mon, 15 Oct 2018 01:22:24 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726659AbeJOQEj (ORCPT + 99 others); Mon, 15 Oct 2018 12:04:39 -0400 Received: from ni.piap.pl ([195.187.100.4]:54236 "EHLO ni.piap.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726416AbeJOQEj (ORCPT ); Mon, 15 Oct 2018 12:04:39 -0400 Received: from t19.piap.pl (OSB1819.piap.pl [10.0.9.19]) by ni.piap.pl (Postfix) with ESMTP id 52ADC442ECA; Mon, 15 Oct 2018 10:20:22 +0200 (CEST) From: khalasa@piap.pl (Krzysztof =?utf-8?Q?Ha=C5=82asa?=) To: Randy Dunlap Cc: "netdev\@vger.kernel.org" , LKML , Alan Cox Subject: Re: net/wan: hostess_sv11 + z85230 problems References: <1468d110-4f92-da7a-21b5-36afcec3c94e@infradead.org> Date: Mon, 15 Oct 2018 10:20:21 +0200 In-Reply-To: <1468d110-4f92-da7a-21b5-36afcec3c94e@infradead.org> (Randy Dunlap's message of "Sun, 14 Oct 2018 11:09:19 -0700") Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-KLMS-Rule-ID: 4 X-KLMS-Message-Action: skipped X-KLMS-AntiSpam-Status: not scanned, whitelist X-KLMS-AntiPhishing: not scanned, whitelist X-KLMS-AntiVirus: Kaspersky Security 8.0 for Linux Mail Server, version 8.0.1.721, not scanned, whitelist Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Randy Dunlap writes: > kernel 4.19-rc7, on i386, with NO wan/hdlc/hostess/z85230 hardware: > > modprobe hostess_sv11 + autoload of z85230 give: BTW Hostess SV11 is apparently an ISA card, with all those problems. > [ 3162.511877] Call Trace: > [ 3162.511877] > [ 3162.511877] dump_stack+0x58/0x7d > [ 3162.511877] register_lock_class+0x4a3/0x4b0 > [ 3162.511877] ? native_sched_clock+0x2f/0x110 > [ 3162.511877] __lock_acquire.isra.26+0x46/0x770 > [ 3162.511877] ? sched_clock+0x8/0x10 > [ 3162.511877] lock_acquire+0x5c/0x80 > [ 3162.511877] ? z8530_interrupt+0x35/0x180 [z85230] > [ 3162.511877] _raw_spin_lock+0x28/0x70 > [ 3162.511877] ? z8530_interrupt+0x35/0x180 [z85230] > [ 3162.511877] z8530_interrupt+0x35/0x180 [z85230] > [ 3162.511877] __handle_irq_event_percpu+0x35/0xe0 > [ 3162.511877] handle_irq_event_percpu+0x26/0x70 > [ 3162.511877] handle_irq_event+0x29/0x42 > [ 3162.511877] handle_fasteoi_irq+0x9b/0x170 > [ 3162.511877] ? handle_simple_irq+0x90/0x90 > [ 3162.511877] handle_irq+0xc3/0xee > [ 3162.511877] > [ 3162.511877] do_IRQ+0x51/0xe0 > [ 3162.511877] common_interrupt+0xe7/0xec Look's like something triggered an IRQ, and the z8530 driver got confused given the lack of z8530 hardware. > [ 3162.511877] EAX: 00000246 EBX: 00000246 ECX: 00000002 EDX: 00000058 > [ 3162.511877] ESI: f400d8e4 EDI: 00000000 EBP: efbf9d74 ESP: efbf9d6c > [ 3162.511877] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00000246 > [ 3162.511877] __setup_irq+0x2f0/0x620 > [ 3162.511877] request_threaded_irq+0xcd/0x170 > [ 3162.511877] init_module+0xb0/0x270 [hostess_sv11] I think the IRQ came as soon as it was requested (enabled). Now the code does: static struct z8530_dev *sv11_init(int iobase, int irq) { ... if (request_irq(irq, z8530_interrupt, 0, "Hostess SV11", sv) < 0) { pr_warn("IRQ %d already in use\n", irq); goto err_irq; } ... disable_irq(irq); and only then: if (z8530_init(sv)) { pr_err("Z8530 series device not found\n"); enable_irq(irq); goto free_dma; (including free_irq()) } Not sure about z8530 internals (driver and hw), but I guess the sv11 driver should initialize the hw first, and only then request_irq(). Perhaps there should be no "default address" either? The user would have to provide the hardware parameters explicitly. How about this (totally untested): Fix the Hostess SV11 driver trying to use the hardware before its existence is detected. Signed-off-by: Krzysztof Halasa diff --git a/drivers/net/wan/hostess_sv11.c b/drivers/net/wan/hostess_sv11.c index 4de0737fbf8a..e8808449c9e5 100644 --- a/drivers/net/wan/hostess_sv11.c +++ b/drivers/net/wan/hostess_sv11.c @@ -216,15 +216,6 @@ static struct z8530_dev *sv11_init(int iobase, int irq) outb(0, iobase + 4); /* DMA off */ - /* We want a fast IRQ for this device. Actually we'd like an even faster - IRQ ;) - This is one driver RtLinux is made for */ - - if (request_irq(irq, z8530_interrupt, 0, - "Hostess SV11", sv) < 0) { - pr_warn("IRQ %d already in use\n", irq); - goto err_irq; - } - sv->irq = irq; sv->chanA.private = sv; sv->chanA.dev = sv; @@ -246,17 +237,12 @@ static struct z8530_dev *sv11_init(int iobase, int irq) goto err_rxdma; } - /* Kill our private IRQ line the hostess can end up chattering - until the configuration is set */ - disable_irq(irq); - /* * Begin normal initialise */ if (z8530_init(sv)) { pr_err("Z8530 series device not found\n"); - enable_irq(irq); goto free_dma; } z8530_channel_load(&sv->chanB, z8530_dead_port); @@ -265,12 +251,6 @@ static struct z8530_dev *sv11_init(int iobase, int irq) else z8530_channel_load(&sv->chanA, z8530_hdlc_kilostream_85230); - enable_irq(irq); - - /* - * Now we can take the IRQ - */ - sv->chanA.netdevice = netdev = alloc_hdlcdev(sv); if (!netdev) goto free_dma; @@ -288,9 +268,21 @@ static struct z8530_dev *sv11_init(int iobase, int irq) } z8530_describe(sv, "I/O", iobase); + + /* We want a fast IRQ for this device. Actually we'd like an even faster + IRQ ;) - This is one driver RtLinux is made for */ + + if (request_irq(irq, z8530_interrupt, 0, + "Hostess SV11", sv) < 0) { + pr_warn("IRQ %d already in use\n", irq); + goto err_irq; + } + sv->active = 1; return sv; +err_irq: + unregister_hdlc_device(netdev); free_dma: if (dma == 1) free_dma(sv->chanA.rxdma); @@ -298,8 +290,6 @@ static struct z8530_dev *sv11_init(int iobase, int irq) if (dma) free_dma(sv->chanA.txdma); err_txdma: - free_irq(irq, sv); -err_irq: kfree(sv); err_kzalloc: release_region(iobase, 8); -- Krzysztof Halasa Industrial Research Institute for Automation and Measurements PIAP Al. Jerozolimskie 202, 02-486 Warsaw, Poland