From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) (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 93ADD375F99 for ; Thu, 9 Jul 2026 14:31:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.180.131 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783607467; cv=none; b=NgILAl/BeSbCJIZqVfD8dsT0Pb7FF006r6AE6DPsqt8RboJ6tQjqJ8hOoojIZgmFt5nNHU5yZz8pJapVGY8ZFTxo3IjrQvANcz5v4BH1lqPsfj5Gy9mY7f2bplKw44ZEVxB6z+3XooD9xDcCi7HxCKEGNAqvz4cdd8+9h8cAwY0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783607467; c=relaxed/simple; bh=i9/EKS5uKSvES1Tz51c9OT6jblP9O4HysVJ1cI/QaN0=; h=Message-ID:Date:MIME-Version:From:Subject:To:Cc:References: In-Reply-To:Content-Type; b=PEilV0OIDDNTU8PHAuoq1RpZMMfxFNDznGck02EfeBGse/TWkK0O4ZAeSFP+PVsXwtHmm45xzleH6KIg0TFumb39vgR2tjKNnEqRQtSBpVlox0TYS+OQVS2CCujF2X1gACEOywq5KCFPNrdyldG/fzO5ezSaP6pSr7KLmwZvzsM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com; spf=pass smtp.mailfrom=oss.qualcomm.com; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b=irKXSLf3; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=Q7LqCalP; arc=none smtp.client-ip=205.220.180.131 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b="irKXSLf3"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="Q7LqCalP" Received: from pps.filterd (m0279872.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 669DwCo11833851 for ; Thu, 9 Jul 2026 14:31:04 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualcomm.com; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=qcppdkim1; bh= i1G7QVGepIEM0CWelKqH3jpucBlcr1CGjsJZXsT1zto=; b=irKXSLf3JBrnMOim 1gm/OU/wrhtN6T4fsUHL0TBQupKbTUNfWjdpnt5qyWJRrAG51K45kw4XDNhbDe/j 6Bit7ZV7ZL1FkeN//hoJ/mg9H0xBBAUTScZuc0EkZEP15KSR2gMtfYoTUthvipm7 MXXIMB9heJvoZIHuo+mcuV7/OCrtMvI9+Ov2LhsY0CQyyQtQGul7BbuM2/Nwzx8k cDCmUregGRj8u/LntYKAlJUCbp0fHc7oLEnHuhxwQ3DV6BXvaAJGbRLxfumL4sZF 7M42umOhaQ3P4DS6RVXkq5F8wnWGYdbVFdU2/5930pMhJs256eA8IYPvCmN8iYQq 050+hg== Received: from mail-ua1-f70.google.com (mail-ua1-f70.google.com [209.85.222.70]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4f9wwfuq4d-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Thu, 09 Jul 2026 14:31:04 +0000 (GMT) Received: by mail-ua1-f70.google.com with SMTP id a1e0cc1a2514c-96939fcd33dso438888241.1 for ; Thu, 09 Jul 2026 07:31:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1783607464; x=1784212264; darn=vger.kernel.org; h=content-transfer-encoding:content-type:in-reply-to:content-language :references:cc:to:subject:from:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to:content-type; bh=i1G7QVGepIEM0CWelKqH3jpucBlcr1CGjsJZXsT1zto=; b=Q7LqCalPGG8SYmTb5eRH5zqOctPG0qPaBRY7yg8oNgUFJ4g3dE7s/rrvf30Pgv1UXn TQ9z8VYAMA5wr2RWkcWnqLHd1kNU9EJG74ifL3aQQMkrjXNRzDa0BT9Pg6IhquSsLcDj wSrP4iFKfgUAi85hzDElyb0tfIsCNn0goQAJWvNq7vQkgsylX7Rrlfzf371tRfvk1TNq BF2lIfcqbghSX+DlUZ8NW2YmZ2EAI8umf9amhFNsyD3MUtjoFib8nZbCWP0Kor1gT/Ke fD2uTxIau+RFPAjJd3RtKU+ZNHhsi5QvUuuv8DWdgNnaXvWACQiHc4q7ODhcjQI35Vuz YoDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783607464; x=1784212264; h=content-transfer-encoding:content-type:in-reply-to:content-language :references:cc:to:subject:from:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=i1G7QVGepIEM0CWelKqH3jpucBlcr1CGjsJZXsT1zto=; b=pOTHIlmfrnOIMG2AMcCLy8fCzRv0+BCwaDAdXCZVhnNZ/4k3ilf+nnVqU2g/Sq4qlz bEEXSWHFBBm8koPLUfab3nUt/sLRdN00NifItjlSqLnGeZRjp4lnTBGCeXAlt6MrYaNP P3l/cIlWeLYSm0H7Wkucvf6JpJi7XmSFRXVqGYpIqb8NbMZ5Tbqc/RAbGIcaQxupQtNI xucY3w4eSSrHYG88p0FmeRTC68IzHItTa+RBtm0+KQHLSHsWrBBKgUM+UhdqdFGF0fqH 3NIdlrpiF5f4zFpIYCYL5ORIc2/BWEQioZlYBsQZtgaiym833Iv9y+2oSCy+BvYVFHWo wFpQ== X-Forwarded-Encrypted: i=1; AHgh+RqjnYf3/m9Q6MhAQcosZDlyBR3Oepg+XlFVtWuND/ua7xMyz9xpFlLWke4U0zQMo4H8GrXLmYuXlGWx64g=@vger.kernel.org X-Gm-Message-State: AOJu0YwlREQIuTzWlEq15ye8IHYWU1LJs/j56oRsYfch51lZpby825tY iFEMHbNtzD4X/h8bVWsgXraNStKcQYBNfKBvmZqeKarAK8ZKmwxZl4LmhBGxi4+jfzxwhdjSRB1 nn5iJ18IuBRk8kd2VBQe2soOIgnkGsvWpcGMLC2/4y8CSB3id2bDng+Rp1KW9y0JoF6A= X-Gm-Gg: AfdE7ckQP21uhroaeqVuNnOOzBgLXVTn+6956PaBt6yrEP2z1cSGZ8/yeC/kVkJ+cY+ MlOUllQrAzWTYXjOzhjduAKcqLmJKvvVCFxZ/O4717rFEqvOL2KbsDxM0DtVJj2Q6Pl9WyMhrGA o8IlhZVJJlK3b+JHviPo6HiccBU33e6jjtNDEUH4L8/xm12oA8gl+cebs8aguV3MJWOqwcE4/c6 d82S3KnjE7Td8NfMZ5hvqHOQcXTFmLyRIfOR8vtzxmptb61UQseUa6QMRM1etUTild4t1DflmYK 8Tuo8HbN590COKICmHdIXCpeFoK1oe8SpY7Xx7Oh4klzKCCINOvg9KsA8RsnV3e0Rbwz/PLcXDX sGfVRSfeVQK0qUqlNajefMreEjq68XEabug//SU3OXcIWPOOi2sBkqPa5KbJ1tXgaAe6jkgqv7W OqXnzeSxT02c6pcFuH674lO+5lHctSpICrudzEjx1oZCF1tsahBRp7+o0TYrGeJ/eX3ugyUbkhD u+2qA== X-Received: by 2002:a05:6102:549e:b0:744:cb59:d6e0 with SMTP id ada2fe7eead31-744dfbf6041mr4475515137.0.1783607463694; Thu, 09 Jul 2026 07:31:03 -0700 (PDT) X-Received: by 2002:a05:6102:549e:b0:744:cb59:d6e0 with SMTP id ada2fe7eead31-744dfbf6041mr4475388137.0.1783607462573; Thu, 09 Jul 2026 07:31:02 -0700 (PDT) Received: from ?IPV6:2001:1c00:c32:7800:5bfa:a036:83f0:f9ec? (2001-1c00-0c32-7800-5bfa-a036-83f0-f9ec.cable.dynamic.v6.ziggo.nl. [2001:1c00:c32:7800:5bfa:a036:83f0:f9ec]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c15ad694736sm489092666b.0.2026.07.09.07.31.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 09 Jul 2026 07:31:01 -0700 (PDT) Message-ID: <5fb236b7-7b99-40fb-b80b-fa7e1dfccd70@oss.qualcomm.com> Date: Thu, 9 Jul 2026 16:31:00 +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 From: Hans de Goede Subject: Re: [PATCH v2 0/2] firmware: arm_scmi: Ensure automatic module loading To: Sudeep Holla Cc: Brian Masney , Bjorn Andersson , Cristian Marussi , Nathan Chancellor , Nicolas Schier , Michael Turquette , arm-scmi@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-kbuild@vger.kernel.org, Stephen Boyd , "Rafael J. Wysocki" , Viresh Kumar , Frank Li , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , Guenter Roeck , Jyoti Bhayana , Jonathan Cameron , David Lechner , =?UTF-8?Q?Nuno_S=C3=A1?= , Andy Shevchenko , Dmitry Torokhov , Ulf Hansson , Liam Girdwood , Mark Brown , Philipp Zabel , Alexandre Belloni , linux-clk@vger.kernel.org, linux-pm@vger.kernel.org, imx@lists.linux.dev, linux-hwmon@vger.kernel.org, linux-iio@vger.kernel.org, linux-input@vger.kernel.org, linux-rtc@vger.kernel.org References: <20260618-scmi-modalias-v2-0-8c7547c1be21@oss.qualcomm.com> <8c2a4ae3-95cc-489a-a7a4-90a3ee2597e9@oss.qualcomm.com> <20260709-spicy-fiery-squid-6eec1d@sudeepholla> <20260709-exuberant-galago-of-spirit-1c908f@sudeepholla> Content-Language: en-US, nl In-Reply-To: <20260709-exuberant-galago-of-spirit-1c908f@sudeepholla> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwNzA5MDE0MyBTYWx0ZWRfXxH6w3lTz1Rjw h9wpseoYUXlQ3YW2NFoGWcoT/r6GWxoeoSm6dmdWd0sxzvh4UAy+LSj0KC/SuIUKUDhsRAZ5zP7 BTa9bMW3y+998YY3VrRcMq+P5SwAtEwuwGf4IU1MSdBw1cImeTQhN9k2xlEjPRKCvstRKroVL7e QjWFdxii6KwanmtzAmmyqrIIrMjkO/zxdllBgDNUifBPLuAQeOODBWX01xattj+1U4B6JVyEKLq aWenjIX1cITKyEYrVXjSVYdmYBOxkOEb8VSV69aSosB4S4HN4gwws4w3nG/RKOcvwgJxDd+gHE0 EQf+Ne0HB6G0nVLbqy/2PAa6pp9pmArY5cuRtXKw7kyO0iqDOb+Xij2khtPZjRXmvYLcMG+XfTU MRjyfSD9DO4a5rTlflhHIdZdjatSB/wFVdRFFm5yjEDWEJCuBuTHk7m0SCBVhiEzZB5CzCO4/ki FRQM+vNbZH3CzXZ05Ng== X-Proofpoint-Spam-Info: AW1haW4tMjYwNzA5MDE0MyBTYWx0ZWRfX/j0b6Or8NiTV nJyX7KY2R6V7uS6+Z412Ob4M8avGMznbM3h/24ssKn+lSl6SrcxYWFWaFJwxXZ4h8a6nW+k5ckx Qku+BK8UNsOcyNNQIIOY5M2SNd96hdc= X-Proofpoint-ORIG-GUID: TbhZjvykqbqgia6y5m8BCrWv8lDiLYbT X-Proofpoint-GUID: TbhZjvykqbqgia6y5m8BCrWv8lDiLYbT X-Authority-Analysis: v=2.4 cv=Krh9H2WN c=1 sm=1 tr=0 ts=6a4fb0a8 cx=c_pps a=R6oCqFB+Yf/t2GF8e0/dFg==:117 a=xqWC_Br6kY4A:10 a=IkcTkHD0fZMA:10 a=RAioF0-LDSMA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=yx91gb_oNiZeI1HMLzn7:22 a=1Iq74HBXAAAA:20 a=EUspDBNiAAAA:8 a=OLQ1oTztZwe7u39PbcAA:9 a=QEXdDO2ut3YA:10 a=TD8TdBvy0hsOASGTdmB-:22 a=bA3UWDv6hWIuX7UZL3qL:22 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-07-09_03,2026-07-09_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1015 phishscore=0 priorityscore=1501 impostorscore=0 lowpriorityscore=0 adultscore=0 spamscore=0 suspectscore=0 bulkscore=0 malwarescore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2607090143 Hi, On 9-Jul-26 16:21, Sudeep Holla wrote: > On Thu, Jul 09, 2026 at 04:07:17PM +0200, Hans de Goede wrote: >> Hi Brian, >> >> On 9-Jul-26 15:28, Brian Masney wrote: >>> Hi Hans, >>> >>> On Thu, Jul 09, 2026 at 03:22:29PM +0200, Hans de Goede wrote: >>>> On 9-Jul-26 12:10, Sudeep Holla wrote: >>>>> On Thu, Jun 18, 2026 at 10:31:12PM +0200, Hans de Goede wrote: >>>>>> On 18-Jun-26 17:56, Bjorn Andersson wrote: >>>>>>> SCMI drivers such as the Arm SCMI CPUfreq driver are allowed to built as >>>>>>> modules, but they are then not automatically loaded. Rework the SCMI >>>>>>> device table alias support to make modpost consume the information from >>>>>>> MODULE_DEVICE_TABLE(scmi, ...) and allow drivers to be loaded based on >>>>>>> this information, if known. Also add a protocol-based alias to also >>>>>>> trigger driver loading when only the SCMI protocol id is known. >>>>>>> >>>>>>> Signed-off-by: Bjorn Andersson >>>>>> >>>>>> So I just gave this a test spin and unfortunately it does not work. >>>>>> >>>>>> The problem with Fedora's kernel-config / setup is that the >>>>>> request_module() from patch 2/2 runs from the initramfs, but >>>>>> the scmi_cpufreq module is only available in the rootfs. >>>>>> >>>>>> It does work if I explictly add the scmi_cpufreq module to >>>>>> the initramfs, then it does get autoloaded. >>>>>> >>>>>> We really need some place to put a uevent sysfs attr which then >>>>>> gets replayed when udev is restarted from the rootfs and then >>>>>> re-reads all the uevent files as part of its coldplug >>>>>> enumeration. >>>>>> >>>>> >>>>> I don't have much knowledge on uevent to provide any suggestions/help. >>>>> But isn't this a generic requirement ? I mean you could have modules >>>>> install on the rootfs and not all of them are packed in initramfs ? >>>>> Just wondering if that works for other modules, we can examine how >>>>> do they work and what are we missing ? >>>> >>>> scmi is special because the actual devices under /sys/bus/scmi/devices >>>> only get created when the module with the driver is loaded because >>>> of some funtion/id mapping requiring info from the driver. >>>> >>>> Patch 2/2 tries to work around this by loading all scmi drivers matching >>>> the scmi protocol which is known at bus enumeration time, but this only >>>> works if the actual scmi driver is in the initramfs because this done >>>> through directly calling modprobe() from the kernel which does not >>>> get "replayed" when switching to the real rootfs. >>> >>> Should the SCMI drivers be added to the dracut module here? >>> >>> https://github.com/dracut-ng/dracut/blob/main/modules.d/70kernel-modules/module-setup.sh#L73 >>> >>> A few years ago we had to add the interconnect drivers to the list for >>> Fedora. >> >> That would be one solution. I first want to understand the problem better >> though. The scmi bus not creating the devices until the kmod with the driver >> has loaded is weird. > > I need to recall why we moved from static list of devices to dynamic. > One reason I can think right now is the vendor protocols and their drivers > But in general it was an attempt to help multiple drivers bind to different > scmi_devices that have same protocol ID. E.g. the performance protocol > can be used by cpufreq and devfreq/performance genpd drivers. Note it is ok to have multiple drivers bind to the same modalias, depending on the reason why there are multiple drivers either one should detect that it is not compatible and exit probe() with -ENODEV or there should be some other mechanism to make sure only one driver loads. E.g. duplicate USB device-ids happen (they shouldn't but they do) and then the drivers typically figure out if they are talking to the device which they were written for, or the other device with the same USB-ids and then one of the 2 drivers exits with -ENODEV. >> I wonder if we can just move a small part of the drivers >> (some mapping table) into the bus code and then just have this work as it >> does on regular busses. I hope to be able to make some time to look into >> this soonish. >> > > I started with that few years ago and we then moved to this dynamic > device creation. But I agree if it is deviation from the norms(which I > wasn't aware of at the time), we can remove it. Looking at the issue this is causing for automatic module loading if we can get back to the bus enumeration code always creating a device without waiting for the driver kmod to load then that would be good IMHO. Regards, Hans