From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-177.mta0.migadu.com (out-177.mta0.migadu.com [91.218.175.177]) (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 C92B2199381 for ; Wed, 30 Oct 2024 16:45:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.177 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1730306745; cv=none; b=KSbQr/NTw0oBLrRyaa1NCzdbFAoiuAx9iGq2U5fR/uD1H7+uhE1AsIpUb2UsFlMSx1zI5miSWfRyrlBmSzAwSiLBDYHqtbN/MCKHyIB/rjFE+heCwtFM5B0CriURzoswp40aL5j5dFRxqIEsTAoBdJHWgtkTGLgoFp0ISCscAfE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1730306745; c=relaxed/simple; bh=hcFBMSRwI7XyLVXiwju9iNxMgHCXtPSFdswCTiWGT8A=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=ECFXEZDO8bkmDTvRQ+0YwB57ZUEduqU0vnz43RPv2eYdm0zWlkQWl7fQasp2SiQfQ1LmxkUskUJcaev6jCGzPQoJ0ThsWQDIzPOpwy3IDEtCBmvZ1FjEI/AtBAfgshjGy21+bRd9zGD0Bd3aBi6e/+v30WFh0kKnmnSQJLnFMX8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=nFJ/Pnzu; arc=none smtp.client-ip=91.218.175.177 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="nFJ/Pnzu" Message-ID: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1730306737; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=2IImZ1cZVsIXJIGIFBIuoTjHne0xPtt9XDcxUzdxcbs=; b=nFJ/PnzuiZtjPkvI0PKl64gdNlEDUbL7oSAq78a1QvDclqZGoe1La2Ah6XdSp1vzNooun7 bCwWvVAvHmL8gchTeI60zfM3b/WoGPP/2zLD0EmFLUI0Odu5eYChun3lBUKye2a73LAIIs yadQopyWqNnFMUSZFHBPqPAtYd1KtN8= Date: Thu, 31 Oct 2024 00:45:24 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH v2] drm/bridge: Fix assignment of the of_node of the parent to aux bridge To: Dmitry Baryshkov , Abel Vesa Cc: Andrzej Hajda , Neil Armstrong , Robert Foss , Laurent Pinchart , Jonas Karlman , Jernej Skrabec , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , Johan Hovold , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org References: <20241018-drm-aux-bridge-mark-of-node-reused-v2-1-aeed1b445c7d@linaro.org> Content-Language: en-US X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Sui Jingfeng In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT Hi, On 2024/10/18 23:43, Dmitry Baryshkov wrote: > On Fri, Oct 18, 2024 at 03:49:34PM +0300, Abel Vesa wrote: >> The assignment of the of_node to the aux bridge needs to mark the >> of_node as reused as well, otherwise resource providers like pinctrl will >> report a gpio as already requested by a different device when both pinconf >> and gpios property are present. >> Fix that by using the device_set_of_node_from_dev() helper instead. >> >> Fixes: 6914968a0b52 ("drm/bridge: properly refcount DT nodes in aux bridge drivers") >> Cc: stable@vger.kernel.org # 6.8 >> Cc: Dmitry Baryshkov >> Signed-off-by: Abel Vesa >> --- >> Changes in v2: >> - Re-worded commit to be more explicit of what it fixes, as Johan suggested >> - Used device_set_of_node_from_dev() helper, as per Johan's suggestion >> - Added Fixes tag and cc'ed stable >> - Link to v1: https://lore.kernel.org/r/20241017-drm-aux-bridge-mark-of-node-reused-v1-1-7cd5702bb4f2@linaro.org >> --- >> drivers/gpu/drm/bridge/aux-bridge.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> > Reviewed-by: Dmitry Baryshkov Technically speaking, your driver just move the burden to its caller. Because this driver requires its user call drm_aux_bridge_register() to create an AUX child device manually, you need it call ida_alloc() to generate a unique id. Functions symbols still have to leak to other subsystems, which is not really preserve coding sharing. What's worse, the action that allocating unique device id traditionally is the duty of driver core. Why breaks (so called) perfect device driver model by moving that out of core. Especially in the DT world that the core knows very well how to populate device instance and manage the reference counter. HPD handling is traditionally belongs to connector, create standalone driver like this one *abuse* to both Maxime's simple bridge driver and Laurent's display-connector bridge driver or drm_bridge_connector or whatever. Why those work can't satisfy you? At least, their drivers are able to passing the mode setting states to the next bridge. Basically those AUX drivers implementation abusing the definition of bridge, abusing the definition of connector and abusing the DT. Its just manually populate instances across drivers. -- Best regards, Sui