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=DKIM_SIGNED,DKIM_VALID, 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 DAA9DC54F70 for ; Sun, 19 Apr 2020 12:55:05 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B6B3C206D9 for ; Sun, 19 Apr 2020 12:55:05 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=vanguardiasur-com-ar.20150623.gappssmtp.com header.i=@vanguardiasur-com-ar.20150623.gappssmtp.com header.b="u5lsvyNi" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725970AbgDSMzF (ORCPT ); Sun, 19 Apr 2020 08:55:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39344 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725793AbgDSMzE (ORCPT ); Sun, 19 Apr 2020 08:55:04 -0400 Received: from mail-ed1-x542.google.com (mail-ed1-x542.google.com [IPv6:2a00:1450:4864:20::542]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C4E4CC061A0C for ; Sun, 19 Apr 2020 05:55:02 -0700 (PDT) Received: by mail-ed1-x542.google.com with SMTP id p16so545868edm.10 for ; Sun, 19 Apr 2020 05:55:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vanguardiasur-com-ar.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Pe8Qy0Gf3UYgcgfyDsFH4TWiKOw4rDRv4sJ8XYFqXvU=; b=u5lsvyNiSZb72r61DjpSksiUWO68i7LgEwVmotr4VBUqiRFRHbu2EruGUR/XBlNEO0 w71OJJQA2nfs4t0byKoJVt3UH1HkQWxyvbQSfFBKBADfB3hAbDPA970lzbHMpYbIvwqL RZ8lKNLdNGbBmxLFk9m5TQ/NmAZJJIDm1RHwU3fInbPJOk725NoYiS4UDtO199ntC7ep dIbdnH6ZEg7srkRWiZQo2AFfsNsYI2pMQhYoRkdzl5fHj57TMSgxYcz07QJp/iUeySl9 h874sFgcXFQ4EfR7A7gVAKFCBENF8X40dhP9BkbjLSaY1E0q1cMS4g87YmZoAEnm25Jq a0TA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Pe8Qy0Gf3UYgcgfyDsFH4TWiKOw4rDRv4sJ8XYFqXvU=; b=ClzdpH4Qt32G2uB1qOsvOUQ4ZfPOKHmWBXg807k5B6Mns30WoqxtnWQ8o/dSaBg1W1 FGbqEOZ3Mq6vuYKQVAgc0FR5awbJWMMPbvuh5z+kM2No9aG7FfGy76IGpxGnnuFE2SUu 5IrCrYnkzkQ4CEaPF/nI5NDJjj8kTW/x95WPqAKjfl8SyLCGy4WWRjP76RhtOrtnSg43 +q4x6sNrVp+KPKR5GKWe1b6ae/NptSJLzEysiKswI+yoOS4TPl5AS5FPuU220cFzJvAY iZES4uXUzmD7z+tHAAkfLDgtmiO/IN6s1YiGgaekUMC+f8d4KBoWO/zZJvc2yP7E/lVQ vnWw== X-Gm-Message-State: AGi0PuYz+oAgWijwmGszAFy4CQM1B/cvS1XiPGtsi4c8db037l/2qlKM 7yYSb9Fjv1JWGEM1csHW9sCykq6xDupUn6cwRQ9Pgw== X-Google-Smtp-Source: APiQypJGVGjxtdPPkJ5/MNfOnUxhN+8psU1U9lQOyFemqbXIrJY0T9nZmKqlxy3Xpjm3uBwBmE88iVK+GHu7W9vYYM8= X-Received: by 2002:a05:6402:391:: with SMTP id o17mr4297099edv.71.1587300901412; Sun, 19 Apr 2020 05:55:01 -0700 (PDT) MIME-Version: 1.0 References: <20200417202859.35427-1-contact@artur-rojek.eu> <20200417202859.35427-3-contact@artur-rojek.eu> <3KAY8Q.NNI6X4F9QRIX1@crapouillou.net> <86BY8Q.C5XO8D57M7BI1@crapouillou.net> In-Reply-To: From: Ezequiel Garcia Date: Sun, 19 Apr 2020 09:54:49 -0300 Message-ID: Subject: Re: [RESEND PATCH v5 3/5] IIO: Ingenic JZ47xx: Add touchscreen mode. To: Andy Shevchenko Cc: Paul Cercueil , Artur Rojek , Dmitry Torokhov , Rob Herring , Mark Rutland , Jonathan Cameron , Heiko Stuebner , linux-input , devicetree , linux-iio , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: devicetree-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Fri, 17 Apr 2020 at 18:54, Andy Shevchenko w= rote: > > On Sat, Apr 18, 2020 at 12:45 AM Paul Cercueil wro= te: > > Le sam. 18 avril 2020 =C3=A0 0:42, Andy Shevchenko > > a =C3=A9crit : > > > On Sat, Apr 18, 2020 at 12:18 AM Paul Cercueil > > > wrote: > > >> Le sam. 18 avril 2020 =C3=A0 0:13, Andy Shevchenko > > >> a =C3=A9crit : > > >> > On Sat, Apr 18, 2020 at 12:05 AM Paul Cercueil > > >> > > >> > wrote: > > >> >> Le ven. 17 avril 2020 =C3=A0 23:59, Andy Shevchenko > > >> >> a =C3=A9crit : > > >> >> > On Fri, Apr 17, 2020 at 11:21 PM Artur Rojek > > >> >> > > >> >> > wrote: > > >> > > > >> > ... > > >> > > > >> >> >> + irq =3D 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. Everythin= g > > > 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? Cheers, Ezequiel