From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx.nabladev.com (mx.nabladev.com [178.251.229.89]) (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 175262BD01B; Wed, 13 May 2026 11:33:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=178.251.229.89 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778671990; cv=none; b=Tl2QGjoWpeV/4K6iQH8EVQQTB41Fagje97vfH3+svWkrQRxND77R/qf03JDZTP/gN4j6mPlQHdw2Hd2TxK3nUS/UBcXQkKIZtXqDrAN9dfwDshjnFWsLbNx59rSRM7xBAj5F8FRWWuxy9x4wx4wcTM/IeUY9qKfOsWLuMflslYw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778671990; c=relaxed/simple; bh=oGroFmISTnnmtt7Tkt5y+mWF4Yhe9IX4X6OC5iYpAvo=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=fZc7GnEszuMdTd58xaVh4OFVZYZjGZc2/m8X0chwQddPSjYIUpQqdTHvWTMiqa4hPxXFMHpp2wRWbplS+U0oulxKS50mW3UpZRqk118VcDde1tU81GfMe/aOJvCc2+LoMLtomCdTjFep/MEfnic1IDVmra8Cy710PJn/VsXLyCY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=nabladev.com; spf=pass smtp.mailfrom=nabladev.com; dkim=pass (2048-bit key) header.d=nabladev.com header.i=@nabladev.com header.b=b9lvXIU0; arc=none smtp.client-ip=178.251.229.89 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=nabladev.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=nabladev.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=nabladev.com header.i=@nabladev.com header.b="b9lvXIU0" Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id BB83D106308; Wed, 13 May 2026 13:33:02 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nabladev.com; s=dkim; t=1778671986; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:content-language:in-reply-to:references; bh=j5ITm7R7s1aHVjiSOgAJ7t7iQ6cNC224p19NsnVO0qk=; b=b9lvXIU0g7qmVXmoOGL3PL/7ib44JYd41OxFzVVugFKsf8P43t97vGwb6Iouc536PMvLJ1 zDbhJOyO+dATRbZ3LGtcDtHnGjPYMya+wPGG/VUoZwU2gk8i77AXzrI+wrcCsZy1sv/VsE WeaI2AqKY0wnG77Yp0WnmXQkMj0+PBhqHvkM2p3YVXaryghoGzmodey+YYpyt9MShDaPJv d1sQCHLbOY7eOt3pIoyxTfaEsZWuKkCa/UpztB3WsCfyhniRqFpZT52ufXktM+51RfTqH/ WiClZL+8vZvNcrz2qRNXNhPV8dlm1hufborS4P05G03g72gHJhXpRDlMoLwQRw== Message-ID: Date: Wed, 13 May 2026 13:33:01 +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 Subject: Re: [PATCH 2/2] drm/bridge: lt9211: Add drive-strength-microamp DT property To: =?UTF-8?B?QsO2cmdlIFN0csO8bXBmZWw=?= Cc: Andrzej Hajda , Neil Armstrong , Robert Foss , Laurent Pinchart , Jonas Karlman , Jernej Skrabec , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , Rob Herring , Krzysztof Kozlowski , Conor Dooley , dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org References: <20260512164609.3390700-1-bstruempfel@data-modul.com> <20260512164609.3390700-3-bstruempfel@data-modul.com> Content-Language: en-US From: Marek Vasut In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Last-TLS-Session-Version: TLSv1.3 On 5/13/26 11:02 AM, Börge Strümpfel wrote: [...] >>> + ctx->lvds_hsdrv_isel = 8; /* default: 25 uA */ >>> + ret = of_property_read_u32(dev->of_node, "drive-strength-microamp", >>> + µamp); >> >> if ret != 0 , then what happens here ? >> > > if ret != 0, we will keep the default value of 8 (corresponding to 25 uA > as written above), which is the behavior that the driver had previously. > > According to the documentation, of_property_read_u32() will return 0 on > success, -EINVAL if the property does not exist, -ENODATA if property > does not have a value, and -EOVERFLOW if the property data isn't large > enough. I think we only would need to give a warning or similar if the > -ENODATA or -EOVERFLOW cases. However, I personally do not think that is > necessary, as the usage is specified unambiguously in the devicetree > bindings. Users can pass in malformed DT, so a warning is a good idea. Thanks.