From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f44.google.com (mail-wr1-f44.google.com [209.85.221.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 19CBA45D5D0 for ; Fri, 7 Aug 2026 13:08:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786108129; cv=none; b=YdwEIgttZYqETEOOa+mArxVhCM1NTTxXPPJae6fdaXK1MDnjtscjDoH1lqaWFaKa83qHoaL5rH8GoSzmUQ7PoZoYs1GyuF1YSzmYZPFqAM0+McxmihCHrl0bgzeYWrklBQnlWXVZgh8opNxw+Grv34uakME+9X0RhPIA1nI+vYE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786108129; c=relaxed/simple; bh=r6tQKNJBJLBKkcU905VTnz7Q+CMwMCXgVwnHBoFckgg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=hmUTZc5hd18CpK5Abk3E2/yajhi2NY6qUEOw3AyrjfSqjYbSZl0HGpLBekSZX7azsO3GdO+T78+ERxfI09Mu0X35sF69h5tdtT8kyeg++tKMwJPshpEjRMmQGj1CVkYrO56leYrn2diIWFK2jTEKOqzNpjhI0nBz0vo02H2a1BI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=S7Kfyaii; arc=none smtp.client-ip=209.85.221.44 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="S7Kfyaii" Received: by mail-wr1-f44.google.com with SMTP id ffacd0b85a97d-47f96c5b722so2105375f8f.0 for ; Fri, 07 Aug 2026 06:08:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786108110; x=1786712910; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=XjfEMCqkZ88kBIhDMMBN1abXLKDzKlzUH+bF7MfZKwc=; b=S7KfyaiirenYUOFITRX99IME3D0ku4natSq9tXJIJjizw5lVdOvMCU0wnzFoD8d2yJ xEOcT+YtCAnyI9f51PiS/z7qZ6NTs8Cgf5vkwz9no6/2Vgu0OWMntB0PtNRgJ8qs1btk k/wT9QdhEKxfzDuPGYKw1prJd3wf3y7bkXSFDjZVswIVGO70ECPQ3MsnvjftUUyAj7nH 8G+X0oIvlla9aJRpypOeQ7RqGOO5Z2emvmzWLhb2MA0BZHVtySEtfkUeRzskQ/XWFBNT cwBR/hvevPbfYKjUIZa3ngVMVl7c+OIewJM6paD/GEcna2pDEV99Py07iG/dH+MHdJ3l BH4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786108110; x=1786712910; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=XjfEMCqkZ88kBIhDMMBN1abXLKDzKlzUH+bF7MfZKwc=; b=kASe2LYq/WD0eiq4zYSlj+R9Oxozrf06uElAJNS4+EmyEcfDYMYr8yeMr+D/xME41V 60fCFj1hktTp+tfBLaMCpvQ0nODuFSuAsi6oFZ2QqTe12RqmsDPHKuw46/je2HHq9zfF +68beqyAz2/ZP+06cpbOG8Kbl9CievzRP2Rk2SzwLCmPwmEL5nc0Z3BJlZkJh+eJsFDJ scSPnjwi7vuLV2UiLPEXl2a55bf08nqI8R2UXkc3j9zriihK4oYbbF4nw8onQPLeJFtO 7jcOI0rC4N1BaevYzKLEQYIZ4W48bBXrmUH0i39qPMsN5ZFfuc40X4BnKRKVeMXUYJCx /XVQ== X-Forwarded-Encrypted: i=1; AHgh+Rr4MiADW1e0RaW+ll+gs5Al48RtJvi8CFYb59ReNQO0QunACc79f51+mKyeFsxnjYJHGrQHGkb88Xtg/GI=@vger.kernel.org X-Gm-Message-State: AOJu0YzAxQv6gWLFbplAcHq6hKUaCMaiL29/zJVhbyX07OaPZtIFbDTu W4wvBVH4iwYxlsujBYO66kez+AZXrb4Wq1OoqrZmpOlp+9A2mpTVzWoc X-Gm-Gg: AR+sD10lSQp8b3b7lBKFY8X5lu/ejbPmFJwkHUKFQQ3sFLU29Bf1u2WPpN4Zhtj1Xee K9qau6UPajj6lWH9vvZRddAiD9rL/lZ0e7gIH6EDBfQgyOzBilLveUc9wYVf0rn/6wRpmmSn7/m lxtCSqUuEzZGoDBp38ssYgrx/F35lpsb0iYJaTU6Qto4aI3dH7RB78Hwa0VPbmOmDV0+i3EMbEL vFHbUsnDrFyJ/BP1/9lJhuDr9vfaP8BUOcZQsO817XRttHpQmdLfPx182rFLO2RkOF6MnqCFB8u anSPNyUx8cOEgn0AvU2OcX7LpB+yKV0nouL8b02Xa51izQHIuG92+vmzbywiwHkdleJiFVB1ux7 tCUwc0auxZnI0sDO6pY5zLy5EuVLdh9zqs+f7FHnAByoh5U3Pr/t+ajm9LxpvM1BN9jIrleWVfS khufW4k5d3HTyalf22Pczo5h1Ne21FaHglwH2gQVahFe0FGdEuKlSXgugw X-Received: by 2002:a5d:50c2:0:b0:47f:8e50:9411 with SMTP id ffacd0b85a97d-47fec52acc2mr26764789f8f.20.1786108110319; Fri, 07 Aug 2026 06:08:30 -0700 (PDT) Received: from localhost ([2c0f:3d00:6be:8900:ce5e:9212:ea4b:f30]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-480021501bcsm5754365f8f.9.2026.08.07.06.08.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 07 Aug 2026 06:08:29 -0700 (PDT) Date: Fri, 7 Aug 2026 16:08:26 +0300 From: Dan Carpenter To: Nam Cao Cc: sh_def@163.com, andy@kernel.org, gregkh@linuxfoundation.org, dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org, linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org, thomas.petazzoni@free-electrons.com, notro@tronnes.org Subject: Re: [PATCH] staging: fbtft: make dirty_lock IRQ-safe Message-ID: References: <20260804173712.176017-1-sh_def@163.com> <87pkzu852x.fsf@yellow.woof> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87pkzu852x.fsf@yellow.woof> On Fri, Aug 07, 2026 at 02:53:26PM +0200, Nam Cao wrote: > sh_def@163.com writes: > > diff --git a/drivers/staging/fbtft/fbtft-core.c b/drivers/staging/fbtft/fbtft-core.c > > index ca0c38221c16..193643d0329d 100644 > > --- a/drivers/staging/fbtft/fbtft-core.c > > +++ b/drivers/staging/fbtft/fbtft-core.c > > @@ -298,14 +298,20 @@ static void fbtft_mkdirty(struct fb_info *info, int y, int height) > > { > > struct fbtft_par *par = info->par; > > struct fb_deferred_io *fbdefio = info->fbdefio; > > + unsigned long flags; > > > > /* Mark display lines/area as dirty */ > > - spin_lock(&par->dirty_lock); > > + /* > > + * fbcon takes dirty_lock while holding console_owner. Disable local > > + * interrupts here so a printk hardirq cannot acquire console_owner > > + * while dirty_lock is held and create the inverse lock ordering. > > + */ > > Beside that reason, we also need spin_lock_irqsave() because > fbtft_mkdirty() can be called in both task context and hardirq > context. And this reason alone suffices and usually is why > spin_lock_irqsave() is used, so I think a comment is not necessary. > > But I am fine with it either way. AI always adds comments. If we keep alowing obvious comments, the kernel will turn into reading the Terms and Conditions which are impossible to read in a single human life time. regards, dan carpenter