From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (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 7434F29A9 for ; Tue, 31 Dec 2024 15:34:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1735659282; cv=none; b=Ru+jU9uOtaOY2CQH7m/mZKwVmingtPIHK+2nPuVa0YP+lxcDJ5E+hM9n4BotrV+SXC6ianhh9Es20XHPC7VuGbD7G6EZT6vTa6ky89Og/V/D79d7xjxL/HyKfAwxnUYIg+Oog8hxanE1GUCmPi62orHvFZuof9ixnlr6wnJcxms= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1735659282; c=relaxed/simple; bh=78FMzw7FA37kVai4hezN1ZvY6tVEedmYQb9EANyS2xM=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=pLKnQicLDjYaSjl3ICdW13t379YwvnLcaIh6eA37nxc8Pqwa6OiyYbUiLEkuRw5G84WECx8uiex8kXsITAvp7zxb0Ic5wUJVecNEyl50KiUiWlayll/9olKNVuLFrDp5uuotmm4b/pF6N/eQ4TNVlrgZjR7eSvUKQXJm7VV+t9c= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=h0IxTvBu; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="h0IxTvBu" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1735659279; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=tmEjGEm1qqJclDuwwxfz/LXp5iHfy6EB/oyyHkg1LM0=; b=h0IxTvBulVWoR2bKIYzNLSAg7MymA7+myXFcvO4bl0oLvvVtyaF9TFeOgJ+IsL5UCGO/RR AMUkCcE5mla+VGAlv8VR4sOFsjJw15vgUItjPhlnI4RryaiShg2SCiZ6jYa/ZaaK09l+91 tloYDWy8Ag7b1mm0auLOG+UsVPlINvQ= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-297-6_C5FnArO-qJKoSAjVSzEw-1; Tue, 31 Dec 2024 10:34:38 -0500 X-MC-Unique: 6_C5FnArO-qJKoSAjVSzEw-1 X-Mimecast-MFC-AGG-ID: 6_C5FnArO-qJKoSAjVSzEw Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-4361d4e8359so78835765e9.3 for ; Tue, 31 Dec 2024 07:34:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735659277; x=1736264077; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=tmEjGEm1qqJclDuwwxfz/LXp5iHfy6EB/oyyHkg1LM0=; b=rWeRNICCuhUuiRKsEWxyO35/A2s3/zBfMa08+7DThRLUc1hC36wQM/wNZ1mQ1xiHIg RHxDUtu640zHdbF+uhGaFwP2vLhea0M5yD7eIWi6oh6BCaDxikjBIJ4WEXawai3UB49j j2Z2ya0RNTCmIIxgkZPLjcGCR1IIRlUg0UiaAQf3zI6vh5OP37gRT8uYWfOE1OyiOzJn kdHCp1yakF/sS/VVZDih2QYuQUrXVIO3bgxgR8Zln5S0eTkO+eL84q+ocKtEAuQMIxzz por+kb04nlf8jDeU6i7gssJi8vdhwdxQcd7Ji4YGeJUBzJstJyV/D9+ffoFhtxObtGpA kXhw== X-Gm-Message-State: AOJu0YyJe8MMnmZOmsnAaJCTRBT80jn9UIVlECwQbi7653WizaEQFyX9 xPI9cC2+28ok9g03xEFNwX97jOWmBph2pWN8fmxV+rhEGzVKLApcZ17XQ6ZfjiAuh3lSluDlWNb LUXlC2Xw+vmepE5dGuYXIfQYs9jUakyahIxobxKVKpB3/2LA4rWest1DtdDGaHQ== X-Gm-Gg: ASbGncup8TTmwySPoJ1SpWUFw+hiYJjhDAuoYQFx/XHh/B6pG+gI7xLYN1WSJpbniFp vqLqrfLxodr2/cs3UuKuZv6ch/OM9Qn010Y8ka73VlUDV7qrvH393utds67PymJLHw2CRjRNi36 BTQ6pg5FU26x0xGNKuHRc/A/ukMr2/NC1iyBTx31JYN4/+YQ9UahVMlNltk3svL8Tg8wR4B06+o 8Y44L3OuHPLbr9D14v5K6sVoKSN2Ww1jnCmmLiiqIYd5QF6r275Y8LdUiw88Rp5N68krGNi5Kb7 aG3RwZvsYwtR/3l21B8CkBjUiy8cbaNQT9vwot0= X-Received: by 2002:a05:600c:1c9f:b0:435:32e:8270 with SMTP id 5b1f17b1804b1-43668642f9dmr333672025e9.14.1735659276710; Tue, 31 Dec 2024 07:34:36 -0800 (PST) X-Google-Smtp-Source: AGHT+IG57ftpliFy4dkSMDQZZqJ3i+cFxIRMiXgo6LlmWrA0RD280HM2gTGmvzxIoyDtNbaErbk63g== X-Received: by 2002:a05:600c:1c9f:b0:435:32e:8270 with SMTP id 5b1f17b1804b1-43668642f9dmr333671815e9.14.1735659276343; Tue, 31 Dec 2024 07:34:36 -0800 (PST) Received: from localhost (62-151-111-63.jazzfree.ya.com. [62.151.111.63]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-38a1c828cc8sm32991575f8f.17.2024.12.31.07.34.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 31 Dec 2024 07:34:35 -0800 (PST) From: Javier Martinez Canillas To: Dmitry Baryshkov Cc: linux-kernel@vger.kernel.org, Mark Brown , David Airlie , Maarten Lankhorst , Maxime Ripard , Simona Vetter , Thomas Zimmermann , dri-devel@lists.freedesktop.org Subject: Re: [PATCH] drm/ssd130x: Set SPI .id_table to prevent an SPI core warning In-Reply-To: References: <20241231114516.2063201-1-javierm@redhat.com> Date: Tue, 31 Dec 2024 16:34:34 +0100 Message-ID: <877c7fkgs5.fsf@minerva.mail-host-address-is-not-set> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain Dmitry Baryshkov writes: Hello Dmitry, > On Tue, Dec 31, 2024 at 12:44:58PM +0100, Javier Martinez Canillas wrote: >> The only reason for the ssd130x-spi driver to have an spi_device_id table >> is that the SPI core always reports an "spi:" MODALIAS, even when the SPI >> device has been registered via a Device Tree Blob. >> >> Without spi_device_id table information in the module's metadata, module >> autoloading would not work because there won't be an alias that matches >> the MODALIAS reported by the SPI core. >> >> This spi_device_id table is not needed for device matching though, since >> the of_device_id table is always used in this case. For this reason, the >> struct spi_driver .id_table field is currently not set in the SPI driver. >> >> Because the spi_device_id table is always required for module autoloading, >> the SPI core checks during driver registration that both an of_device_id >> table and a spi_device_id table are present and that they contain the same >> entries for all the SPI devices. >> >> Not setting the .id_table field in the driver then confuses the core and >> leads to the following warning when the ssd130x-spi driver is registered: >> >> [ 41.091198] SPI driver ssd130x-spi has no spi_device_id for sinowealth,sh1106 >> [ 41.098614] SPI driver ssd130x-spi has no spi_device_id for solomon,ssd1305 >> [ 41.105862] SPI driver ssd130x-spi has no spi_device_id for solomon,ssd1306 >> [ 41.113062] SPI driver ssd130x-spi has no spi_device_id for solomon,ssd1307 >> [ 41.120247] SPI driver ssd130x-spi has no spi_device_id for solomon,ssd1309 >> [ 41.127449] SPI driver ssd130x-spi has no spi_device_id for solomon,ssd1322 >> [ 41.134627] SPI driver ssd130x-spi has no spi_device_id for solomon,ssd1325 >> [ 41.141784] SPI driver ssd130x-spi has no spi_device_id for solomon,ssd1327 >> [ 41.149021] SPI driver ssd130x-spi has no spi_device_id for solomon,ssd1331 >> >> To prevent the warning, set the .id_table even though it's not necessary. >> >> Since the check is done even for built-in drivers, drop the condition to >> only define the ID table when the driver is built as a module. Finally, >> rename the variable to use the "_spi_id" convention used for ID tables. >> >> Signed-off-by: Javier Martinez Canillas > > Fixes: 74373977d2ca ("drm/solomon: Add SSD130x OLED displays SPI support") > I was on the fence about adding a Fixes: tag due a) the issue being there from the beginning as you pointed out and b) the warning being harmless. But I'll add it to v2 or just before pushing it to drm-misc-next. > Reviewed-by: Dmitry Baryshkov > Thanks for your review! -- Best regards, Javier Martinez Canillas Core Platforms Red Hat