From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx.nabladev.com (mx.nabladev.com [178.251.229.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 378491547C0; Sat, 18 Apr 2026 16:46:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=178.251.229.89 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776530818; cv=none; b=GnhiN77PM7C5pFVjLUrxERz7m0upknaid8HtoZdo+zaF7zN9KEkgQN2+oocA1z+rbi/jSNLQYGELgbhiYsSHxddufkiW7VOjC15cOT40K3zSEZfiwuHQHg1N/B2nyZBBMC0DuWvHbsnwt1hTZrrWLymI+vgwhlioJvBUEXmmziU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776530818; c=relaxed/simple; bh=79g8Cj0aVvxyvk8Zpsm1NfOTZskgvZcrJiNve829PM0=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=XG/puPEZonEJMrN3FmotVXaYse28fLQjODVPxSIh5wwCdJoYW8e7hkoQn2UPWSACY5wsg3Z15N2x2E43O1SB85KciJl8+nuuMOkLAK0dKr9/VJ4ycEQjunwrXwUPlnHUOk73uwDdTNRkUwXaNVleymvz0sP2Pdbai5qu18ETjpg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=nabladev.com; spf=pass smtp.mailfrom=nabladev.com; dkim=pass (2048-bit key) header.d=nabladev.com header.i=@nabladev.com header.b=Cgqvm8Fj; arc=none smtp.client-ip=178.251.229.89 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=nabladev.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=nabladev.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=nabladev.com header.i=@nabladev.com header.b="Cgqvm8Fj" Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id D11B31143A3; Sat, 18 Apr 2026 18:46:44 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nabladev.com; s=dkim; t=1776530807; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:content-language:in-reply-to:references; bh=jwxsjqC6odbloW4RnZUq7a7489g9YY4pbiBKr6i/Ls4=; b=Cgqvm8Fj4anJr5bp47idXk4Lz9yQ3o5gIgyoLoav2L2hhUvyYqzLZy9SlJ1OmyYO+svfdO xD7OQyb5jC0klVf4qw6eT9sigJa3lesqJHSlhjLK7J1bcZ7yBNT2ZLH6x/XUjD+VrAu431 R0lhBQ7/+I8dSKhmDPb3pml/aDRBVcjYcXPBhew8+49hb/ldb7wBpYlbKVfMuernFgLneR 3VI9gLj5heKhAItCecOIi+GkKXWIXZN3ChG2js/Mr9KbGCzuVzhEHoymmSuQb6rhGyCqP6 R6PaoWTrCvirYF3OeL5lMOX0U9ick9zMNkuG+fhlR8DXnwzo9WneYemxFyBSaw== Message-ID: Date: Sat, 18 Apr 2026 18:46:44 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [net,PATCH v3 1/2] net: ks8851: Reinstate disabling of BHs around IRQ handler To: Sebastian Andrzej Siewior Cc: netdev@vger.kernel.org, stable@vger.kernel.org, "David S. Miller" , Andrew Lunn , Eric Dumazet , Jakub Kicinski , Nicolai Buchwitz , Paolo Abeni , Ronald Wahl , Yicong Hui , linux-kernel@vger.kernel.org References: <20260414103327.113500-1-marex@nabladev.com> <20260414125753.Im6GAIHn@linutronix.de> <2fcfb84f-69f6-493e-94d6-95d85d8000f6@nabladev.com> <20260414145218.lsNpdAJI@linutronix.de> <7734527a-d08b-49fa-b258-c37c5ae2da55@nabladev.com> <20260416062159.fPxqc52X@linutronix.de> <20260416104818._EDbo9hA@linutronix.de> Content-Language: en-US From: Marek Vasut In-Reply-To: <20260416104818._EDbo9hA@linutronix.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Last-TLS-Session-Version: TLSv1.3 On 4/16/26 12:48 PM, Sebastian Andrzej Siewior wrote: > On 2026-04-16 11:26:00 [+0200], Marek Vasut wrote: >>> memory allocation. Therefore I am saying this backtrace is from an older >>> kernel. >> >> I actually did update the backtrace in V3 with the one from next 20260413 >> that contained b44596ffe1b4 ("ARM: Allow to enable RT") from >> stable-rt/v6.12-rt-rebase branch [1] . >> >> I think I misunderstood the usage of "softirq is raised" vs. "softirq is >> invoked" above . Is it possible that there was an already raised softirq >> before the threaded IRQ handler was invoked, and __netdev_alloc_skb() is >> what invoked that softirq ? > > It is not impossible. Something needs to netif_wake_queue() and > ks8851_irq() must only report IRQ_RXI (not IRQ_TXI). Then it can happen. > But usually the driver "stops" the queue if it can't process any new > packets and resumes it once a packet has been sent so it has room again. This driver .start_xmit is very simple, if there is space in the 6 kiB TX FIFO, then the packet is written into it, otherwise the .start_xmit returns NETDEV_TX_BUSY . There does not seem to be any netif_{start,stop,wake}_queue() in the .start_xmit path.