From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lf1-f42.google.com (mail-lf1-f42.google.com [209.85.167.42]) (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 9CFB2299948 for ; Wed, 29 Apr 2026 05:53:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777442003; cv=none; b=hCJlsgoU7obMSoK6K6/N6T5/LecDEUsmkFgNClvoAlbkZCM4O0dbtUrBzHuZkbAcWhDgFdqhKJduRUEadpGh59SKOndIkLct3hI8jI3ZdjN8FJwrxQ9egoao6eQtINjuXYKrw3TbnU3IEKc84CJkeBcChezrydSgwBlzBbRYGn4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777442003; c=relaxed/simple; bh=U4vTOXDBuqRxm6MFu6SmRXuuAA/rgx7l0h6xmhiOz2s=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=gAeONZCO5FAxDsUspsqUJRrYIZa7u+AeurSrbntIi0XpLPDp+Ou2S9xDGBmKp3fvtpNCJdAoZIvYEaT521OHS8hr5NUQGOqTxt/MHpmA/2iuHxz3ML3tOsaghrisJfNNQPb9Pcdn9t+x++50Ovcuwt3uLHX8wWKlobFg0sT75Gk= 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=X18e6Pvt; arc=none smtp.client-ip=209.85.167.42 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="X18e6Pvt" Received: by mail-lf1-f42.google.com with SMTP id 2adb3069b0e04-5a748d5ece4so997349e87.2 for ; Tue, 28 Apr 2026 22:53:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1777442000; x=1778046800; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=6n16uGT/0/t4d1YijajME6BhM7VCNicuTLQuYVZLPNc=; b=X18e6PvthTFJ57a3OCIsVr3Aazha51SUW9aUXRK52uaXnzHV9ighp/1e8ETLoGj0wF 2wNrAXBPakXS+2Pr8rHy9IlMyVRCJdfwkH2jOXXaMtzfEviI0e52N1uWENIXxLvQ1bOp bqqfkucmvfJaa2ymQ87Arqzeopm/9W/5bkRktJ6XMaXeIWq171hjWWxfJ/seKMRpcuRM fjxwTbapCwkLEVHcWIWpBozILMZdkSO8P0kTBobx3e53TapcsZaqgnuN3JNq2zUCJ/Yz +AWS3w36ifJ/l6EN4PI9XB1imQ6RP8fEyt5FTR0FC8fMN1GHCjYj/o+od7/Q81mkjlAM //nQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777442000; x=1778046800; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=6n16uGT/0/t4d1YijajME6BhM7VCNicuTLQuYVZLPNc=; b=GUk63Tr7gDrKPaWwh4SRCX9YPDd+VLNMiWtFbPJREYzFAX0xKey49/jKqWylqNXEic HRQXKDacdftD5BrUyRT1EUp0+R7U8BZS2yNH0Xa1dy8zWh8tELl/tKnbScdRN25huvas el7Bq1MH7A8SsQYA32hOnkyAGZWMvGExWQu2lInJJBHQOtOixOTDyhpDbRWX8UDWIdo5 nIFlUAkaMe7D5Mo1VjrUm0pRT+S33knwowUYzcvrVAWecfOPQi7Wuj61Q1K7ElGBYKTD OmYg1gLzqDYY3cqoLmSuDQndezMWt4YKRfEFZ6FmsnOFBzVw65sjZTjO6A7fLNvTEAK9 S+YQ== X-Forwarded-Encrypted: i=1; AFNElJ/BmVzw8NfhfTjNB1I+U3ezc9nPH76F51oaiMgedhFEqvSsA/XVDWSNBa5LuEYMGW9wexsHp6Vov6Mh9c4=@vger.kernel.org X-Gm-Message-State: AOJu0YwC5qW10aPSzHmdnejTzc5QqmxqY7jmEoH5snBY34aiJhCwaqm/ 73cnHdg6zXvt5CasG52X8FtsBTR5VWt/X7Zf2YRk8EHjR8ArytRtIwlz X-Gm-Gg: AeBDiesAPiuvzntfLk5+BpidwK94wWFQ+951+yhytW5o5oeP5DLzWwvmMRs8DudGdxH 2GW1bALb7rBV95jwLAU0EERK1iM7tB3nXQJqTH4+GSHdPiuzhf0/GTyBbIEhETX0R5Ifgvk2+k2 fMYVvCujHYu2uikv+pRHzJB8MlJVxEtAraURNRgk+rSrxmXJavu63LKMVhIZZaBHnALRWYjQI51 VaZydBc9bsjWslH4s7uVgbuKGr1qlkj+A3R7EHiEORE+LHY2FI6W2dH8SL0IFQPNnzx23wNBuYw cY9LCnzN8V/mL2aiuUznyEGo4DGA+FqXk83Tt1YIoHql1XpXCYZzqNqW00JwCJ/Au2tW/wnAfxT c3iMXMhD30tro+Z0BOG9EIXg066MrBF52q3aGq3FlQ4LhGO5lOaTZxvY8ygV/cr5hxWYuptzeyA G3RPXc7xV1VNIio7c/G4I9bLTTRb03RIrUB0yw7RVJJ5mKSwbwvPsj+nbcvC8jkbdYweIvFnn/b NMLlz3OdkMJgOX7BiM= X-Received: by 2002:a05:6512:6d0:b0:5a4:56:aa88 with SMTP id 2adb3069b0e04-5a749d21f18mr680742e87.27.1777441999401; Tue, 28 Apr 2026 22:53:19 -0700 (PDT) Received: from ?IPV6:2a10:a5c0:800d:dd00:8fdf:935a:2c85:d703? ([2a10:a5c0:800d:dd00:8fdf:935a:2c85:d703]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5a74a6f841csm266687e87.30.2026.04.28.22.53.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 28 Apr 2026 22:53:17 -0700 (PDT) Message-ID: <391d679c-0d93-456a-977e-2b26b8135db9@gmail.com> Date: Wed, 29 Apr 2026 08:53:16 +0300 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: [PATCH v4 1/2] mfd: rohm-bd71828: Use software nodes for gpio-keys To: Dmitry Torokhov , Lee Jones Cc: Arnd Bergmann , linux-kernel@vger.kernel.org References: <20260427-rohm-software-nodes-v4-0-ffeb5b0c4774@gmail.com> <20260427-rohm-software-nodes-v4-1-ffeb5b0c4774@gmail.com> Content-Language: en-US, en-AU, en-GB, en-BW From: Matti Vaittinen In-Reply-To: <20260427-rohm-software-nodes-v4-1-ffeb5b0c4774@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Dee Ho, Thanks a ton Dmitry! This is looking very good to me now. I only have one question below. On 28/04/2026 07:13, Dmitry Torokhov wrote: > Refactor the rohm-bd71828 MFD driver to use software nodes for > instantiating the gpio-keys child device, replacing the old > platform_data mechanism. > > The power key's properties are now defined using software nodes and > property entries. The IRQ is passed as a resource attached to the > platform device. > > This will allow dropping support for using platform data for configuring > gpio-keys in the future. > > Signed-off-by: Dmitry Torokhov > --- > drivers/mfd/rohm-bd71828.c | 122 +++++++++++++++++++++++++++++++++------------ > 1 file changed, 90 insertions(+), 32 deletions(-) > > diff --git a/drivers/mfd/rohm-bd71828.c b/drivers/mfd/rohm-bd71828.c > index a79f354bf5cb..a8bdb9c955a4 100644 > --- a/drivers/mfd/rohm-bd71828.c > +++ b/drivers/mfd/rohm-bd71828.c //snip > +static int bd71828_i2c_register_pwrbutton(struct device *dev, int button_irq, > + struct irq_domain *irq_domain) > +{ > + static const struct property_entry bd71828_powerkey_parent_props[] = { > + PROPERTY_ENTRY_STRING("label", "bd71828-pwrkey"), > + { } > + }; > + static const struct property_entry bd71828_powerkey_props[] = { > + PROPERTY_ENTRY_U32("linux,code", KEY_POWER), > + PROPERTY_ENTRY_BOOL("wakeup-source"), > + { } > + }; > + const struct resource res[] = { > + DEFINE_RES_IRQ_NAMED(button_irq, "bd71828-pwrkey"), > + }; > + struct mfd_cell gpio_keys_cell = { > + .name = "gpio-keys", > + .resources = res, > + .num_resources = ARRAY_SIZE(res), > + }; > + struct software_node *nodes; > + int error; > + > + nodes = devm_kcalloc(dev, 2, sizeof(*nodes), GFP_KERNEL); > + if (!nodes) > + return -ENOMEM; > + > + /* Node corresponding to gpio-keys device itself */ > + nodes[0].name = devm_kasprintf(dev, GFP_KERNEL, "%s-power-key", dev_name(dev)); > + if (!nodes[0].name) > + return -ENOMEM; Do we have any guidance/rules for naming the swnodes similar to devicetree nodes? Do they need to be unique, and are they used for anything? I am wondering if the dev_name() is needed or if we should have some 'numbering'? I am not sure if the node names can be used for anything, but in some cases adding IC-type to names will hurt the "generic usability". On the other hand, if names need to be unique, then some numbering might be needed (although, this is not critical for this driver as it is very unlikely there is a system with more than one of these PMICs). Huh. I feel the "generic usability" is not too accurately said... As one example, I have added IC-type in IRQ names declared in MFD driver. Later, when same RTC driver was used to support multiple ICs, getting IRQ resources in RTC had to be done separately for each IC-variant just because the IRQ names contained the IC-type. No idea if there is any use for swnode names, so I don't know if this makes sense for them. This is a 'nit'. I am fine with a simple reply that the naming is not a concern here - just thought that perhaps it matters :) With that clarified: Reviewed-by: Matti Vaittinen --- Matti Vaittinen Linux kernel developer at ROHM Semiconductors Oulu Finland ~~ When things go utterly wrong vim users can always type :help! ~~