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 X-Spam-Level: * X-Spam-Status: No, score=1.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_ABUSE_SURBL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 48F69C54FC9 for ; Sun, 19 Apr 2020 13:32:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2FC36206F9 for ; Sun, 19 Apr 2020 13:32:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726123AbgDSNcA (ORCPT ); Sun, 19 Apr 2020 09:32:00 -0400 Received: from relay10.mail.gandi.net ([217.70.178.230]:41203 "EHLO relay10.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725994AbgDSNcA (ORCPT ); Sun, 19 Apr 2020 09:32:00 -0400 Received: from webmail.gandi.net (webmail15.sd4.0x35.net [10.200.201.15]) (Authenticated sender: contact@artur-rojek.eu) by relay10.mail.gandi.net (Postfix) with ESMTPA id B7F79240003; Sun, 19 Apr 2020 13:31:54 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Sun, 19 Apr 2020 15:31:54 +0200 From: Artur Rojek To: Ezequiel Garcia Cc: Andy Shevchenko , Paul Cercueil , Dmitry Torokhov , Rob Herring , Mark Rutland , Jonathan Cameron , Heiko Stuebner , linux-input , devicetree , linux-iio , Linux Kernel Mailing List Subject: Re: [RESEND PATCH v5 3/5] IIO: Ingenic JZ47xx: Add touchscreen mode. In-Reply-To: References: <20200417202859.35427-1-contact@artur-rojek.eu> <20200417202859.35427-3-contact@artur-rojek.eu> <3KAY8Q.NNI6X4F9QRIX1@crapouillou.net> <86BY8Q.C5XO8D57M7BI1@crapouillou.net> Message-ID: <2ac495eef8143f2339b3e2a3eef24b27@artur-rojek.eu> X-Sender: contact@artur-rojek.eu User-Agent: Roundcube Webmail/1.3.8 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Ezequiel, On 2020-04-19 14:54, Ezequiel Garcia wrote: > On Fri, 17 Apr 2020 at 18:54, Andy Shevchenko > wrote: >> >> On Sat, Apr 18, 2020 at 12:45 AM Paul Cercueil >> wrote: >> > Le sam. 18 avril 2020 à 0:42, Andy Shevchenko >> > a écrit : >> > > On Sat, Apr 18, 2020 at 12:18 AM Paul Cercueil >> > > wrote: >> > >> Le sam. 18 avril 2020 à 0:13, Andy Shevchenko >> > >> a écrit : >> > >> > On Sat, Apr 18, 2020 at 12:05 AM Paul Cercueil >> > >> >> > >> > wrote: >> > >> >> Le ven. 17 avril 2020 à 23:59, Andy Shevchenko >> > >> >> a écrit : >> > >> >> > On Fri, Apr 17, 2020 at 11:21 PM Artur Rojek >> > >> >> >> > >> >> > wrote: >> > >> > >> > >> > ... >> > >> > >> > >> >> >> + irq = platform_get_irq(pdev, 0); >> > >> >> > >> > >> >> > Before it worked w/o IRQ, here is a regression you introduced. >> > >> >> >> > >> >> Before it simply did not need the IRQ, which is provided by the >> > >> >> devicetree anyway. No regression here. >> > >> > >> > >> > Does it work without IRQ? Or it was a dead code till now? >> > >> > For me it's clear regression. Otherwise something is really wrong >> > >> in a >> > >> > process of development of this driver. >> > >> >> > >> Nothing wrong here. The IRQ was not used by the driver for the >> > >> functionality it provided before. It is required now to support the >> > >> touchscreen channels. >> > > >> > > This is exactly what's wrong. >> > > Previous DTS for my (hypothetical) case has no IRQ defined. Everything >> > > works, right? >> > > Now, due to this change it breaks my setup. Don't you see the problem? >> > >> > The IRQ has been provided by every concerned DTS file since the >> > introduction of this driver and the related bindings, even though it >> > was not used by the driver. >> >> Can you speak for all possible DTSs/DTBs in the wild? >> Okay, in any case it will be problem of maintainers and yours if >> somebody complains. >> I'm not going to push this anyway -- your choice. >> >> But I see a (potential) regression. >> > > So, there are a few things to keep in mind here. > > Let's abstract ourselves from this specific driver > for a minute. > > First, and just as Andy pointed out, we can never be fully > sure about DTBs out there. These could be out of tree, > so out of our control. By introducing a new requirement > we break them, which may be seen as a regression. > > Second, the interrupt is not required as per > current mainline bindings/iio/adc/ingenic,adc.txt, > so it is perfectly legal for users to not have an interrupt > specified. > > Now, back to this case, I think we can get away with this > change, provided this hardware is not that widespread > among developers/users that follow upstream closely. > > I suspect anyone developing a serious platform > with this SoC is most likely using some vendor kernel. > > If that is not the case, i.e. if you have users _actually_ > using this upstream driver, then we should consider > making the interrupt optional instead of required. > > Or we can also just break it and hope nobody > complaints. > > BTW, this series looks great and I'm happy > to see JZ47xx activity :-) > > Arthur: perhaps you can consider converting the txt dt binding > to yaml? Sure, it will come with v6 of this patchset. And this time I'll make the `interrupts` property required :-) - Artur > > Cheers, > Ezequiel