[PATCH v12 2/3] of: Factor arguments passed to of_map_id() into a struct
Krzysztof Kozlowski
krzk at kernel.org
Wed Apr 1 09:01:20 PDT 2026
On 31/03/2026 16:43, Frank Li wrote:
> On Tue, Mar 31, 2026 at 07:34:47PM +0530, Vijayanand Jitta wrote:
>> From: Charan Teja Kalla <charan.kalla at oss.qualcomm.com>
>>
>> Change of_map_id() to take a pointer to struct of_phandle_args
>> instead of passing target device node and translated IDs separately.
>> Update all callers accordingly.
>>
>> Add an explicit filter_np parameter to of_map_id() and of_map_msi_id()
>> to separate the filter input from the output. Previously, the target
>> parameter served dual purpose: as an input filter (if non-NULL, only
>> match entries targeting that node) and as an output (receiving the
>> matched node with a reference held). Now filter_np is the explicit
>> input filter and arg->np is the pure output.
>>
>> Previously, of_map_id() would call of_node_put() on the matched node
>> when a filter was provided, making reference ownership inconsistent.
>> Remove this internal of_node_put() call so that of_map_id() now always
>> transfers ownership of the matched node reference to the caller via
>> arg->np. Callers are now consistently responsible for releasing this
>> reference with of_node_put(arg->np) when done.
>>
>> Suggested-by: Rob Herring (Arm) <robh at kernel.org>
>> Suggested-by: Dmitry Baryshkov <dmitry.baryshkov at oss.qualcomm.com>
>> Signed-off-by: Charan Teja Kalla <charan.kalla at oss.qualcomm.com>
>> Signed-off-by: Vijayanand Jitta <vijayanand.jitta at oss.qualcomm.com>
>> ---
>> drivers/cdx/cdx_msi.c | 7 ++--
>> drivers/iommu/of_iommu.c | 4 +-
>> drivers/irqchip/irq-gic-its-msi-parent.c | 11 ++++--
>> drivers/of/base.c | 68 +++++++++++++++++---------------
>> drivers/of/irq.c | 10 ++++-
>> drivers/pci/controller/dwc/pci-imx6.c | 32 +++++++--------
>>
>> for imx part.
>>
>> Reviewed-by: Frank Li <Frank.Li at nxp.com>
So that's an Ack. Leaving a Rb tag for a tiny tiny piece of big patch
will give impression that everything is reviewed on v13. And the patch
was not reviewed by you.
If you cannot certify the reviewers statement of oversight then use acked
"For instance, maintainers may use it to signify that they are OK with a
patch landing, but they may not have reviewed it as thoroughly as if a
Reviewed-by: was provided."
"For example, if a patch affects multiple subsystems and has an
Acked-by: from one subsystem maintainer then this usually indicates
acknowledgement of *just the part which affects that maintainer's code.*"
Best regards,
Krzysztof
More information about the linux-arm-kernel
mailing list