From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 3332BC6FA82 for ; Wed, 28 Sep 2022 11:01:09 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id B500510E42F; Wed, 28 Sep 2022 11:01:07 +0000 (UTC) Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) by gabe.freedesktop.org (Postfix) with ESMTPS id 7E64510E42F for ; Wed, 28 Sep 2022 11:00:56 +0000 (UTC) Received: by mail-wr1-x430.google.com with SMTP id z6so19242526wrq.1 for ; Wed, 28 Sep 2022 04:00:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date; bh=Vmh28mTnRu63ezVpuO/VYJZBKc7bNMAcTpkijNYdpyA=; b=eWsdi58eEi2d+xAwZU365etNANXaKeUbz6X79IbCm9H9HsBdqAZugvQDvVLOABzfB0 p3zLdfC7XmaOYbVCe9leZRYVvjlL4ArmzkzWiprCKuXkt9XKBVuXWNa4uAdZTyuq40EQ HfSpyxljjlafgudMxvIWMNsAWgOkm/q1fiIPhFmehyHQPsbeEqB6owfjKFJYOAwrPTOf K/iP4Z+9nlvV/3435cCK+JiuiTG/UX1dmN6QJ+l3+IVs8yxtftML/ncExEdmBpgZJlFO URJslWFayRQYLbYPjYUaGWde4zDVq45Rfppg2OCn6ATDWXhUJiQF1iJlmcyQgy1BPsDl lZAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date; bh=Vmh28mTnRu63ezVpuO/VYJZBKc7bNMAcTpkijNYdpyA=; b=yySN8TvbqxATLn+W/6zLkiYq5MmbtZnI2dcfmpysxDyHoNqnwWKWqlXpPvs9AOhClR Dk9nHhwi3zP2ooSJQMWPwmzp11mIobI0M2DSZWqU4vhucN/RklKNl7tG+e/Vj5WJQHwT UWGrqLfhwfI6F4BSwwuCZSNwil1AvCO3Djifd6Zf+RsZKyjrDDEpNdDn28Ab41/yzuru qzdNERbweTyoOFfuiVnkCNDPO34yXDRmp+5KoJJmfFmAmmxb1/lG0UEs6Mdwe550a0Bx 2f3u9kejRDA0IVCadHb+Njgz346oB7G1aTqewx+AKItiPSNpRzYI0/SpV+Q8wiADvgFi neig== X-Gm-Message-State: ACrzQf3tJA+Ia/36HlxvdTlIMwkpaKruUt2dTtUIADVPQvy0kn1BCGMh fJz1yGsXZTP6PuaMQl7tNzuv1w== X-Google-Smtp-Source: AMsMyM6CwwVXxXr1iKOfbH0C0zBuHDeMEcKc5KNkjaOdpkrjKkMaH6ADg7D9oJX5c11no20O0U5aLA== X-Received: by 2002:a5d:6808:0:b0:22a:c437:5b36 with SMTP id w8-20020a5d6808000000b0022ac4375b36mr20216420wru.459.1664362854849; Wed, 28 Sep 2022 04:00:54 -0700 (PDT) Received: from maple.lan (cpc141216-aztw34-2-0-cust174.18-1.cable.virginm.net. [80.7.220.175]) by smtp.gmail.com with ESMTPSA id x4-20020adfdcc4000000b0022b11a27e39sm4035884wrm.1.2022.09.28.04.00.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 28 Sep 2022 04:00:54 -0700 (PDT) Date: Wed, 28 Sep 2022 12:00:51 +0100 From: Daniel Thompson To: Dmitry Torokhov Subject: Re: [RFC/PATCH] backlight: hx8357: prepare to conversion to gpiod API Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Jingoo Han , Sascha Hauer , Lee Jones , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Rob Herring , NXP Linux Team , Krzysztof Kozlowski , Shawn Guo , linux-arm-kernel@lists.infradead.org Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Tue, Sep 27, 2022 at 03:32:35PM -0700, Dmitry Torokhov wrote: > Properties describing GPIOs should be named as "-gpios" or > "-gpio", and that is what gpiod API expects, however the > driver uses non-standard "gpios-reset" name. Let's adjust this, and also > note that the reset line is active low as that is also important to > gpiod API. No objections to the goal but... > Signed-off-by: Dmitry Torokhov > --- > > Another option is to add another quirk into gpiolib-of.c, but we > may end up with a ton of them once we convert everything away from > of_get_named_gpio() to gpiod API, so I'd prefer not doing that. ... it is unusual to permit backwards incompatible changes to the DT bindings[1]: creating "flag days" where hardware stops functioning if you boot an new kernel with an old DT is a known annoyance to users. I usually favour quirks tables or similar[2] rather than break legacy DTs. Very occasionally I accept (believable) arguments that no legacy DTs actually exist but that can very difficult to verify. Overall I'd like to solicit views from both GPIO and DT maintainers before rejecting quirks tables as a way to help smooth these sort of changes (or links to ML archives if this has already been discussed). [1] For this particular driver the situation is muddied slightly because it looks like complex since it looks the bindings for himax,hx8357 and himax,hx8369 are undocumented (and badly named). [2] When the property is not parsed by library code mostly we handle legacy by consuming both new or old names in the parser code. > diff --git a/drivers/video/backlight/hx8357.c b/drivers/video/backlight/hx8357.c > index 9b50bc96e00f..41332f48b2df 100644 > --- a/drivers/video/backlight/hx8357.c > +++ b/drivers/video/backlight/hx8357.c > @@ -601,7 +601,7 @@ static int hx8357_probe(struct spi_device *spi) > if (!match || !match->data) > return -EINVAL; > > - lcd->reset = of_get_named_gpio(spi->dev.of_node, "gpios-reset", 0); > + lcd->reset = of_get_named_gpio(spi->dev.of_node, "reset-gpios", 0); > if (!gpio_is_valid(lcd->reset)) { > dev_err(&spi->dev, "Missing dt property: gpios-reset\n"); > return -EINVAL; Daniel. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id F25ACC6FA82 for ; Wed, 28 Sep 2022 11:02:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234165AbiI1LCr (ORCPT ); Wed, 28 Sep 2022 07:02:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52756 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233895AbiI1LBI (ORCPT ); Wed, 28 Sep 2022 07:01:08 -0400 Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 76688270C for ; Wed, 28 Sep 2022 04:00:56 -0700 (PDT) Received: by mail-wr1-x435.google.com with SMTP id n10so19147701wrw.12 for ; Wed, 28 Sep 2022 04:00:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date; bh=Vmh28mTnRu63ezVpuO/VYJZBKc7bNMAcTpkijNYdpyA=; b=eWsdi58eEi2d+xAwZU365etNANXaKeUbz6X79IbCm9H9HsBdqAZugvQDvVLOABzfB0 p3zLdfC7XmaOYbVCe9leZRYVvjlL4ArmzkzWiprCKuXkt9XKBVuXWNa4uAdZTyuq40EQ HfSpyxljjlafgudMxvIWMNsAWgOkm/q1fiIPhFmehyHQPsbeEqB6owfjKFJYOAwrPTOf K/iP4Z+9nlvV/3435cCK+JiuiTG/UX1dmN6QJ+l3+IVs8yxtftML/ncExEdmBpgZJlFO URJslWFayRQYLbYPjYUaGWde4zDVq45Rfppg2OCn6ATDWXhUJiQF1iJlmcyQgy1BPsDl lZAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date; bh=Vmh28mTnRu63ezVpuO/VYJZBKc7bNMAcTpkijNYdpyA=; b=qPrbrKfDYZv06xFPOsgT9mjjkPnTU8qmCqBFOoAXgBSNxoHJgsG0mLKkisL0uPTFG1 yolUSRK0QNNt7rAhgP+S5fQ9FVs0HP1kh1rGdh3UxkyNfayheuZP5wdDfWme3xpUDD8a JyPZ6cNRPDqikJwuUmRi49pOt+ZF4QnMMWm+BeMKx9sSKaWOSdF2htwsdJP7GkJ+FE/W VvBxprnyLYah+NHMs6LF4wj6+RIKW9b41107YOWpWcvm3Ykxmz/zGAx1AlAlqwe3zTiE spSrO0ghWCjSUwSnx88ltfCkFPAUV24Es08ZmPMTtl5Zgt4AB0zpSJko1x7JScrpsJFR tbrg== X-Gm-Message-State: ACrzQf3I6b9pR7Bzecp/BbMK87mvk3T1+otQjGLMeaDOU5pszUHqPokp ZFZzVasnQGxuC/6rHp7H4GTbHfJDLup8ZK+1 X-Google-Smtp-Source: AMsMyM6CwwVXxXr1iKOfbH0C0zBuHDeMEcKc5KNkjaOdpkrjKkMaH6ADg7D9oJX5c11no20O0U5aLA== X-Received: by 2002:a5d:6808:0:b0:22a:c437:5b36 with SMTP id w8-20020a5d6808000000b0022ac4375b36mr20216420wru.459.1664362854849; Wed, 28 Sep 2022 04:00:54 -0700 (PDT) Received: from maple.lan (cpc141216-aztw34-2-0-cust174.18-1.cable.virginm.net. [80.7.220.175]) by smtp.gmail.com with ESMTPSA id x4-20020adfdcc4000000b0022b11a27e39sm4035884wrm.1.2022.09.28.04.00.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 28 Sep 2022 04:00:54 -0700 (PDT) Date: Wed, 28 Sep 2022 12:00:51 +0100 From: Daniel Thompson To: Dmitry Torokhov Cc: Krzysztof Kozlowski , Rob Herring , Lee Jones , Jingoo Han , Shawn Guo , Sascha Hauer , Fabio Estevam , NXP Linux Team , Linus Walleij , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org Subject: Re: [RFC/PATCH] backlight: hx8357: prepare to conversion to gpiod API Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Sep 27, 2022 at 03:32:35PM -0700, Dmitry Torokhov wrote: > Properties describing GPIOs should be named as "-gpios" or > "-gpio", and that is what gpiod API expects, however the > driver uses non-standard "gpios-reset" name. Let's adjust this, and also > note that the reset line is active low as that is also important to > gpiod API. No objections to the goal but... > Signed-off-by: Dmitry Torokhov > --- > > Another option is to add another quirk into gpiolib-of.c, but we > may end up with a ton of them once we convert everything away from > of_get_named_gpio() to gpiod API, so I'd prefer not doing that. ... it is unusual to permit backwards incompatible changes to the DT bindings[1]: creating "flag days" where hardware stops functioning if you boot an new kernel with an old DT is a known annoyance to users. I usually favour quirks tables or similar[2] rather than break legacy DTs. Very occasionally I accept (believable) arguments that no legacy DTs actually exist but that can very difficult to verify. Overall I'd like to solicit views from both GPIO and DT maintainers before rejecting quirks tables as a way to help smooth these sort of changes (or links to ML archives if this has already been discussed). [1] For this particular driver the situation is muddied slightly because it looks like complex since it looks the bindings for himax,hx8357 and himax,hx8369 are undocumented (and badly named). [2] When the property is not parsed by library code mostly we handle legacy by consuming both new or old names in the parser code. > diff --git a/drivers/video/backlight/hx8357.c b/drivers/video/backlight/hx8357.c > index 9b50bc96e00f..41332f48b2df 100644 > --- a/drivers/video/backlight/hx8357.c > +++ b/drivers/video/backlight/hx8357.c > @@ -601,7 +601,7 @@ static int hx8357_probe(struct spi_device *spi) > if (!match || !match->data) > return -EINVAL; > > - lcd->reset = of_get_named_gpio(spi->dev.of_node, "gpios-reset", 0); > + lcd->reset = of_get_named_gpio(spi->dev.of_node, "reset-gpios", 0); > if (!gpio_is_valid(lcd->reset)) { > dev_err(&spi->dev, "Missing dt property: gpios-reset\n"); > return -EINVAL; Daniel. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 35E43C6FA82 for ; Wed, 28 Sep 2022 11:02:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=HSc4tLmscVA9vkvuojuasYurCf39RoDulOzl168MSLc=; b=w+YyGak9v4Y90h DpcUtaX/G2pbXbOo+HM9YrLltAHDmHKcnNZrDgNVVhHOYJLOdRoK8btfAHtSDzzAQ6aCyuFYf3Njs 3KG3Z5Rc97HYkDleh5Bw/EImOrIDyu4A1M5jshyMe4eQtcnsk4We6Ai5ZaqAAUo7KT1mAO60fCZeR tn44j6MvWGg3i+PeBGI0xTcqRoclUnZTFb97YbYiX7Iwn1Fs/bkvTd7EGsn/ALw+K6qof1p54fdBf yn+96eQfFaJ5jX64GYEApGuRnsDRGt2G9TjrSE0aEMr2oQztVMYBIsHmV3yZh0qmdyttqH1P7xwm1 W6lxHnY0PmJx/rLbluLA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1odUoH-00Fo5q-OU; Wed, 28 Sep 2022 11:01:04 +0000 Received: from mail-wr1-x433.google.com ([2a00:1450:4864:20::433]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1odUoD-00Fo1q-Cf for linux-arm-kernel@lists.infradead.org; Wed, 28 Sep 2022 11:00:58 +0000 Received: by mail-wr1-x433.google.com with SMTP id r7so19228786wrm.2 for ; Wed, 28 Sep 2022 04:00:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date; bh=Vmh28mTnRu63ezVpuO/VYJZBKc7bNMAcTpkijNYdpyA=; b=eWsdi58eEi2d+xAwZU365etNANXaKeUbz6X79IbCm9H9HsBdqAZugvQDvVLOABzfB0 p3zLdfC7XmaOYbVCe9leZRYVvjlL4ArmzkzWiprCKuXkt9XKBVuXWNa4uAdZTyuq40EQ HfSpyxljjlafgudMxvIWMNsAWgOkm/q1fiIPhFmehyHQPsbeEqB6owfjKFJYOAwrPTOf K/iP4Z+9nlvV/3435cCK+JiuiTG/UX1dmN6QJ+l3+IVs8yxtftML/ncExEdmBpgZJlFO URJslWFayRQYLbYPjYUaGWde4zDVq45Rfppg2OCn6ATDWXhUJiQF1iJlmcyQgy1BPsDl lZAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date; bh=Vmh28mTnRu63ezVpuO/VYJZBKc7bNMAcTpkijNYdpyA=; b=4va7UKtmViK07as8oMIkHdIKsOXBNkf3j+u5GOtMz8o4vM4L9GaQ0Y0Js5NjeYWg55 I4OKW88jqPsw2pr+MPkRmvyYgeOULPua+lKEbgrM0ReHLEfTXS6CN4v0p/WfwurZt2fz 9xjXXVCbU053hY5GDYU0zXNL2/f28AiiZ+nNu4daTgIbAmql5dGwssfnsl79g/HCHLHR SRYTOANGM4Seq9jtMIvZkdNNoNv0Lf/lriIwtyQOV5YcITp/ew8E3pllZtvO4eoeozNd 0tdQe/e4DFNnKNJHghUtftNa7INw7ZdIVN4rIdV4mI8gazLeJ3DhXxeEYV8ZHNoy44En l2Nw== X-Gm-Message-State: ACrzQf1xTb6smQ5Tds6O68K4rzOfoNhjcIW/TWOdtjOKDwqRMLr8JyhD wnsIASPwzGL4/8hwQxOUxVWFDQ== X-Google-Smtp-Source: AMsMyM6CwwVXxXr1iKOfbH0C0zBuHDeMEcKc5KNkjaOdpkrjKkMaH6ADg7D9oJX5c11no20O0U5aLA== X-Received: by 2002:a5d:6808:0:b0:22a:c437:5b36 with SMTP id w8-20020a5d6808000000b0022ac4375b36mr20216420wru.459.1664362854849; Wed, 28 Sep 2022 04:00:54 -0700 (PDT) Received: from maple.lan (cpc141216-aztw34-2-0-cust174.18-1.cable.virginm.net. [80.7.220.175]) by smtp.gmail.com with ESMTPSA id x4-20020adfdcc4000000b0022b11a27e39sm4035884wrm.1.2022.09.28.04.00.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 28 Sep 2022 04:00:54 -0700 (PDT) Date: Wed, 28 Sep 2022 12:00:51 +0100 From: Daniel Thompson To: Dmitry Torokhov Cc: Krzysztof Kozlowski , Rob Herring , Lee Jones , Jingoo Han , Shawn Guo , Sascha Hauer , Fabio Estevam , NXP Linux Team , Linus Walleij , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org Subject: Re: [RFC/PATCH] backlight: hx8357: prepare to conversion to gpiod API Message-ID: References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220928_040057_478379_62574993 X-CRM114-Status: GOOD ( 22.52 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Sep 27, 2022 at 03:32:35PM -0700, Dmitry Torokhov wrote: > Properties describing GPIOs should be named as "-gpios" or > "-gpio", and that is what gpiod API expects, however the > driver uses non-standard "gpios-reset" name. Let's adjust this, and also > note that the reset line is active low as that is also important to > gpiod API. No objections to the goal but... > Signed-off-by: Dmitry Torokhov > --- > > Another option is to add another quirk into gpiolib-of.c, but we > may end up with a ton of them once we convert everything away from > of_get_named_gpio() to gpiod API, so I'd prefer not doing that. ... it is unusual to permit backwards incompatible changes to the DT bindings[1]: creating "flag days" where hardware stops functioning if you boot an new kernel with an old DT is a known annoyance to users. I usually favour quirks tables or similar[2] rather than break legacy DTs. Very occasionally I accept (believable) arguments that no legacy DTs actually exist but that can very difficult to verify. Overall I'd like to solicit views from both GPIO and DT maintainers before rejecting quirks tables as a way to help smooth these sort of changes (or links to ML archives if this has already been discussed). [1] For this particular driver the situation is muddied slightly because it looks like complex since it looks the bindings for himax,hx8357 and himax,hx8369 are undocumented (and badly named). [2] When the property is not parsed by library code mostly we handle legacy by consuming both new or old names in the parser code. > diff --git a/drivers/video/backlight/hx8357.c b/drivers/video/backlight/hx8357.c > index 9b50bc96e00f..41332f48b2df 100644 > --- a/drivers/video/backlight/hx8357.c > +++ b/drivers/video/backlight/hx8357.c > @@ -601,7 +601,7 @@ static int hx8357_probe(struct spi_device *spi) > if (!match || !match->data) > return -EINVAL; > > - lcd->reset = of_get_named_gpio(spi->dev.of_node, "gpios-reset", 0); > + lcd->reset = of_get_named_gpio(spi->dev.of_node, "reset-gpios", 0); > if (!gpio_is_valid(lcd->reset)) { > dev_err(&spi->dev, "Missing dt property: gpios-reset\n"); > return -EINVAL; Daniel. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel