[{"id":3672731,"web_url":"http://patchwork.ozlabs.org/comment/3672731/","msgid":"","list_archive_url":null,"date":"2026-04-02T13:35:34","subject":"Re: [PATCH v2 1/4] software node: return -ENXIO when referenced\n swnode is not registered yet","submitter":{"id":8583,"url":"http://patchwork.ozlabs.org/api/people/8583/","name":"Andy Shevchenko","email":"andriy.shevchenko@linux.intel.com"},"content":"On Thu, Apr 02, 2026 at 02:54:26PM +0200, Bartosz Golaszewski wrote:\n> It's possible that at the time of resolving a reference to a remote\n> software node, the node we know exists is not yet registered as a full\n> firmware node. We currently return -ENOENT in this case but the same\n> error code is also returned in some other cases, like the reference\n> property with given name not existing in the property list of the local\n> software node.\n> \n> It makes sense to let users know that we're dealing with an unregistered\n> software node so that they can defer probe - the situation is somewhat\n> similar to there existing a firmware node to which no device is bound\n> yet - which is valid grounds for probe deferral. To that end: use -ENXIO\n> which stands for \"No such device or address\".\n\nThis error code is also too generic to my taste. What about alternative(s)?\nEADDRNOTAVAIL\nENOTCONN\n\n(The brief grep shows that the second one might suit slightly better than the\n first one by existing use cases.)\n\nDo we need to update the (chain of) kernel-doc?","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","linux-gpio@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256\n header.s=Intel header.b=c+uXZyYm;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=172.105.105.114; helo=tor.lore.kernel.org;\n envelope-from=linux-gpio+bounces-34592-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com\n header.b=\"c+uXZyYm\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=192.198.163.9","smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=linux.intel.com","smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=linux.intel.com"],"Received":["from tor.lore.kernel.org (tor.lore.kernel.org [172.105.105.114])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fmjjq51yrz1yCs\n\tfor ; Fri, 03 Apr 2026 00:43:27 +1100 (AEDT)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby tor.lore.kernel.org (Postfix) with ESMTP id DD79C3130F7F\n\tfor ; Thu, 2 Apr 2026 13:36:13 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id AD1C13009CB;\n\tThu, 2 Apr 2026 13:36:04 +0000 (UTC)","from mgamail.intel.com (mgamail.intel.com [192.198.163.9])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id EC2F130E831;\n\tThu, 2 Apr 2026 13:36:02 +0000 (UTC)","from orviesa002.jf.intel.com ([10.64.159.142])\n by fmvoesa103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;\n 02 Apr 2026 06:36:03 -0700","from amilburn-desk.amilburn-desk (HELO localhost) ([10.245.245.31])\n by orviesa002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;\n 02 Apr 2026 06:35:38 -0700"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1775136964; cv=none;\n b=gPAxzV5WtNJ4LHPHhBg7XroCyXjXKeD4qJ8W6XV73xgmk8YjouhORy4/6qF/IxEXDdCHNzIgi7X/E1uNVXpYBcJd29Zh7WzT9lDs0pPIbWbyz92cVGjypk1/yrEShorzOL+/PMETcrhWU2DjZnb/qyOC9QzkE+6u92oTnKQKgPU=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1775136964; c=relaxed/simple;\n\tbh=EUyHOU+PT6gcnQyOOsL/7iU6RX6nDZfCu5E3pc2js84=;\n\th=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:\n\t Content-Type:Content-Disposition:In-Reply-To;\n b=TtM7TrL24Xwtx5QTdFc+2VlCM02AJrGtwCeUjgKAYnm0+KBSYZkHrxchPzFI3WYKXx5K8PECUJVVPMGqZNe38QC4QUCK6dUUM7ZW9VwCln86FBcXYlJIS0c4FGJ5wPlmdWla890vj/tgfx9aAYX0YrJ1dY+67LD3zaGsF3U19t0=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=linux.intel.com;\n spf=pass smtp.mailfrom=linux.intel.com;\n dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com\n header.b=c+uXZyYm; arc=none smtp.client-ip=192.198.163.9","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple;\n d=intel.com; i=@intel.com; q=dns/txt; s=Intel;\n t=1775136963; x=1806672963;\n h=date:from:to:cc:subject:message-id:references:\n mime-version:in-reply-to;\n bh=EUyHOU+PT6gcnQyOOsL/7iU6RX6nDZfCu5E3pc2js84=;\n b=c+uXZyYmGZoJw5GpIgc4SGi5XUFlX0JQURrWqT0ThjSno7TCrkxQPWPC\n CwczDuB1Sg4fPbZSSoM4w7kjyxj8e8FmKONLlvKO5FluO0J4tJV/Yg2d4\n Eij5Oc/1biospJiLIlGceQnYtI5/98rIeJbXEr3U6QAqly7NpDC2R7Jju\n iz2kwqHdzxgc6Rj9akUWtao68DoNzbUo23iBb1i/ms737xU0jWldDrqAy\n OVnmG1RTf3RTpV58hHqlFykVV3CHFKgJYZDBPKD9HNrArC4rxw2iQlGFl\n 0lGfZMLQy5kaACmAFmvKv0uNSiMyhhBRYwEtYyMY95yocl0TLmDHE6qfw\n g==;","X-CSE-ConnectionGUID":["KV9QR5sZQzKfQ96CrpKxoQ==","ohdmiZMgRjSwR2KP1n23kg=="],"X-CSE-MsgGUID":["Hfj39xJrQ9ORyL/gmrYLSQ==","+0H3evrnRy+vKvbW51rkjg=="],"X-IronPort-AV":["E=McAfee;i=\"6800,10657,11746\"; a=\"86896088\"","E=Sophos;i=\"6.23,155,1770624000\";\n d=\"scan'208\";a=\"86896088\"","E=Sophos;i=\"6.23,155,1770624000\";\n d=\"scan'208\";a=\"257464118\""],"X-ExtLoop1":"1","Date":"Thu, 2 Apr 2026 16:35:34 +0300","From":"Andy Shevchenko ","To":"Bartosz Golaszewski ","Cc":"Daniel Scally ,\n Heikki Krogerus ,\n Sakari Ailus ,\n Greg Kroah-Hartman ,\n \"Rafael J. Wysocki\" , Danilo Krummrich ,\n Mika Westerberg ,\n Andy Shevchenko , Linus Walleij ,\n Hans de Goede ,\n Ilpo =?iso-8859-1?q?J=E4rvinen?= ,\n Dmitry Torokhov , Len Brown ,\n linux-acpi@vger.kernel.org, driver-core@lists.linux.dev,\n linux-kernel@vger.kernel.org, linux-gpio@vger.kernel.org,\n platform-driver-x86@vger.kernel.org, brgl@kernel.org","Subject":"Re: [PATCH v2 1/4] software node: return -ENXIO when referenced\n swnode is not registered yet","Message-ID":"","References":"<20260402-baytrail-real-swnode-v2-0-6f5054a4cc07@oss.qualcomm.com>\n <20260402-baytrail-real-swnode-v2-1-6f5054a4cc07@oss.qualcomm.com>","Precedence":"bulk","X-Mailing-List":"linux-gpio@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":"\n <20260402-baytrail-real-swnode-v2-1-6f5054a4cc07@oss.qualcomm.com>","Organization":"Intel Finland Oy - BIC 0357606-4 - c/o Alberga Business Park, 6\n krs, Bertel Jungin Aukio 5, 02600 Espoo"}},{"id":3672898,"web_url":"http://patchwork.ozlabs.org/comment/3672898/","msgid":"","list_archive_url":null,"date":"2026-04-02T20:43:35","subject":"Re: [PATCH v2 1/4] software node: return -ENXIO when referenced\n swnode is not registered yet","submitter":{"id":695,"url":"http://patchwork.ozlabs.org/api/people/695/","name":"Dmitry Torokhov","email":"dmitry.torokhov@gmail.com"},"content":"On Thu, Apr 02, 2026 at 04:35:34PM +0300, Andy Shevchenko wrote:\n> On Thu, Apr 02, 2026 at 02:54:26PM +0200, Bartosz Golaszewski wrote:\n> > It's possible that at the time of resolving a reference to a remote\n> > software node, the node we know exists is not yet registered as a full\n> > firmware node. We currently return -ENOENT in this case but the same\n> > error code is also returned in some other cases, like the reference\n> > property with given name not existing in the property list of the local\n> > software node.\n> > \n> > It makes sense to let users know that we're dealing with an unregistered\n> > software node so that they can defer probe - the situation is somewhat\n> > similar to there existing a firmware node to which no device is bound\n> > yet - which is valid grounds for probe deferral. To that end: use -ENXIO\n> > which stands for \"No such device or address\".\n> \n> This error code is also too generic to my taste. What about alternative(s)?\n> EADDRNOTAVAIL\n> ENOTCONN\n> \n> (The brief grep shows that the second one might suit slightly better than the\n> first one by existing use cases.)\n\nWe are in the core of the driver core. Why not simply use -EPROBE_DEFER\nto which all users will resolve this error to and call it a day?\n\nThanks.","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","linux-gpio@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256\n header.s=20251104 header.b=gXiyjDE2;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=172.105.105.114; helo=tor.lore.kernel.org;\n envelope-from=linux-gpio+bounces-34617-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com\n header.b=\"gXiyjDE2\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=74.125.82.173","smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=gmail.com","smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=gmail.com"],"Received":["from tor.lore.kernel.org (tor.lore.kernel.org [172.105.105.114])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fmv2s4wNjz1yCt\n\tfor ; Fri, 03 Apr 2026 07:43:49 +1100 (AEDT)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby tor.lore.kernel.org (Postfix) with ESMTP id E74CF3024193\n\tfor ; Thu, 2 Apr 2026 20:43:45 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id CDFE736074D;\n\tThu, 2 Apr 2026 20:43:41 +0000 (UTC)","from mail-dy1-f173.google.com (mail-dy1-f173.google.com\n [74.125.82.173])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id 6E21B344D8E\n\tfor ; Thu, 2 Apr 2026 20:43:40 +0000 (UTC)","by mail-dy1-f173.google.com with SMTP id\n 5a478bee46e88-2bd9a485bd6so2911701eec.1\n for ;\n Thu, 02 Apr 2026 13:43:40 -0700 (PDT)","from google.com ([2a00:79e0:2ebe:8:902a:cd8d:1c0d:8926])\n by smtp.gmail.com with ESMTPSA id\n 5a478bee46e88-2ca7c20b195sm3280897eec.16.2026.04.02.13.43.37\n (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);\n Thu, 02 Apr 2026 13:43:38 -0700 (PDT)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1775162621; cv=none;\n b=Tap0APsdhrVrYLeSJ5lJ7VQHfAkU6k3jpAIpB46Ey2h9gj4PaudWEOBZf+OOAF5U7igYySl0ylE/6xKqb8chTjIK/gLN/AxmOlVEg0quq5KQ1Ip3Y94FgtoyIbmld9v5uRE28PDXuV3sPVeuqGR0yNGCFv7kWztU2ghScdoRgG8=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1775162621; c=relaxed/simple;\n\tbh=PfOSvF+9Q9GvIApbJuER9HJI0ph9y/C4dHyB4wNs/UM=;\n\th=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:\n\t Content-Type:Content-Disposition:In-Reply-To;\n b=lwIimsbpm3Zbydm7jNkn9QKeMVsWNCd0eS7z4zvNC+PIPw8jqGBcm5GHU/qZwQ+TK4mdDSDL10DPT3iKZyO+ACEgkyf2UN1aG8l/3jWPmiDnX77V4vNY6oBUVF+blS1eqLR3Pt6nAp7UWtjKFw0K5OdFJOhd2H4oMIB3MmHMhoI=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=gmail.com;\n spf=pass smtp.mailfrom=gmail.com;\n dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com\n header.b=gXiyjDE2; arc=none smtp.client-ip=74.125.82.173","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=gmail.com; s=20251104; t=1775162620; x=1775767420;\n darn=vger.kernel.org;\n h=in-reply-to:content-disposition:mime-version:references:message-id\n :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;\n bh=21ClTGnhigH6pmJ1bdxGPTsm+cYy8Gt+rk4//h1qZck=;\n b=gXiyjDE23EjXZrk7uxkNcBB90uOw5CiHfWwnqND5xV+ZfXYwOvoki959Actdm7YRIG\n JkGCDOyqQ4vgCIsZBFfYtt8JrzFCwl+C+wz0hhnpA8CCzJqeiTmleEFdz2i3jtapa9EE\n L2fhOyB4vIj3CAC8YmbQsUvNwPsjDv9mvPjffXHOFlcaBRowboyMcjG2PfT1JIWglBUH\n aWEMWu5IkK/vHJ2VO+loA+2NQBrbvt6q5BmEztS5StTut1G7l7l4Osv3+/5SeEd4Ueb8\n /pxhVKKvn/o4XmluN2Ii16rlCd7rTdcfToOBaTXYsXqFlmMntxbJL/xdCIhKmvzC+YSl\n AB5g==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1775162620; x=1775767420;\n h=in-reply-to:content-disposition:mime-version:references:message-id\n :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc\n :subject:date:message-id:reply-to;\n bh=21ClTGnhigH6pmJ1bdxGPTsm+cYy8Gt+rk4//h1qZck=;\n b=B1KY2+dyWGRXgvbi/C5N/a0DKwHyOKHxe7MfDYOvAnMGJmdRqOXJS0p9qVGrRDAsc7\n 2KfmNoSmOudTLqvD81CvJZXcoKzlEWN9owKYs+jwlk1Fjt9sWdp2FuB8HkBgJXksG7zo\n BY4VhkQOmxiW2YTZDbym60GaNoIznZ1pD7dmHooyKcqbA659LGaVyzWum+z+U3iL2Jzu\n 85MLHAS/LGg1yo7VHUZAyQsYaGRpfCMdnMgb1+CeRjV2+6V6r4LbjDR2bmMK/gxFBwJN\n xXywOi5PwAnjKmvpA9w0mxAjpfwYZtY0bA/SrkEwekhr5imtweYFh44D6ccX7Komv2Yi\n 0umw==","X-Forwarded-Encrypted":"i=1;\n AJvYcCXCM34ftFDZDprvfu+bHnKzEdkq7Gjf2lmItdDcc1T6AM4vJ8Y9w1fjDo25sp3ITKM0MUXkwHYO1DuZ@vger.kernel.org","X-Gm-Message-State":"AOJu0YzoPEqRb2mJmD9w9Gc4MWdj4BPpexRG24ajn/e2U0zlr82u/Row\n\t9tfShDnumaqsv3sFX0pBl3PX7oZ8Vj0RFYYTx9cQGZ0+Sn96L0Y8sbcz","X-Gm-Gg":"AeBDieuuPyUkLVj6oEM2GPasNwPFyzsBxoN3tQiclRvrwHQXl72CjoQ86kiQOV6hUsN\n\t8quSgqjgA4GnF9hME/99QSLxLsuCLhSKOUCMNNNfqSsJEcgAFlD2O4j0PiYnrUKjh8N9GXP+OTL\n\thReXfi5b4cM5Sk17VhRRvD8uj1OKOAfVTKmCunqszrjoRoBlSOYNdYDTb61gBZvrGUrKtIqrl0U\n\t4wRZ9QRI1reO+0l7HtlZKSkV4IYzi2ppjDHOf/SwgNWtxrM/eBefbRekOq2Je/+1IlLNoz6bLv+\n\tsCs4c7LNNZRdJthhnjO0ycvldOoN/Fto1S6XG9hRqZwLUgvzwqme4wcLgMMYWNN/BTMjsjwr2pV\n\t8TyWRAnZF2tWN1x3am5j6oKrUupLDUcbMRmkdarA607/N19U0/SN3NWnzWKDzwsEBXJVPQHZ75v\n\tZRUbF1DwNoCwhksyIUt8c4YKhaOySm30pJx21MgzRFhVbIV5+RcvIzMm+Vi08I47QZ","X-Received":"by 2002:a05:7301:1e87:b0:2c6:cdb3:bd8d with SMTP id\n 5a478bee46e88-2cbf9afd61emr347222eec.7.1775162619471;\n Thu, 02 Apr 2026 13:43:39 -0700 (PDT)","Date":"Thu, 2 Apr 2026 13:43:35 -0700","From":"Dmitry Torokhov ","To":"Andy Shevchenko ","Cc":"Bartosz Golaszewski ,\n Daniel Scally ,\n Heikki Krogerus ,\n Sakari Ailus ,\n Greg Kroah-Hartman ,\n \"Rafael J. Wysocki\" , Danilo Krummrich ,\n Mika Westerberg ,\n Andy Shevchenko , Linus Walleij ,\n Hans de Goede ,\n Ilpo =?utf-8?b?SsOkcnZpbmVu?= ,\n Len Brown , linux-acpi@vger.kernel.org,\n driver-core@lists.linux.dev, linux-kernel@vger.kernel.org,\n linux-gpio@vger.kernel.org, platform-driver-x86@vger.kernel.org,\n brgl@kernel.org","Subject":"Re: [PATCH v2 1/4] software node: return -ENXIO when referenced\n swnode is not registered yet","Message-ID":"","References":"<20260402-baytrail-real-swnode-v2-0-6f5054a4cc07@oss.qualcomm.com>\n <20260402-baytrail-real-swnode-v2-1-6f5054a4cc07@oss.qualcomm.com>\n ","Precedence":"bulk","X-Mailing-List":"linux-gpio@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":""}},{"id":3673005,"web_url":"http://patchwork.ozlabs.org/comment/3673005/","msgid":"","list_archive_url":null,"date":"2026-04-03T07:29:38","subject":"Re: [PATCH v2 1/4] software node: return -ENXIO when referenced\n swnode is not registered yet","submitter":{"id":92191,"url":"http://patchwork.ozlabs.org/api/people/92191/","name":"Bartosz Golaszewski","email":"brgl@kernel.org"},"content":"On Thu, Apr 2, 2026 at 10:43 PM Dmitry Torokhov\n wrote:\n>\n> On Thu, Apr 02, 2026 at 04:35:34PM +0300, Andy Shevchenko wrote:\n> > On Thu, Apr 02, 2026 at 02:54:26PM +0200, Bartosz Golaszewski wrote:\n> > > It's possible that at the time of resolving a reference to a remote\n> > > software node, the node we know exists is not yet registered as a full\n> > > firmware node. We currently return -ENOENT in this case but the same\n> > > error code is also returned in some other cases, like the reference\n> > > property with given name not existing in the property list of the local\n> > > software node.\n> > >\n> > > It makes sense to let users know that we're dealing with an unregistered\n> > > software node so that they can defer probe - the situation is somewhat\n> > > similar to there existing a firmware node to which no device is bound\n> > > yet - which is valid grounds for probe deferral. To that end: use -ENXIO\n> > > which stands for \"No such device or address\".\n> >\n> > This error code is also too generic to my taste. What about alternative(s)?\n> > EADDRNOTAVAIL\n> > ENOTCONN\n> >\n> > (The brief grep shows that the second one might suit slightly better than the\n> > first one by existing use cases.)\n>\n> We are in the core of the driver core. Why not simply use -EPROBE_DEFER\n> to which all users will resolve this error to and call it a day?\n>\n\nBecause -EPROBE_DEFER only makes sense in probe() context, while\nfwnode_get_reference_args() may be called in many other situations. I\nthink ENOTCONN as \"not connected\" makes sense, though the string\nrepresentation says: \"Transport endpoint is not connected\" which\ndoesn't spell out quite the same thing.\n\nBart","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","linux-gpio@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=ufuE3aPG;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c0a:e001:db::12fc:5321; helo=sea.lore.kernel.org;\n envelope-from=linux-gpio+bounces-34625-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org\n header.b=\"ufuE3aPG\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=10.30.226.201"],"Received":["from sea.lore.kernel.org (sea.lore.kernel.org\n [IPv6:2600:3c0a:e001:db::12fc:5321])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fn9Ns2frmz1xtJ\n\tfor ; Fri, 03 Apr 2026 18:30:21 +1100 (AEDT)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sea.lore.kernel.org (Postfix) with ESMTP id 41E1F30416D1\n\tfor ; Fri, 3 Apr 2026 07:29:53 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 45B8C378D92;\n\tFri, 3 Apr 2026 07:29:52 +0000 (UTC)","from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org\n [10.30.226.201])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id 06B68377009\n\tfor ; Fri, 3 Apr 2026 07:29:51 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id D026CC2BCF4\n\tfor ; Fri, 3 Apr 2026 07:29:51 +0000 (UTC)","by mail-lf1-f47.google.com with SMTP id\n 2adb3069b0e04-5a12cd0bd79so1965395e87.2\n for ;\n Fri, 03 Apr 2026 00:29:51 -0700 (PDT)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1775201392; cv=none;\n b=mHImeTXF6JIU1lrqo44RK1JMRR6Wg7Qp4nMWNPi3Ps272zYDruTod4CVHtGDfFMjTR68E51tAnXRJcQjhPXYR7GW1g7c/Oe7ovro8Rrxst7xxyybE7mcsyVxYhaCb2bDjKFvMasB73UnPzoiDyTOsydVGetyQ/oCxYa5zc5NOtM=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1775201392; c=relaxed/simple;\n\tbh=o+bZHsTAqtziXuBsNd+plTbXRxbHoO6NC5HHzgU3PU4=;\n\th=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:\n\t To:Cc:Content-Type;\n b=iuMlUu3RUXSOD4fOy4pz2KAaLDsbEyEkHqxxM1Ip0aZ5J5Z9MeEPtne6hbfn5bTcpBi7/YVZq/Han4SJrRJFfHnx1KL7xaGRNq/WMUUAiB5B9agpjsW+YtnzTseiA5cd81W/sn7WFmP3i7VD2AlrwZChB59GcaPcCRtFIHTriC8=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org\n header.b=ufuE3aPG; arc=none smtp.client-ip=10.30.226.201","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;\n\ts=k20201202; t=1775201391;\n\tbh=o+bZHsTAqtziXuBsNd+plTbXRxbHoO6NC5HHzgU3PU4=;\n\th=References:In-Reply-To:From:Date:Subject:To:Cc:From;\n\tb=ufuE3aPGGnvRozgJelrUuR+95zug3LqzWGJlK/3JEpBBP2rD21IpOrQCkkZ/TwHgv\n\t eDGPCaR7uV+RUHq63WzzHRu1al+HFhHwyPpIGo1fuDvxpKsDNvey9fq2fJRJR6gmG4\n\t J3yGQkpZPuhN91xooONIt7qurzA3dHDlm/zYFEWWzeYyuVDN1jOrJX7Gi6XrSzQbOy\n\t LtDnjlMTWhRo5O0utkp+eVHf0R54xF5OIfGqDcIYJoSYgGUTAlwzKvbAnjvIOyWik2\n\t zdfKPrSHOoBNyiUjq7YkwOBI/1SqN8Aunqt5wKSRxed7Vng3frebRps4X8bJ2vQbPD\n\t j0REPppOrJiMg==","X-Forwarded-Encrypted":"i=1;\n AJvYcCU4zppxTESXZGir6Rh785j2VLjqYNAU8r+EufcRspjkOb1tkPzrLDwdvXW7Nl2PRqQIDC7e+hpGYKEA@vger.kernel.org","X-Gm-Message-State":"AOJu0YyhjGB+6/+QTXI9fX0P2mBq/gWDJxmVfQWnqXnJxqHtBCAMPOzq\n\tDOtMkE7P2ZtNUrjibuFO6qF2IfkxHQ1InZ/0QcxUFgrE1knvrSEpnI4mHYPh1g+GueYXGARK8DR\n\t5re2QRsqO5mVWMCApkctfH/zQ8gPt+f5xS/XkhXl9Yg==","X-Received":"by 2002:a05:6512:b82:b0:5a2:c409:8ed3 with SMTP id\n 2adb3069b0e04-5a3377823bcmr620861e87.40.1775201390408; Fri, 03 Apr 2026\n 00:29:50 -0700 (PDT)","Precedence":"bulk","X-Mailing-List":"linux-gpio@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","References":"<20260402-baytrail-real-swnode-v2-0-6f5054a4cc07@oss.qualcomm.com>\n <20260402-baytrail-real-swnode-v2-1-6f5054a4cc07@oss.qualcomm.com>\n ","In-Reply-To":"","From":"Bartosz Golaszewski ","Date":"Fri, 3 Apr 2026 09:29:38 +0200","X-Gmail-Original-Message-ID":"\n ","X-Gm-Features":"AQROBzCzQrtkyxRFQGk9CJN4liBRk5TYi19gtZVgUqX_Bqb_Om8xmXeCvKqn5jE","Message-ID":"\n ","Subject":"Re: [PATCH v2 1/4] software node: return -ENXIO when referenced\n swnode is not registered yet","To":"Dmitry Torokhov ","Cc":"Andy Shevchenko ,\n Bartosz Golaszewski ,\n Daniel Scally ,\n Heikki Krogerus ,\n Sakari Ailus ,\n Greg Kroah-Hartman ,\n \"Rafael J. Wysocki\" , Danilo Krummrich ,\n Mika Westerberg ,\n Andy Shevchenko , Linus Walleij ,\n Hans de Goede ,\n =?utf-8?q?Ilpo_J=C3=A4rvinen?= ,\n Len Brown , linux-acpi@vger.kernel.org,\n driver-core@lists.linux.dev, linux-kernel@vger.kernel.org,\n linux-gpio@vger.kernel.org, platform-driver-x86@vger.kernel.org","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable"}},{"id":3673260,"web_url":"http://patchwork.ozlabs.org/comment/3673260/","msgid":"","list_archive_url":null,"date":"2026-04-03T18:07:32","subject":"Re: [PATCH v2 1/4] software node: return -ENXIO when referenced\n swnode is not registered yet","submitter":{"id":695,"url":"http://patchwork.ozlabs.org/api/people/695/","name":"Dmitry Torokhov","email":"dmitry.torokhov@gmail.com"},"content":"On Fri, Apr 03, 2026 at 09:29:38AM +0200, Bartosz Golaszewski wrote:\n> On Thu, Apr 2, 2026 at 10:43 PM Dmitry Torokhov\n> wrote:\n> >\n> > On Thu, Apr 02, 2026 at 04:35:34PM +0300, Andy Shevchenko wrote:\n> > > On Thu, Apr 02, 2026 at 02:54:26PM +0200, Bartosz Golaszewski wrote:\n> > > > It's possible that at the time of resolving a reference to a remote\n> > > > software node, the node we know exists is not yet registered as a full\n> > > > firmware node. We currently return -ENOENT in this case but the same\n> > > > error code is also returned in some other cases, like the reference\n> > > > property with given name not existing in the property list of the local\n> > > > software node.\n> > > >\n> > > > It makes sense to let users know that we're dealing with an unregistered\n> > > > software node so that they can defer probe - the situation is somewhat\n> > > > similar to there existing a firmware node to which no device is bound\n> > > > yet - which is valid grounds for probe deferral. To that end: use -ENXIO\n> > > > which stands for \"No such device or address\".\n> > >\n> > > This error code is also too generic to my taste. What about alternative(s)?\n> > > EADDRNOTAVAIL\n> > > ENOTCONN\n> > >\n> > > (The brief grep shows that the second one might suit slightly better than the\n> > > first one by existing use cases.)\n> >\n> > We are in the core of the driver core. Why not simply use -EPROBE_DEFER\n> > to which all users will resolve this error to and call it a day?\n> >\n> \n> Because -EPROBE_DEFER only makes sense in probe() context, while\n> fwnode_get_reference_args() may be called in many other situations.\n\nExactly same argument applies to your follow-up change: gpiod_get()\nreturning -EPROBE_DEFER only makes sense in probe context but it may be\ncalled in many other situations. Are you planning to change all places\nwhere gpiolib returns -EPROBE_DEFER to something else just in case it\nmight be called outside of probe context? \n\n-EPROBE_DEFER should have been called -ENOTREADY from the beginning and\nthen we would not have this argument. Or, even better, we should have\nused -EAGAIN. But it is just a name, semantics does not really change.\nWe want to signal that something is not ready and the operation needs be\nrepeated. Currently we contorting ourselves by using yet another error\ncode that everyone will either convert to -EPORBE_DEFER or will handle\nlike -EAGAIN.\n\n> I think ENOTCONN as \"not connected\" makes sense, though the string\n\nWhy is it better? Most of users of -ENOTCONN are in networking code so\nit is somewhat unexpected to have other APIs return it. \n\n> representation says: \"Transport endpoint is not connected\" which\n> doesn't spell out quite the same thing.\n\nYes, because it is really for networking/sockets handling.\n\nThanks.","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","linux-gpio@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256\n header.s=20251104 header.b=XTYzGhnz;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c09:e001:a7::12fc:5321; helo=sto.lore.kernel.org;\n envelope-from=linux-gpio+bounces-34656-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com\n header.b=\"XTYzGhnz\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=74.125.82.53","smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=gmail.com","smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=gmail.com"],"Received":["from sto.lore.kernel.org (sto.lore.kernel.org\n [IPv6:2600:3c09:e001:a7::12fc:5321])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fnRXd2kymz1yCt\n\tfor ; Sat, 04 Apr 2026 05:08:01 +1100 (AEDT)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sto.lore.kernel.org (Postfix) with ESMTP id DA322300D76E\n\tfor ; Fri, 3 Apr 2026 18:07:55 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 563C33D34B3;\n\tFri, 3 Apr 2026 18:07:52 +0000 (UTC)","from mail-dl1-f53.google.com (mail-dl1-f53.google.com\n [74.125.82.53])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id C84003CEB85\n\tfor ; Fri, 3 Apr 2026 18:07:50 +0000 (UTC)","by mail-dl1-f53.google.com with SMTP id\n a92af1059eb24-12a80c36350so2491912c88.1\n for ;\n Fri, 03 Apr 2026 11:07:50 -0700 (PDT)","from google.com ([2a00:79e0:2ebe:8:2357:9278:e4dd:85f2])\n by smtp.gmail.com with ESMTPSA id\n a92af1059eb24-12bede7f004sm5079641c88.13.2026.04.03.11.07.48\n (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);\n Fri, 03 Apr 2026 11:07:49 -0700 (PDT)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1775239672; cv=none;\n b=Q1zBzYQ2HxaC5pV9eQTqUgjTay3ytXleD4oPJKyrvVhvl2kkfLcgpHC37rokUo4zHG0kiFck5hpaLKx5xNzL1xQOrt2cJGinUEttgWQ4rhGmi6/5NJFiI7gpNdEAaBgSIAKMWYR4+72Su2R7SlSNCQ6XKMEaz3VUOQHaNxi+LsU=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1775239672; c=relaxed/simple;\n\tbh=UFPWSEdBYNvmgOvcN99SS0anBY+f8Mv9diH3OxTcOTY=;\n\th=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:\n\t Content-Type:Content-Disposition:In-Reply-To;\n b=fRZxujByMZfhgIwpBz6uZ6AmRVFf7Cb8F1vXYVY6oOkRLEFSZA0j48RVdfRl9P/K2w1a65eCHJ5CdPSLNSqoOSNZ1nomH8QIj5VWVDukF+DQm+Vq3iKyZQjfdsecj0RW/6iVrqllxmMpYvBLZ0hyQfLbsFEROsOIHo6IIA49o70=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=gmail.com;\n spf=pass smtp.mailfrom=gmail.com;\n dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com\n header.b=XTYzGhnz; arc=none smtp.client-ip=74.125.82.53","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=gmail.com; s=20251104; t=1775239670; x=1775844470;\n darn=vger.kernel.org;\n h=in-reply-to:content-transfer-encoding:content-disposition\n :mime-version:references:message-id:subject:cc:to:from:date:from:to\n :cc:subject:date:message-id:reply-to;\n bh=XYS8rrk/W9xmmpVLtPf6SPDq6V5JZhKXUApyjYv6jfU=;\n b=XTYzGhnzcWGiLo+VIC5LKWuBaAiimDScN1VOv8TmEx4OBMEztOwhjuaN81sNhU+Tzv\n vuplG6XC57dRGHSKKn/vzdDien75/d4iYiNTsP49Sirnl76MVhGNKvy0LnS4FC/YmNhs\n TyMYXGUbOr/soQYjbpPOumwKe3ueG+sBFRPpwQ2z9cZrb2hXTsYhLRnO1KoLiOwlv4EB\n EIL0zcK+TXn5p/rcDi3L3WjhPehD9V13qBVaeU40lZplZDTrAxw2jKmoxbVqdpG8+iAd\n utL/u+SqlKBW5Tkgv7oxBTZmGBddhONOv+Hln1EVcwiZL7meGE5Uc1S1RmyhMl4qX2JE\n ZDXg==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1775239670; x=1775844470;\n h=in-reply-to:content-transfer-encoding:content-disposition\n :mime-version:references:message-id:subject:cc:to:from:date:x-gm-gg\n :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;\n bh=XYS8rrk/W9xmmpVLtPf6SPDq6V5JZhKXUApyjYv6jfU=;\n b=VcBeGludUR/W44/44eW5M2drRn5o3y9bjqoIdmSEAUxmAADQNfcJWjAHRit46s67gE\n T/ts7IIiYYUhRqj9nOoafQCO3TNlMNE9omvuTm6spZGEsVokW6GEGqF5DJCpV7IrglFE\n uA3PEPEnWBkcAmbJeXucp87xaMmFpB3qbph3xtubfr64AwX9A8Jk02S6mCRpIvHCoNgN\n K4fuYYpkvMIjfHaPrD8DJ+ARcjnOufStZz+5MnrSKEhPAzBNyGlT/UnauP+vGsjgM6y2\n 2XAR6sanzSNIG1XrkCbf37KEkqOmp+MuPjCYYlSCg7jRaj+tfELzFuGwKpdXik2RP9ft\n 70kA==","X-Forwarded-Encrypted":"i=1;\n AJvYcCWMdp5I3h4+AvOgdQsdrKA/bEEjIofKSpAjGgnE0HMopkRHqFEllecU1oIlZhfftepB5ilQdpZEsLXB@vger.kernel.org","X-Gm-Message-State":"AOJu0YxcUILYiSWoBrqre2PkDISXOvesoz5/om0MSbEktnhoP+12Nm93\n\tdTdOBGVtrIQYirtTwli7MT3PPu3H2yg+4mGJaqdIUuWuo1ENq98i9fr8","X-Gm-Gg":"ATEYQzw6QX2jXVtKEIA9AGV9hCbJN401XgDg14crgqK1JzuJCoZZUL7OILKrIZE6M71\n\tv/ZiLNgyQYv0yVnNH7c2H8zL1c0RmMLTQNFRPlM/nJ5gwJVE9eV8yckbD0az4ezEALYnm9EtSZA\n\tkSBVGUzpht9iJE7CTfB9eCIhUJOV63Sn5nLabuXZ7+/IaZ+2Qmkub/wL86IyIg+lhvcUiRe9bDP\n\tsKRcOLJx8koXUZmL4dMYgKQw+ZkARfLo3lMe1k/1MzF6wc8dCvE+1k1MIsmZ2W2u6PzDRXznlrl\n\tVZQurX0n6ZcYMOIw3k2ki8PYe1nHbthH0sJRaAGgmtpxB7Vhc30xFCCSsFVXmZlTXVK/uJEu7r+\n\tWGDhcSZG1I6GXZ2Vu/Amu5Zbcnnri4ArG78bNWgApq/tsioXeyK5XvU0c3eCchn6WI3RTkaBKLp\n\ta9PhtbU0e8toqxhvB34sByoMjDb2DyxfpdaTTQk4rV5pFdgc1+k+miaD9zQsAWgFqV","X-Received":"by 2002:a05:7022:43a8:b0:119:e569:f609 with SMTP id\n a92af1059eb24-12bfb6ecd57mr1666933c88.2.1775239669720;\n Fri, 03 Apr 2026 11:07:49 -0700 (PDT)","Date":"Fri, 3 Apr 2026 11:07:32 -0700","From":"Dmitry Torokhov ","To":"Bartosz Golaszewski ","Cc":"Andy Shevchenko ,\n Bartosz Golaszewski ,\n Daniel Scally ,\n Heikki Krogerus ,\n Sakari Ailus ,\n Greg Kroah-Hartman ,\n \"Rafael J. Wysocki\" , Danilo Krummrich ,\n Mika Westerberg ,\n Andy Shevchenko , Linus Walleij ,\n Hans de Goede ,\n Ilpo =?utf-8?b?SsOkcnZpbmVu?= ,\n Len Brown , linux-acpi@vger.kernel.org,\n driver-core@lists.linux.dev, linux-kernel@vger.kernel.org,\n linux-gpio@vger.kernel.org, platform-driver-x86@vger.kernel.org","Subject":"Re: [PATCH v2 1/4] software node: return -ENXIO when referenced\n swnode is not registered yet","Message-ID":"","References":"<20260402-baytrail-real-swnode-v2-0-6f5054a4cc07@oss.qualcomm.com>\n <20260402-baytrail-real-swnode-v2-1-6f5054a4cc07@oss.qualcomm.com>\n \n \n ","Precedence":"bulk","X-Mailing-List":"linux-gpio@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","Content-Transfer-Encoding":"8bit","In-Reply-To":"\n "}},{"id":3674092,"web_url":"http://patchwork.ozlabs.org/comment/3674092/","msgid":"","list_archive_url":null,"date":"2026-04-07T10:57:29","subject":"Re: [PATCH v2 1/4] software node: return -ENXIO when referenced\n swnode is not registered yet","submitter":{"id":92191,"url":"http://patchwork.ozlabs.org/api/people/92191/","name":"Bartosz Golaszewski","email":"brgl@kernel.org"},"content":"On Fri, Apr 3, 2026 at 8:07 PM Dmitry Torokhov\n wrote:\n>\n> On Fri, Apr 03, 2026 at 09:29:38AM +0200, Bartosz Golaszewski wrote:\n> > On Thu, Apr 2, 2026 at 10:43 PM Dmitry Torokhov\n> > wrote:\n> > >\n> > > On Thu, Apr 02, 2026 at 04:35:34PM +0300, Andy Shevchenko wrote:\n> > > > On Thu, Apr 02, 2026 at 02:54:26PM +0200, Bartosz Golaszewski wrote:\n> > > > > It's possible that at the time of resolving a reference to a remote\n> > > > > software node, the node we know exists is not yet registered as a full\n> > > > > firmware node. We currently return -ENOENT in this case but the same\n> > > > > error code is also returned in some other cases, like the reference\n> > > > > property with given name not existing in the property list of the local\n> > > > > software node.\n> > > > >\n> > > > > It makes sense to let users know that we're dealing with an unregistered\n> > > > > software node so that they can defer probe - the situation is somewhat\n> > > > > similar to there existing a firmware node to which no device is bound\n> > > > > yet - which is valid grounds for probe deferral. To that end: use -ENXIO\n> > > > > which stands for \"No such device or address\".\n> > > >\n> > > > This error code is also too generic to my taste. What about alternative(s)?\n> > > > EADDRNOTAVAIL\n> > > > ENOTCONN\n> > > >\n> > > > (The brief grep shows that the second one might suit slightly better than the\n> > > > first one by existing use cases.)\n> > >\n> > > We are in the core of the driver core. Why not simply use -EPROBE_DEFER\n> > > to which all users will resolve this error to and call it a day?\n> > >\n> >\n> > Because -EPROBE_DEFER only makes sense in probe() context, while\n> > fwnode_get_reference_args() may be called in many other situations.\n>\n> Exactly same argument applies to your follow-up change: gpiod_get()\n> returning -EPROBE_DEFER only makes sense in probe context but it may be\n> called in many other situations. Are you planning to change all places\n> where gpiolib returns -EPROBE_DEFER to something else just in case it\n> might be called outside of probe context?\n>\n\nI'd argue that gpiod_get() should really be limited to being called at\nprobe() time but I see your point.\n\n> -EPROBE_DEFER should have been called -ENOTREADY from the beginning and\n> then we would not have this argument. Or, even better, we should have\n> used -EAGAIN. But it is just a name, semantics does not really change.\n> We want to signal that something is not ready and the operation needs be\n> repeated. Currently we contorting ourselves by using yet another error\n> code that everyone will either convert to -EPORBE_DEFER or will handle\n> like -EAGAIN.\n>\n> > I think ENOTCONN as \"not connected\" makes sense, though the string\n>\n> Why is it better? Most of users of -ENOTCONN are in networking code so\n> it is somewhat unexpected to have other APIs return it.\n>\n> > representation says: \"Transport endpoint is not connected\" which\n> > doesn't spell out quite the same thing.\n>\n> Yes, because it is really for networking/sockets handling.\n>\n> Thanks.\n>\n\nAndy et al: what is your take on this?\n\nBart","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","linux-gpio@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=mYWWf7Qb;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=172.234.253.10; helo=sea.lore.kernel.org;\n envelope-from=linux-gpio+bounces-34778-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org\n header.b=\"mYWWf7Qb\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=10.30.226.201"],"Received":["from sea.lore.kernel.org (sea.lore.kernel.org [172.234.253.10])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fqjtd6PvPz1yD3\n\tfor ; Tue, 07 Apr 2026 21:01:29 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sea.lore.kernel.org (Postfix) with ESMTP id 8954C30209E8\n\tfor ; Tue, 7 Apr 2026 10:57:44 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id B135A3AB297;\n\tTue, 7 Apr 2026 10:57:42 +0000 (UTC)","from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org\n [10.30.226.201])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id 716093AB269\n\tfor ; Tue, 7 Apr 2026 10:57:42 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id 4E714C2BCB3\n\tfor ; Tue, 7 Apr 2026 10:57:42 +0000 (UTC)","by mail-lf1-f52.google.com with SMTP id\n 2adb3069b0e04-5a2c9c5ff87so5082498e87.0\n for ;\n Tue, 07 Apr 2026 03:57:42 -0700 (PDT)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1775559462; cv=none;\n b=RIAtoso0npFqocPaOEj0TwnRqTihi5z0eLrf1MVL4gqNOLxVd7y6gx45QXeLz+kA9xaIXLlCj7pb+Py4UTCFpLy8PpUnGe9e2ChfdIcLk7EMoT23eTKBcdyNluX/J1RLCPQrCa8Yaal8YWR9TqASjsfiKdG54pakE6QEB8FjLSg=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1775559462; c=relaxed/simple;\n\tbh=4r1vDbs0pq5LzaslrOkl01oKuos6pzpFCtMes87/kkw=;\n\th=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:\n\t To:Cc:Content-Type;\n b=tzvqDeajqxQ8bzmS2SkfGq/8FKOrcXn25OuSojAOzwnBIen2xCgTwtP816Xpj8bPFy8VMAX/jH0ag1Xo+3ecPfkXnn5jYRmTOveWzjIZtXSTliO6Ee6/Pl/6d8e3fUKx8Bqes+qk9uZegmeiOiLJM9gC8EcXC7OXLKi85uS2drc=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org\n header.b=mYWWf7Qb; arc=none smtp.client-ip=10.30.226.201","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;\n\ts=k20201202; t=1775559462;\n\tbh=4r1vDbs0pq5LzaslrOkl01oKuos6pzpFCtMes87/kkw=;\n\th=References:In-Reply-To:From:Date:Subject:To:Cc:From;\n\tb=mYWWf7Qby/+Ci0q++KFsbjqGBGSoCxKvCQ2kqJycj6SIEnHNLLwR9r44X0d4CPolK\n\t tg3Bfo3kPewMeTpksUKFEVeP6Mdx60XXNYMPnEHKZwOHbvf24rnA6ul1eoIUzbMlVU\n\t ZCo6qCqJhpc2PfUP3hPYjnH929wKNz2iPZqbyvPqt8pBOzT0lMi6hJddmw16cwsJfU\n\t J9ip6EGwANwwjWw33HDR4T6V/HLd5/lctDR5mnTLrAgq8pqbROkLVUVlgbnl+4rkyg\n\t NGjqcxD8eJL87zmmj8WbVfvcad2TwOSwA+tOxnekG11AdspcwOIFn48c4UKl6GjiSC\n\t 7ujyavdEdgpGQ==","X-Forwarded-Encrypted":"i=1;\n AJvYcCWVIdGjyyStDz8guUwr6cquvKHyAwr/y7NFyI+qpEBmXxNbHOsS55dlM/IUgIQDFqHTB9xwmFZacJjU@vger.kernel.org","X-Gm-Message-State":"AOJu0YzvN1sssP4tRwjjk8tRgGVrNAu7UDIP+aQ6zrji99yYwB/s6nDI\n\t/VXLqSHUSgdqzJ3/x1p6wAiyW9huAKOwUXlujeXX6pgm5dPT4HV3q6E5EbzZh1+zqiM0HcibVoQ\n\tlgBBocFUB2dk7VxKJK2pSud2Cq5/iMT7z4Us9tQrDPw==","X-Received":"by 2002:ac2:4e0a:0:b0:5a2:a0b0:94a with SMTP id\n 2adb3069b0e04-5a33757bf68mr5319679e87.25.1775559460807; Tue, 07 Apr 2026\n 03:57:40 -0700 (PDT)","Precedence":"bulk","X-Mailing-List":"linux-gpio@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","References":"<20260402-baytrail-real-swnode-v2-0-6f5054a4cc07@oss.qualcomm.com>\n <20260402-baytrail-real-swnode-v2-1-6f5054a4cc07@oss.qualcomm.com>\n \n \n ","In-Reply-To":"","From":"Bartosz Golaszewski ","Date":"Tue, 7 Apr 2026 12:57:29 +0200","X-Gmail-Original-Message-ID":"\n ","X-Gm-Features":"AQROBzBAE1qyZXcNp6W0M7clxAQQsS9tQ0MKkJzF0Q5g3_M3cSllREtCbrsIUy0","Message-ID":"\n ","Subject":"Re: [PATCH v2 1/4] software node: return -ENXIO when referenced\n swnode is not registered yet","To":"Dmitry Torokhov ","Cc":"Andy Shevchenko ,\n Bartosz Golaszewski ,\n Daniel Scally ,\n Heikki Krogerus ,\n Sakari Ailus ,\n Greg Kroah-Hartman ,\n \"Rafael J. Wysocki\" , Danilo Krummrich ,\n Mika Westerberg ,\n Andy Shevchenko , Linus Walleij ,\n Hans de Goede ,\n =?utf-8?q?Ilpo_J=C3=A4rvinen?= ,\n Len Brown , linux-acpi@vger.kernel.org,\n driver-core@lists.linux.dev, linux-kernel@vger.kernel.org,\n linux-gpio@vger.kernel.org, platform-driver-x86@vger.kernel.org","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable"}},{"id":3674193,"web_url":"http://patchwork.ozlabs.org/comment/3674193/","msgid":"","list_archive_url":null,"date":"2026-04-07T13:30:17","subject":"Re: [PATCH v2 1/4] software node: return -ENXIO when referenced\n swnode is not registered yet","submitter":{"id":92191,"url":"http://patchwork.ozlabs.org/api/people/92191/","name":"Bartosz Golaszewski","email":"brgl@kernel.org"},"content":"On Tue, Apr 7, 2026 at 12:57 PM Bartosz Golaszewski wrote:\n>\n> > -EPROBE_DEFER should have been called -ENOTREADY from the beginning and\n> > then we would not have this argument. Or, even better, we should have\n> > used -EAGAIN. But it is just a name, semantics does not really change.\n> > We want to signal that something is not ready and the operation needs be\n> > repeated. Currently we contorting ourselves by using yet another error\n> > code that everyone will either convert to -EPORBE_DEFER or will handle\n> > like -EAGAIN.\n> >\n>\n> Andy et al: what is your take on this?\n>\n> Bart\n\nAndy acked the v3 patch and Sakari pointed out an example of v4l2\nwhere a similar approach was taken, so I sent a v4 with issues pointed\nout in v3 fixed.\n\nBart","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","linux-gpio@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=f5378GIm;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=172.234.253.10; helo=sea.lore.kernel.org;\n envelope-from=linux-gpio+bounces-34813-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org\n header.b=\"f5378GIm\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=10.30.226.201"],"Received":["from sea.lore.kernel.org (sea.lore.kernel.org [172.234.253.10])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fqnR80pP4z1xtJ\n\tfor ; Tue, 07 Apr 2026 23:41:24 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sea.lore.kernel.org (Postfix) with ESMTP id 21A59305B2B2\n\tfor ; Tue, 7 Apr 2026 13:30:37 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 78C601E0DE8;\n\tTue, 7 Apr 2026 13:30:36 +0000 (UTC)","from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org\n [10.30.226.201])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id 3C51A2C86D\n\tfor ; Tue, 7 Apr 2026 13:30:36 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id 15A69C2BCB0\n\tfor ; Tue, 7 Apr 2026 13:30:36 +0000 (UTC)","by mail-lj1-f177.google.com with SMTP id\n 38308e7fff4ca-38cc8708d76so43227001fa.3\n for ;\n Tue, 07 Apr 2026 06:30:36 -0700 (PDT)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1775568636; cv=none;\n b=pu/GIwswM5QXrekxSSzKIUSJAGUEuJWwytVYVS03leIlhao6l7OHDMmH4tj+WmyHApXURqRfeVakFmMaB0lA88gg5nUgrUBOPICy/fP6n/48ESiB66Klno4SMXIzGF8KC4S9JSbQ6diOkZQmmnEvJHLoTJVMZQHke3omZF5Y2Kw=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1775568636; c=relaxed/simple;\n\tbh=xX/hhBDJLd9xal9rlmLTq8tcBQ3ZwIxZZu1w1wj3XHI=;\n\th=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:\n\t To:Cc:Content-Type;\n b=jIXB9STAu/WWywbgx3KL7L5usL1wDEjnWz6IeoA7Om4VLlbDJ4PmuBKRd0XaYTxCeVNsF+bONe8yDWQRzmclXYNk7+laZ1Oc0a6Wc6HeAJO2+hxnXzIE5RMj3iRcom+3L9yQtPL+TwrChz/depx5SbI4BOxhwGpiHddrXYBHFjY=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org\n header.b=f5378GIm; arc=none smtp.client-ip=10.30.226.201","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;\n\ts=k20201202; t=1775568636;\n\tbh=xX/hhBDJLd9xal9rlmLTq8tcBQ3ZwIxZZu1w1wj3XHI=;\n\th=References:In-Reply-To:From:Date:Subject:To:Cc:From;\n\tb=f5378GImYAQt5+RjMqq0kVvqiQuebqBQypOQWuoH2kpBIC6MD2qMfIHHlgX8lpmr0\n\t ewa/+f88KWwTNdcrfw0Z1zcDhFoI1KLnbPC1IIyTCwkc+8uICDGiaqT54bMml+K6Lq\n\t SEZzoz0ZBzOocXyhjB2oZeeySJjeBZmHaoZ8Ovc8M8o/w4FQCdLQKwtJjLa/UacqoR\n\t O6bOIdDWOy2cpu7qxksQMSjBSm8uv1TsxvmvEIux9I8CwVQiZsCYU9+r6U5toNMYCK\n\t 3qddw8SeRuj+WgkwgeyzwO7fG1YAeJAIVxPnC3GwKnC8HdDBLXrGy2faa8A5WzkHKq\n\t v+rbhO367HbLQ==","X-Forwarded-Encrypted":"i=1;\n AJvYcCVMkR2XPrvMUkVacHlTgWGwJ33tZ5pqfPUbV53gtZGP7cgKRyCXdLGZoCMSPio3r/a4KHaeg56MZX3Z@vger.kernel.org","X-Gm-Message-State":"AOJu0Yzjv1IP9hDqDok/eo6sEsfJmDLRigBCj5irv77RHX64wDTv/Fo2\n\tgw30qavVVuKLmICPkj6B6GkQyWO3oTqS1M3K+tGNpWg8cxr+WkrrkkdQ1glH4i0Os7YeltaqvZZ\n\tUohG0/ujr1r4Zk/w1gjbkVtmtm5OztSgq+JBE1sFKXA==","X-Received":"by 2002:a05:651c:906:b0:389:f0d9:398c with SMTP id\n 38308e7fff4ca-38d92dd7601mr56152441fa.31.1775568634530; Tue, 07 Apr 2026\n 06:30:34 -0700 (PDT)","Precedence":"bulk","X-Mailing-List":"linux-gpio@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","References":"<20260402-baytrail-real-swnode-v2-0-6f5054a4cc07@oss.qualcomm.com>\n <20260402-baytrail-real-swnode-v2-1-6f5054a4cc07@oss.qualcomm.com>\n \n \n \n ","In-Reply-To":"\n ","From":"Bartosz Golaszewski ","Date":"Tue, 7 Apr 2026 15:30:17 +0200","X-Gmail-Original-Message-ID":"\n ","X-Gm-Features":"AQROBzBMrZ5OueRzPU9GuzizwvAVvNCpC1VwkP67KUbTRzmFKPR0cmXYe3F1Qxs","Message-ID":"\n ","Subject":"Re: [PATCH v2 1/4] software node: return -ENXIO when referenced\n swnode is not registered yet","To":"Dmitry Torokhov ","Cc":"Andy Shevchenko ,\n Bartosz Golaszewski ,\n Daniel Scally ,\n Heikki Krogerus ,\n Sakari Ailus ,\n Greg Kroah-Hartman ,\n \"Rafael J. Wysocki\" , Danilo Krummrich ,\n Mika Westerberg ,\n Andy Shevchenko , Linus Walleij ,\n Hans de Goede ,\n =?utf-8?q?Ilpo_J=C3=A4rvinen?= ,\n Len Brown , linux-acpi@vger.kernel.org,\n driver-core@lists.linux.dev, linux-kernel@vger.kernel.org,\n linux-gpio@vger.kernel.org, platform-driver-x86@vger.kernel.org","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable"}},{"id":3674201,"web_url":"http://patchwork.ozlabs.org/comment/3674201/","msgid":"","list_archive_url":null,"date":"2026-04-07T13:59:52","subject":"Re: [PATCH v2 1/4] software node: return -ENXIO when referenced\n swnode is not registered yet","submitter":{"id":8583,"url":"http://patchwork.ozlabs.org/api/people/8583/","name":"Andy Shevchenko","email":"andriy.shevchenko@linux.intel.com"},"content":"On Tue, Apr 07, 2026 at 12:57:29PM +0200, Bartosz Golaszewski wrote:\n> On Fri, Apr 3, 2026 at 8:07 PM Dmitry Torokhov\n> wrote:\n> > On Fri, Apr 03, 2026 at 09:29:38AM +0200, Bartosz Golaszewski wrote:\n> > > On Thu, Apr 2, 2026 at 10:43 PM Dmitry Torokhov\n> > > wrote:\n> > > > On Thu, Apr 02, 2026 at 04:35:34PM +0300, Andy Shevchenko wrote:\n> > > > > On Thu, Apr 02, 2026 at 02:54:26PM +0200, Bartosz Golaszewski wrote:\n\n...\n\n> > > Because -EPROBE_DEFER only makes sense in probe() context, while\n> > > fwnode_get_reference_args() may be called in many other situations.\n> >\n> > Exactly same argument applies to your follow-up change: gpiod_get()\n> > returning -EPROBE_DEFER only makes sense in probe context but it may be\n> > called in many other situations. Are you planning to change all places\n> > where gpiolib returns -EPROBE_DEFER to something else just in case it\n> > might be called outside of probe context?\n> \n> I'd argue that gpiod_get() should really be limited to being called at\n> probe() time but I see your point.\n\nThere is weird hardware that might need to switch GPIO from IRQ (input) to\noutput at runtime (at least some touchscreens functioning like that IIRC).\nBut I dunno if it requires gpiod_put()/gpiod_get() dances.\n\n> > -EPROBE_DEFER should have been called -ENOTREADY from the beginning and\n> > then we would not have this argument. Or, even better, we should have\n> > used -EAGAIN. But it is just a name, semantics does not really change.\n> > We want to signal that something is not ready and the operation needs be\n> > repeated. Currently we contorting ourselves by using yet another error\n> > code that everyone will either convert to -EPORBE_DEFER or will handle\n> > like -EAGAIN.\n> >\n> > > I think ENOTCONN as \"not connected\" makes sense, though the string\n> >\n> > Why is it better? Most of users of -ENOTCONN are in networking code so\n> > it is somewhat unexpected to have other APIs return it.\n> >\n> > > representation says: \"Transport endpoint is not connected\" which\n> > > doesn't spell out quite the same thing.\n> >\n> > Yes, because it is really for networking/sockets handling.\n\n> Andy et al: what is your take on this?\n\nI already commented on this while ago, and I think EPROBE_DEFER should be\nlimited as much as possible (and eventually killed for good). This is known\nhack to the Linux device model instead of doing it via some graphs that are\nconstructed during initialisation. There were talks and approaches how to\nsolve this using graph theory IIRC (i.o.w. mathematically proven).\n\nTo the current case, I think the fwnode/swnode APIs should be clean of\ndeferred probe hack, so I like Bart's patch.","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","linux-gpio@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256\n header.s=Intel header.b=KFjXiaUj;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c04:e001:36c::12fc:5321; helo=tor.lore.kernel.org;\n envelope-from=linux-gpio+bounces-34816-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com\n header.b=\"KFjXiaUj\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=198.175.65.21","smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=linux.intel.com","smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=linux.intel.com"],"Received":["from tor.lore.kernel.org (tor.lore.kernel.org\n [IPv6:2600:3c04:e001:36c::12fc:5321])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fqp0j2QfTz1yD3\n\tfor ; Wed, 08 Apr 2026 00:07:01 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby tor.lore.kernel.org (Postfix) with ESMTP id 11C86307B376\n\tfor ; Tue, 7 Apr 2026 14:00:02 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 83DF03B8958;\n\tTue, 7 Apr 2026 14:00:00 +0000 (UTC)","from mgamail.intel.com (mgamail.intel.com [198.175.65.21])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id 1985A3B636E;\n\tTue, 7 Apr 2026 13:59:58 +0000 (UTC)","from fmviesa002.fm.intel.com ([10.60.135.142])\n by orvoesa113.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;\n 07 Apr 2026 06:59:59 -0700","from pgcooper-mobl3.ger.corp.intel.com (HELO localhost)\n ([10.245.244.182])\n by fmviesa002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;\n 07 Apr 2026 06:59:54 -0700"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1775570400; cv=none;\n b=ooty5LvFLa9SUkOmsZX1+/yvlhIZZQjTAOtWsZ3UADMALcB8hYqhEHlT8KEZZ49aHq2WrMKMK8F/QkGa0MJF5rAYMOZ2LOm+B8rZj2LBSVZqpZcEWGJ280p/Uh9GIKG1hPP1MKvytYTlB/z5+azO85y6CpQlE70wpAnsNUkCXTY=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1775570400; c=relaxed/simple;\n\tbh=H3Fo4J2NVU0PFRfCQAwlJEgYC6mqn4kJRkIsmg1rNmQ=;\n\th=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:\n\t Content-Type:Content-Disposition:In-Reply-To;\n b=PK9GZqk2X+OEoNWMjSf4y3pi0zwpaJExTQLQdJUAWJhrPee8AT/7S5hwXzGAP6codUQ47mL3htxRUs0pQD5GKWTDCuy9CB72wbTjI0TG0SPXkxS6HN3pzubBmBJgtWIdfICUDrrtCHwy9iwvWgHDf+eAQkPYJn3Ae7bLAibX7Ks=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=linux.intel.com;\n spf=pass smtp.mailfrom=linux.intel.com;\n dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com\n header.b=KFjXiaUj; arc=none smtp.client-ip=198.175.65.21","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple;\n d=intel.com; i=@intel.com; q=dns/txt; s=Intel;\n t=1775570399; x=1807106399;\n h=date:from:to:cc:subject:message-id:references:\n mime-version:content-transfer-encoding:in-reply-to;\n bh=H3Fo4J2NVU0PFRfCQAwlJEgYC6mqn4kJRkIsmg1rNmQ=;\n b=KFjXiaUjrQBaUb7SBE2M+hlt2hCUGWcOpEkNOq7zK/MO970unci8Waty\n vUFnE5XiA0uf09PTop5vKWr377HfdfJnnyVMdqrG6/q9wU8bzUaim33j7\n Pg0AUyjXr9C5JnF2DSuRtXnUb7SR1ORYKCAnVJfDs1vhRB/zdaUV7X9UA\n 3DY2aT0c/5rSJcXGlabM1o4udVDRPOUdollXX2qHpGBEg7+ij6DnmlQwM\n fV6Uo6PvuzrA5NzbvhWcg53PvRYx0SwTv55PdNtKVsHGx8u/W5yhWQPJa\n E2MhGkQJm/hV46OczP85cIj8qgXWtr//R3VtGR4/5pH88h6aPYv8Vtsrj\n g==;","X-CSE-ConnectionGUID":["wozY9WhbSWaxH2KWOTaGUQ==","IGZNhBObRoOtINcVfkMZIw=="],"X-CSE-MsgGUID":["n967fMBuTAeldXDhtCfT+Q==","EdV9wd8jR22m7NUwFtblFA=="],"X-IronPort-AV":["E=McAfee;i=\"6800,10657,11752\"; a=\"76416502\"","E=Sophos;i=\"6.23,165,1770624000\";\n d=\"scan'208\";a=\"76416502\"","E=Sophos;i=\"6.23,165,1770624000\";\n d=\"scan'208\";a=\"251309532\""],"X-ExtLoop1":"1","Date":"Tue, 7 Apr 2026 16:59:52 +0300","From":"Andy Shevchenko ","To":"Bartosz Golaszewski ","Cc":"Dmitry Torokhov ,\n Bartosz Golaszewski ,\n Daniel Scally ,\n Heikki Krogerus ,\n Sakari Ailus ,\n Greg Kroah-Hartman ,\n \"Rafael J. Wysocki\" , Danilo Krummrich ,\n Mika Westerberg ,\n Andy Shevchenko , Linus Walleij ,\n Hans de Goede ,\n Ilpo =?iso-8859-1?q?J=E4rvinen?= ,\n Len Brown , linux-acpi@vger.kernel.org,\n driver-core@lists.linux.dev, linux-kernel@vger.kernel.org,\n linux-gpio@vger.kernel.org, platform-driver-x86@vger.kernel.org","Subject":"Re: [PATCH v2 1/4] software node: return -ENXIO when referenced\n swnode is not registered yet","Message-ID":"","References":"<20260402-baytrail-real-swnode-v2-0-6f5054a4cc07@oss.qualcomm.com>\n <20260402-baytrail-real-swnode-v2-1-6f5054a4cc07@oss.qualcomm.com>\n \n \n \n \n ","Precedence":"bulk","X-Mailing-List":"linux-gpio@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","Content-Transfer-Encoding":"8bit","In-Reply-To":"\n ","Organization":"Intel Finland Oy - BIC 0357606-4 - c/o Alberga Business Park, 6\n krs, Bertel Jungin Aukio 5, 02600 Espoo"}}]