Received: by 10.213.65.68 with SMTP id h4csp271008imn; Sat, 17 Mar 2018 03:22:35 -0700 (PDT) X-Google-Smtp-Source: AG47ELuHjVac8RP4R6Lc7b8omLxvYol/4yjzJVn3XZzWk87al9vRHQqVXY3mUZ0dfeZhxyBc/7er X-Received: by 10.99.110.5 with SMTP id j5mr3956496pgc.65.1521282155308; Sat, 17 Mar 2018 03:22:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521282155; cv=none; d=google.com; s=arc-20160816; b=EqX8dHTdgT1Qz6bOYg4TNS3+sQvCAlCqXoo2ZT7YB37D48vTRJCKKZNS70Sui9y7+2 u0Rr5n6IZA3et6nOaZ+Tr9Hu6nqWdUJwEfRYwpUii0BpZ4CiN7GOqutykesOV0ysa6N3 u84E5jNY58W+dFu4XkKSSG8z5p2MUEKUJwQlMs/Xcd/6sff+E+BUoGKwMuWC0beWhn2H WMXbWJbDhmJQnHLcmN1hiGG3irXasuzr+q1S11+e7Nqm18n9rZ++M9JBU9xWqPnusZ74 kfwBUvSjIyei+i0FcJReD9UlRHStmyw80e6zyY0rnMfmO+2P2/6et0li+gqv2Em9JzCi 3TYw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:to:references:message-id :content-transfer-encoding:cc:date:in-reply-to:from:subject :mime-version:arc-authentication-results; bh=swHRMJF2r3w7KFcX/6Bzv+DtrFi9InDoorrc3210I54=; b=rcHRd8qE92DswHX5CiE6PvCufX7Rw2BOyst90XNj5lRdUal47E8FE3R5xhSoHH93LJ fUBwZhggtWPuziJYTLGR+JMdlB+W6emhV7uyZLDckYLaKdV3i0P8es9jTSxjQJvcYc/k whUqg751ASJFnV2XQ3I55PR6ywWiNV/sq66Vd1payDzm2O+4/XN7Vzp9E2a6Hwca6PSZ LAPzQLtsedw5dDtQWApehClqHTmVhX5xZWWchTa0WSlz/1pZABxxHowf82/+rfnnHQAX hKjicNwVcey6+S3IvMKCwsSB6JaizqdlDlOEhlKiBp5D4LedyivtCOvNCjpXt+ZYtZDL GJwg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r22-v6si5030528pls.133.2018.03.17.03.22.21; Sat, 17 Mar 2018 03:22:35 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752577AbeCQKV3 convert rfc822-to-8bit (ORCPT + 99 others); Sat, 17 Mar 2018 06:21:29 -0400 Received: from outpost1.zedat.fu-berlin.de ([130.133.4.66]:54715 "EHLO outpost1.zedat.fu-berlin.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752381AbeCQKV1 (ORCPT ); Sat, 17 Mar 2018 06:21:27 -0400 Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1ex8xm-002cki-HT>; Sat, 17 Mar 2018 11:21:22 +0100 Received: from mp76f1fb1f.ap.nuro.jp ([118.241.251.31] helo=[100.97.66.201]) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1ex8xl-0024S9-8H>; Sat, 17 Mar 2018 11:21:22 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: [RFC 2/4] sh: ecovec24: conditionally register backlight device From: John Paul Adrian Glaubitz X-Mailer: iPhone Mail (15D100) In-Reply-To: <20180317092516.g5p5ybka57abyhex@apu3b> Date: Sat, 17 Mar 2018 19:21:17 +0900 Cc: Dmitry Torokhov , Laurent Pinchart , Lee Jones , Daniel Thompson , Jingoo Han , linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-sh@vger.kernel.org, Yoshinori Sato , Rich Felker , Linus Walleij Content-Transfer-Encoding: 8BIT Message-Id: <02834805-5053-4BDC-9256-DF1AFFEC8630@physik.fu-berlin.de> References: <20180315224202.96668-1-dmitry.torokhov@gmail.com> <20180315224202.96668-3-dmitry.torokhov@gmail.com> <20180316100748.GH16424@w540> <20180316233800.GA32310@dtor-ws> <20180317092516.g5p5ybka57abyhex@apu3b> To: jacopo mondi X-Originating-IP: 118.241.251.31 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > On Mar 17, 2018, at 6:25 PM, jacopo mondi wrote: > > Hi Dmitry, > >> On Fri, Mar 16, 2018 at 04:38:00PM -0700, Dmitry Torokhov wrote: >> Hi Jacopo, >> >>> On Fri, Mar 16, 2018 at 11:07:48AM +0100, jacopo mondi wrote: >>> Hello Dmitry >>> >>> FYI I am brushing the ecovec board these days as well >>> https://www.spinics.net/lists/linux-sh/msg52536.html >>> >> >> What is the ecovec board BTW? Is it some devkit or what? It seems quite >> old to me. > > Yes, it is a SuperH 4 based development board. It is old for sure. I'm > also working on removing some stuff the ecovec board file is the only > user of... Umh, but I’m still using the SH7724 Evovec board. Please don’t remove support for that. The SuperH port of the Linux kernel is still maintained. Adrian > >>> And I have a board to test with but without any display panel, I'm >>> afraid. >>> >>>> On Thu, Mar 15, 2018 at 03:42:00PM -0700, Dmitry Torokhov wrote: >>>> Commit fe79f919f47e ("sh: ecovec24: Use gpio-backlight") removed custom >>>> backlight support and switched over to generic gpio-backlight driver. The >>>> comment when we run with DVI states "no backlight", but setting >>>> gpio_backlight_data.fbdev to NULL actually makes gpio-backlight to react to >>>> events from any framebuffer device, not ignore them. >>>> >>>> We want to get rid of platform data in favor of generic device properties >>>> in gpio_backlight driver, so we can not have kernel pointers passed around >>>> to tie the framebuffer device to backlight. Assuming that the intent of the >>>> above referenced commit was to indeed not export backlight when using DVI, >>>> let's switch to conditionally registering backlight device so it is not >>>> present at all in DVI case. >>>> >>>> Signed-off-by: Dmitry Torokhov >>>> --- >>>> arch/sh/boards/mach-ecovec24/setup.c | 24 +++++++++++++++++------- >>>> 1 file changed, 17 insertions(+), 7 deletions(-) >>>> >>>> diff --git a/arch/sh/boards/mach-ecovec24/setup.c b/arch/sh/boards/mach-ecovec24/setup.c >>>> index 6f929abe0b50f..67633d2d42390 100644 >>>> --- a/arch/sh/boards/mach-ecovec24/setup.c >>>> +++ b/arch/sh/boards/mach-ecovec24/setup.c >>>> @@ -368,7 +368,6 @@ static struct platform_device lcdc_device = { >>>> }; >>>> >>>> static struct gpio_backlight_platform_data gpio_backlight_data = { >>>> - .fbdev = &lcdc_device.dev, >>>> .gpio = GPIO_PTR1, >>>> .def_value = 1, >>>> .name = "backlight", >>>> @@ -987,7 +986,6 @@ static struct platform_device *ecovec_devices[] __initdata = { >>>> &usb1_common_device, >>>> &usbhs_device, >>>> &lcdc_device, >>>> - &gpio_backlight_device, >>>> &ceu0_device, >>>> &ceu1_device, >>>> &keysc_device, >>>> @@ -1077,6 +1075,8 @@ static int __init arch_setup(void) >>>> { >>>> struct clk *clk; >>>> bool cn12_enabled = false; >>>> + bool use_backlight = false; >>>> + int error; >>>> >>>> /* register board specific self-refresh code */ >>>> sh_mobile_register_self_refresh(SUSP_SH_STANDBY | SUSP_SH_SF | >>>> @@ -1193,9 +1193,6 @@ static int __init arch_setup(void) >>>> lcdc_info.ch[0].lcd_modes = ecovec_dvi_modes; >>>> lcdc_info.ch[0].num_modes = ARRAY_SIZE(ecovec_dvi_modes); >>>> >>>> - /* No backlight */ >>>> - gpio_backlight_data.fbdev = NULL; >>>> - >>>> gpio_set_value(GPIO_PTA2, 1); >>>> gpio_set_value(GPIO_PTU1, 1); >>>> } else { >>>> @@ -1217,6 +1214,8 @@ static int __init arch_setup(void) >>>> /* enable TouchScreen */ >>>> i2c_register_board_info(0, &ts_i2c_clients, 1); >>>> irq_set_irq_type(IRQ0, IRQ_TYPE_LEVEL_LOW); >>>> + >>>> + use_backlight = true; >>>> } >>>> >>>> /* enable CEU0 */ >>>> @@ -1431,8 +1430,19 @@ static int __init arch_setup(void) >>>> gpio_set_value(GPIO_PTG4, 1); >>>> #endif >>>> >>>> - return platform_add_devices(ecovec_devices, >>>> - ARRAY_SIZE(ecovec_devices)); >>>> + error = platform_add_devices(ecovec_devices, >>>> + ARRAY_SIZE(ecovec_devices)); >>> >>> I would invert this. >>> Register the backlight first, then all other devices. >> >> We could do that, but why would that be better? >> > > That if backlight device registration fails we do not register all > other devices. But yes that may be a bit too harsh, isn't it? > >>> >>> >>>> + if (error) >>>> + return error; >>>> + >>>> + if (use_backlight) { >>>> + error = platform_device_add(&gpio_backlight_device); >>>> + if (error) >>>> + pr_warn("%s: failed to register backlight: %d\n", >>>> + error); >>> >>> Could you use dev_warn here? Also the format is wrong, I assume you >> >> I would rather not, as the backlight device would be in unknown state >> here, and using dev_warn with device that has not been fully registered >> does not give any benefits. There is also no ambiguity as there is only >> one backlight. > > You are very correct, sorry for the fuss. > >> >>> are missing a '__func__' as second function argument. >> >> I'll fix this. >> >>> >>> Also, you may want to return error. >> >> How would caller handle this error? Should we kill all successfully >> registered devices on error adding backlight? > > As the function returned an error code for 'platform_add_devices()' I > thought we may want to return one as well. That's why I proposed to > invert the registration order :) > > All minor nits btw, sorry for jumping up, I understand this is an > RFC and ecovec board file is not the real juice of this series ;) > > Ping me if I can help with testing as I've the board. > > Thanks > j > >> >> Thanks. >> >> -- >> Dmitry > -- > To unsubscribe from this list: send the line "unsubscribe linux-sh" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html